[Chabi]

Idézet: vers - Dátum: 2010. 12. 09. 18:59

meg a gpgpu-nal is problemas a tobb gpu

2 éve hogy a multigpu támogatás megjelent a CUDA-ban (v2.1), az egy másik dolog, hogy rengeteg program 2.0-t használ. Én úgy gondolom ez inkább a fejlesztők sara amíg úgy van megírva a program, hogy csak 1 gpu-t használjon.

[vers]

Idézet: Rodrigez07 - Dátum: 2010. 12. 09. 17:03

Túl egyenletesnek tűnik a sebesség ahhoz, hogy szofveres, CF féle megoldás legyen ... szerintem

szerintem nem a CF az erdekes ebben az architecturaban, hanem a 3D tamogatas, gondolom erre fog epulni az egesz marketing
aztan lehet tevedek , bar szemely szerint a 3d-t egyelore letojom

[vers]

Idézet: Chabi - Dátum: 2010. 12. 09. 17:07

2 éve hogy a multigpu támogatás megjelent a CUDA-ban (v2.1), az egy másik dolog, hogy rengeteg program 2.0-t használ. Én úgy gondolom ez inkább a fejlesztők sara amíg úgy van megírva a program, hogy csak 1 gpu-t használjon.

eloszor en is erre gondoltam, aztan probaltam egy raytrace algoritmust kitalalni tobb gpu-ra, es arra a megallapitasra jutottam hogy rohadjon meg a tobb gpu
bar megoldhato a dolog csak igen nagy a kinlodas

[Chabi]

Idézet: Rodrigez07 - Dátum: 2010. 12. 09. 19:03

Túl egyenletesnek tűnik a sebesség ahhoz, hogy szofveres, CF féle megoldás legyen ... szerintem

Remélem nem kajáltad be ezt a mondatot:

Idézet: vers - Dátum: 2010. 12. 09. 16:46

vegulis egy cf van egy chipbe rakva

Nincs semmi féle CF a chipen bellül, hogy hardveres/szoftveres/driveres anyámkínja legyen, egész egyszerűen ilyen a felépítése.

[Chabi]

Idézet: vers - Dátum: 2010. 12. 09. 19:11

eloszor en is erre gondoltam, aztan probaltam egy raytrace algoritmust kitalalni tobb gpu-ra, es arra a megallapitasra jutottam hogy rohadjon meg a tobb gpu
bar megoldhato a dolog csak igen nagy a kinlodas

Hát az SDK-k már csak ilyenek. De én aztmondom hogy desktop környezetre teljesen felesleges több gpu-ra fejleszteni, mivel a felhasználók 99.9%-nak 1 gpu van a gépében. Meg ugye ne 2-3 gpu-val akarjunk helyettesíteni 1 (x magos)processzort, ha már raytracing, mert a jelenlegi formájában epic fail a technológia színvonala/használhatósága.

[vers]

Idézet: Chabi - Dátum: 2010. 12. 09. 17:13

Remélem nem kajáltad be ezt a mondatot:

Nincs semmi féle CF a chipen bellül, hogy hardveres/szoftveres/driveres anyámkínja legyen, egész egyszerűen ilyen a felépítése.

viselkedhet CF-kent, gondolj bele mikor egy jatekban allsz egy helyben es csak losz, akkor az egymas utani framek ugyanazok, es a 2 framet egyszerre renderelve, csak egyszer kell beolvasni a texturakat a memoriabol , igy olyan mintha duplaznad a memsavszelt
a driver csak annyit csinal hogy a geometriat egyszerre inditsa el a fel gpu-n , hogy a cache talalatot maximalizalja
ugyanez ervenyes a stereo 3D-re is mivel a 2 kep kozotti kulonbseg nincs 5 %

Szerkesztette: vers 2010. 12. 09. 18:33 -kor

[Rodrigez07]

