Új hozzászólás Aktív témák

• #49 Everman addikt cqr #47

  Új Válasz 2011-07-28 12:52:51 #49

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Everman

  addikt

  válasz cqr #47 üzenetére

  Butaságért nem mész a szomszédba látom

  SGS II-n per pillanat annyit tud tenni a rendszer, hogy az újonnan indított alkalmazást arra a magra irányítja, ami kevésbé van terhelve (a rendszer és user processeket megpróbálja elosztani a két mag között).
  Ha maga a böngésző lenne képes a több processzormag kezelésére, akkor ahhoz eleve több szálon kéne futnia, hogy azokat el tudja köztük osztani (erre volt példa a Chrome), de ezt nem tudja.

  Szóval ha hallgattál volna, akkor....

  [ Szerkesztve ]

• #51 Everman addikt cqr #50

  Új Válasz 2011-07-28 14:29:59 #51

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Everman

  addikt

  válasz cqr #50 üzenetére

  Kapaszkodj meg, a JVQ-s SGS-es böngésző szintén GPU gyorsított, szóval nem nyert, nem ezért gyors az SGS II-n

  Az más tészta, hogy Androidon nincs OpenCL, vagy hasonló megoldás, ami a számításokat átterhelhetné a GPU-ra, csupán arról van szó, hogy az Android világában újdonságként a képi megjelenítés bizonyos részeinek feldolgozását már a GPU végzi. Ez más rendszereknél alap dolog, itt sok év után ilyen kavarodást okoz a fejekben, mint nálad
  Még egyszer, a GPU/hardveresen gyorsított megjelenítésnek semmi köze a több processzormagon egy időben történő feldolgozáshoz, többszálú működéshez.

  "Van egy pár gpu-gyorsított böngésző, a samu esetén egyes a verziókban a gyári is"

  Ezt senki nem cáfolta, pl. az Opera Mobile is ilyen.

  "Egyébként ha ilyen izgis dolgokat írsz, akkor esetleg linkelhetsz is egy két szmájli helyett"

  Google és a józan ész a barátod

• #52 cqr aktív tag cqr #50

  Új Válasz 2011-07-28 14:47:47 #52

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cqr

  aktív tag

  válasz cqr #50 üzenetére

  Egy is kiegészítés, mert félreérti..

  Ha maga a böngésző lenne képes a több processzormag kezelésére, akkor ahhoz eleve több szálon kéne futnia, hogy azokat el tudja köztük osztani (erre volt példa a Chrome), de ezt nem tudja.

  Nem arról folyik a ""vita"" hogy tud-e több magot kezelni a böngésző, nem is írtam sehol olyat.. És nem is arról, hogy mit jelent a többszálú adatfeldolgozás.. hanem amit 47-ben idézek. Nem attól gyors, hogy kap +5% cpu időt, hanem mert használhatja a gpu-t.

  SGS II-n per pillanat annyit tud tenni a rendszer, hogy az újonnan indított alkalmazást arra a magra irányítja, ami kevésbé van terhelve (a rendszer és user processeket megpróbálja elosztani a két mag között).

  Ez sem igazán a hszmre válasz, kivéve ha arra is célzol, hogy a nincs gpu gyorsítás a böngészőben. Na arról akkor igazán jöhet egy link.

  Szerk, jaj de kár hogy nem voltam gyorsabb (lehet a hsz felénél nem kellett volna lemenni enni xd), persze hogy ezekkel kapcsolatban kezdi el írni a ...

  [ Szerkesztve ]

• #53 Everman addikt cqr #52

  Új Válasz 2011-07-28 14:59:10 #53

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Everman

  addikt

  válasz cqr #52 üzenetére

  "Egy is kiegészítés, mert félreérti.."

  Lehet, hogy mindketten félreértettük egymást.

  "Nem arról folyik a ""vita"" hogy tud-e több magot kezelni a böngésző"

  De pont erről szól, ezzel kapcsolatban válaszoltam muveszur hozzászólására.

  "Nem attól gyors, hogy kap +5% cpu időt, hanem mert használhatja a gpu-t."

  A hardveres grafikai gyorsítás már az SGS-en sem újdonság, attól gyors, hogy mivel két mag között tudja a processeket elosztani a rendszer, így lényegesen több erőforrás jut a böngészőnek is, akár konkrétan annyi, mint az SGS esetén az összes alkalmazásnak, rendszernek együttvéve. Ha mindezt több szálra szét tudná bontani és a két mag között megosztani, akkor még nagyobb teljesítményre lenne képes. Én erről írtam.

  Grafikai teljesítményben egyébként az SGS is fel tudja venni a versenyt az SGS II-vel, megfelelő beállításokkal: [link]

  "Ez sem igazán a hszmre válasz"

  A hozzászólásodra nem igen lehet lényegi választ adni, mert úgy fogalmaztál, hogy butaság jött ki belőle.

  Lásd.:
  "A gyári böngésző külön magon fut, azért gyors
  Ja, a gpu-n."

  Még OpenCL esetén sem a GPU-n fut az adott alkalmazás, hanem annak bizonyos matematikai számításait terhelik át a GPU-ra.
  Itt meg csak annyi történik, hogy a böngésző képi megjelenítését (scroll, képkezelés, nagyítás stb.) a GPU dolgozza fel.
  Más rendszereknél ez alapból így van, de Androidon ezek a számítások a sok gyenge GPU-val, vagy akár GPU nélkül szerelt készülék miatt alapból a CPU-ra van terhelve.

  Még egyszer, senki nem cáfolta, hogy az SGS II böngészője hardveresen gyorsított megjelenítést alkalmaz, egész egyszerűen másról szólt a két hozzászólás, amihez kapcsolódtál.

  [ Szerkesztve ]