Idézet: Chabi - Dátum: 2010. 12. 09. 18:13

Remélem nem kajáltad be ezt a mondatot:

Nincs semmi féle CF a chipen bellül, hogy hardveres/szoftveres/driveres anyámkínja legyen, egész egyszerűen ilyen a felépítése.

Nem kajáltam én semmit, éhes is vagyok mint a rosseb
De még a 2010.11.22. 15:48-kor általad linkelt 2. képről is az jön le nekem, mintha valóban 2 majdnem teljes értékű GPU lenne összetokozva. Arról a slide-ról beszélek, ahol Dual Graphics Engine-ként említik. Saját textúrázó, SIMD tömbök, saját L1 cache, stb. Ezért gondoltam, hogy valamilyen szintű párhuzamosítás kell a 2 különálló blokk vezérlésére. Bár biztos egyszerűbb, mint 2 önálló GPU-t - aminek saját memóriavezérlője és egyebe van - kezelni.

[Chabi]

Idézet: vers - Dátum: 2010. 12. 09. 19:32

viselkedhet CF-kent, gondolj bele mikor egy jatekban allsz egy helyben es csak losz, akkor az egymas utani framek ugyanazok, es a 2 framet egyszerre renderelve, csak egyszer kell beolvasni a texturakat a memoriabol , igy olyan mintha duplaznad a memsavszelt
a driver csak annyit csinal hogy a geometriat egyszerre inditsa el a fel gpu-n , hogy a cache talalatot maximalizalja
ugyanez ervenyes a stereo 3D-re is mivel a 2 kep kozotti kulonbseg nincs 5 %

Ha egyhelyben állsz és lősz akkor mozognak valamik aminek változó lehet a textúrája. Mert ugye nem mozogó semmire nem lövünk. A Geometriára pedig már évek óta megoldás (2003 - Dx9.0b), hogy a cache-ből legyen kiolvasva és ne egyfolytában számolja ki ugyanazt újra és újra hanem csak 1x. Ez pedig a Geometry Instancing, ami nem csak ATI kártyával működik.

[Valdy]

A frame buffer is közös lesz-e?

[arn]

Idézet: Rodrigez07 - Dátum: 2010. 12. 09. 18:03

Túl egyenletesnek tűnik a sebesség ahhoz, hogy szofveres, CF féle megoldás legyen ... szerintem

a programokat ok valogattak

[vers]

Idézet: Chabi - Dátum: 2010. 12. 09. 17:59

Ha egyhelyben állsz és lősz akkor mozognak valamik aminek változó lehet a textúrája. Mert ugye nem mozogó semmire nem lövünk. A Geometriára pedig már évek óta megoldás (2003 - Dx9.0b), hogy a cache-ből legyen kiolvasva és ne egyfolytában számolja ki ugyanazt újra és újra hanem csak 1x. Ez pedig a Geometry Instancing, ami nem csak ATI kártyával működik.

a nem mozgast az egyszeruseg kedveert vezettem be:D, de ugy latszik meg igy sem sikerult feldolgozni, 100 fps-nel 2 frame kozott a textura kulonbseg sincs 5% folott, akkor sem ha gyalogolsz , vagy futsz a terepen,
a lenyeg hogy a textura olvasas nagyjabol egyidoben jojjon letre a 2 fel gpu-n, mert igy nagyobb a valoszinusege hogy a cacheben meg benne van

amugy ezt az architecturat mar a 4850 kijovetelekor feszegettem itt a forumon, az ati most ert el a megvalositasig

[arn]

Idézet: Rodrigez07 - Dátum: 2010. 12. 09. 18:42