• #56 Everman addikt cqr #54

  Új Válasz 2011-07-28 18:16:39 #56

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Everman

  addikt

  válasz cqr #54 üzenetére

  "Normál esetben mikor a böngésző elindul már a cpu idő nagyon jelentős százalékát megkapja, így + néhány százalék ebből az erőforrásból nem olyan jelentős."

  SGS-en megkapja a CPU 50-60%-át és jó esetben 50-60 MB RAM-ot, SGS II-n ideális esetben megkapja az egyik mag 100%-át és akár 4-500 MB RAM-ot.
  Ne haragudj, de ez jelentős különbség.

  "Kirajzolás során (android esetén főleg natív alkalmazásoknál) a megjelenítendő primitívek és azok kombinációjától (és az effectektől) függően 100-1000szer is gyorsabb lehet a gpu a cpu-nál."

  Ez így igaz, de egy weboldal esetén a kirajzolás a legkevésbé erőforrás igényes feladat (a tartalom mozgatása, nagyítása más lapra tartozik), az oldal lerenderelése, nagyításnál a hasábok újratördelése viszont inkább nagyobb falat és ezt a CPU végzi.

  "az általad linkelt grafikus teszt nem az a kategória amivel ezeket mérni lehet"

  Ez a teszt inkább a 2D-s grafikus teljesítményt nézi, mint a 3D-t így lényegében teljesen igazad van, de egy weboldal GPU specifikus kezelésénél pont ez számít, nem a 3D-s teljesítmény.

  Egyébként ha tudsz mondhatsz korrekt tesztet.

• #58 Everman addikt cqr #57

  Új Válasz 2011-07-28 22:11:13 #58

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Everman

  addikt

  válasz cqr #57 üzenetére

  "A böngészés a betöltés után elsődlegesen render feladat (amibe beletartozik a görgetés, nagyitás is)"

  A renderinget a CPU végzi, a leképzett oldal megjelenítését és grafikai megoldásait (valós idejű nagyítás, scroll) a GPU végzi (hardveres gyorsítás esetén). Nem véletlen, hogy a browser tesztek főleg CPU sebesség eredményeket adnak (egy HTML5 kódot, vagy java scriptet nem a GPU számol).

• #61 Everman addikt cqr #60

  Új Válasz 2011-07-29 10:56:13 #61

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Everman

  addikt

  válasz cqr #60 üzenetére

  "Továbbra is furcsán kezeled a két fogalmat (megjelentítés vs. rendering) : )."

  Inkább te nem érted a különbséget
  A rendering a kapott adatok alapján történő leképzése az oldalnak (különböző HTML kódok fordítása, scriptek lefuttatása stb.) ezt mobil rendszernél nem tudja a GPU egyelőre segíteni, ami a rendering végterméke, azt dolgozza fel a GPU és jeleníti meg. A hardveres gyorsítás Androidnál kimerül a megjelenítésben, vagyis gyorsabb és folyamatosabb lesz a scroll és a nagyítás. Illetve ami nem közvetlenül a böngészőhöz kötődik, a flash tartalom megjelenítésében is segít.

  [link]

  [ Szerkesztve ]

• #64 cqr aktív tag cqr #63

  Új Válasz 2011-07-29 12:01:49 #64

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cqr

  aktív tag

  válasz cqr #63 üzenetére

  Btw, valsz csak arról van szó, hogy everman azt a folyamatot, amikor a gpu végrehajtja a cpu által összegyűjtött objectek és kirajzoló-parancsok sorozatát, nos azt nem veszi a "rendering"-hez, hanem arra a "megjelenítés" szót használja.. így kicsit nehéz.. xd

  [ Szerkesztve ]

• #65 Everman addikt cqr #64

  Új Válasz 2011-07-29 12:50:40 #65

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Everman

  addikt

  válasz cqr #64 üzenetére

  "cpu által összegyűjtött objectek és kirajzoló-parancsok sorozatát, nos azt nem veszi a "rendering"-hez, hanem arra a "megjelenítés" szót használja."

  Természetesen, hiszen két különböző folyamat, az egyik a kapott kódok és scriptek alapján leképzi az adott oldal megjelenítéséhez szükséges adatokat a CPU segítségével, amit megkap a GPU és megjeleníti azt (az, hogy milyen grafikus könyvtárakat használ a fontok, vektoros objektumok, képek megjelenítéshez már itt kap jelentőséget).
  A rendering ugyanis nem a képernyőn látható információ megjelenítését jelenti, hanem az ahhoz szükséges adathalmaz leképzését. Egy renderfarm sem azon ügyködik, hogy gyorsan scrollozzon a képernyőn a kép, hanem a megjelenítendő képi információ (képkockák) leképzését végzi. (Az más téma, hogy egy renderfarmon ügyködő gép számítási sebességét a különböző GPU-s megoldások is gyorsíthatják.)

Új hozzászólás Aktív témák