Nem kajáltam én semmit, éhes is vagyok mint a rosseb
De még a 2010.11.22. 15:48-kor általad linkelt 2. képről is az jön le nekem, mintha valóban 2 majdnem teljes értékű GPU lenne összetokozva. Arról a slide-ról beszélek, ahol Dual Graphics Engine-ként említik. Saját textúrázó, SIMD tömbök, saját L1 cache, stb. Ezért gondoltam, hogy valamilyen szintű párhuzamosítás kell a 2 különálló blokk vezérlésére. Bár biztos egyszerűbb, mint 2 önálló GPU-t - aminek saját memóriavezérlője és egyebe van - kezelni.

a cypress is erdekesen szimmetrikus volt.

[Chabi]

Idézet: Rodrigez07 - Dátum: 2010. 12. 09. 19:42

Nem kajáltam én semmit, éhes is vagyok mint a rosseb
De még a 2010.11.22. 15:48-kor általad linkelt 2. képről is az jön le nekem, mintha valóban 2 majdnem teljes értékű GPU lenne összetokozva. Arról a slide-ról beszélek, ahol Dual Graphics Engine-ként említik. Saját textúrázó, SIMD tömbök, saját L1 cache, stb. Ezért gondoltam, hogy valamilyen szintű párhuzamosítás kell a 2 különálló blokk vezérlésére. Bár biztos egyszerűbb, mint 2 önálló GPU-t - aminek saját memóriavezérlője és egyebe van - kezelni.

Ott van az RV870 ami szintén két 800 stream proceszoros SIMD tömbből áll, a hozzájuk kapcsolódó textúrázó egységekkel és L1 cache-el. Mégse 2 teljes értékű gpu egybetokozva.



A Dual-Graphics Engine annyiban különbözik, hogy órajelenkét 2 ciklus lesz végrehajtva a jelenlegi 1 ciklussal szemben amit az RV870 tud.



Ezért a 2 ciklus miatt a geometriai feldolozó sebessége azonos órajelen a duplája lesz.



A Fermi 4 feldolgozóból áll (GPC - Graphics Processing Cluster), ezért órajelenként 4 ciklust képes végrehajtani.



Csak a poén kevéért játék a számokkal... Ha a GTX580 esetenként 40-60%-ot is képes ráverni az 5870-re a magasabb geometriai számítási teljesítményével (4 ciklus), akkor a HD6970 magasabb órajellel, ezért az 5870-nél (1 ciklus) több mint kétszeres geometriai számítási teljesítménnyel, több textúrázóval, magasabb memória sávszélességgel; mennyivel lesz gyorsabb mint az 5870 ?

[Chabi]

Idézet: vers - Dátum: 2010. 12. 09. 20:07

a lenyeg hogy a textura olvasas nagyjabol egyidoben jojjon letre a 2 fel gpu-n, mert igy nagyobb a valoszinusege hogy a cacheben meg benne van

Két fél gpu-n fele akkora csak a tetúrázási teljesítmény, hiába van ott benne a cache-ben. Ennek így semmi értelme.

[vers]

Idézet: Chabi - Dátum: 2010. 12. 09. 18:37

Két fél gpu-n fele akkora csak a tetúrázási teljesítmény, hiába van ott benne a cache-ben. Ennek így semmi értelme.

orulnenek az ati mernokei ha csak a gputol fuggene a texturazasi sebesseg, es nem a nyomorek memoriatol

[vers]

[Chabi]

1440 nem lehet ha már bejelentették a VILW4-re épülő architektúrát.

[vers]

Idézet: Chabi - Dátum: 2010. 12. 09. 20:45

1440 nem lehet ha már bejelentették a VILW4-re épülő architektúrát.

VLIW amugy, mint a ps2 processzora

nagy a szarkavaras atieknal , de az adatokbol nagy 580 utes nem varhato

[vers]

most mar csak az erdekel mi a dudva az a kapcsolo a kartyan, mit nem lehetett megoldani driverbol

[NetTom]

Az egyetlen érdekes dolog amit látok a slidokon az a "tile based load balancing"... erre kíváncsi leszek.
Amugy a geometria duplázás miatt vágták csak szét ez tisztán látszik.