[SFIJ]

Idézet: vers - Dátum: 2005. márc. 22., kedd - 0:45

a "hirek" szerint a ps3 devkitekben nincs grafikus proci, hanem valoszinüsithetöen 2 cell dübörög,valakinek  van ötlete hogy van ez? netán raytracing algoritmust használnak ?

valszeg befogtak az egyik cell-t vpu-nak. amugy hogy lehet(ne) egy ilyen devkitet szerzni?

[vers]

Idézet: SFIJ - Dátum: 2005. márc. 22., kedd - 13:35

valszeg befogtak az egyik cell-t vpu-nak. amugy hogy lehet(ne) egy ilyen devkitet szerzni?

a sonytol , csekély 10 milla az ára:) de elképzelhetö hogy csak késöbb kapnál, most csak a föfejlesztök kaptak belöle

[SFIJ]

Idézet: vers - Dátum: 2005. márc. 22., kedd - 16:51

a sonytol , csekély 10 milla az ára:) de elképzelhetö hogy csak késöbb kapnál, most csak a föfejlesztök kaptak belöle

pedig milyen jol jonne a videokodek testbenchnek. kezdem unni, hogy az athlon 15-16 ora alatt vegez csak egy masfel oras jatekfilm H.264 AVC-be tomesevel

amugy nincsenek jo tapasztalataim a sonyval. 2002-ben honapokat konyorogtunk a sony hungarianak, hogy importaljon mar magayrorszagra dru500a tipusu dvd irot. aztan a vege az lett, hogy a sony ausztriatol hozott be valaki 500 darabot... 

Szerkesztette: SFIJ 2005. 03. 22. 17:33 -kor

[Laa-Yosh]

A 3D grafika egyik legidiótább jellegzetessége az egységsugarú userek körében a raytracing túlmisztifikálása... eh... évek óta nem trace-eltünk semmit renderben, és textúra bake-eléshez is csak minimálisat...

[Elric]

vers, a 4 argumentumos procik altalaban DSP-k, de minden olyan CPU ami tud FMAC-ot vagy MAC-ot az altalaban rendelkezik legalabb egy de inkabb ket 4 argumentumos utasitassal.
Elric

[vers]

Idézet: Laa-Yosh - Dátum: 2005. márc. 23., szerda - 22:45

A 3D grafika egyik legidiótább jellegzetessége az egységsugarú userek körében a raytracing túlmisztifikálása... eh... évek óta nem trace-eltünk semmit renderben, és textúra bake-eléshez is csak minimálisat...

a raytracingel semmi gond nincs, elöbb utobb ugyis leváltja a mai fillezö algoritmusokat, a kérdés csak az hogy mikor, lehet hogy a ps3 már részlegesen használni fogja , kitudja

mindenesetre érdekes hogy a sony R&D-nél  dolgozo magyar srác pont raytracert ir szabad idejében. érdemes chekkelni: http://www.equinox3d.com/index.html

"Welcome to the home of EQUINOX-3D
The 3D modeler with the fastest, fully integrated ray-tracer.
Because "rasterization is so 20th century™"
"

[vers]

Idézet: Elric - Dátum: 2005. márc. 24., csütörtök - 0:12

vers, a 4 argumentumos procik altalaban DSP-k, de minden olyan CPU ami tud FMAC-ot vagy MAC-ot az altalaban rendelkezik legalabb egy de inkabb ket 4 argumentumos utasitassal.
Elric

van 4 argumentumu utasitása szinte mindegyik risc-nek , csakhogy a 4 -ik regiszter általában az accumulator
de a cellnél mintha nem igy lenne, a regiszterfile 3 regolvasással és egy irással rendelkezik, tehát olyan mintha mindegyik utasitás 4 reges lenne, ami érdekes mivel tudva hogy 32 bitesek az utasitások, és van 128 regiszter amit 7 bit ir le, és 4*7 az 28, tehát marad 4 bit az utasitás opcode-ra???
vagy az egyik forrás maga a cél is , nemtudni de mindenképpen érdekes...

[vers]

asszem eddig ez a legjobb kép:


[ Kattints ide a teljes méretû képhez ]

[Elric]

Huhhh, vers te mirol beszelsz? Milyen accumulator? Milyen RISC-ben?
Aztan meg mi koze a "minden utasitas"-hoz annak, hogy 3 read es egy write portja van egy register file-nak. Sot, tovabb megyek, mi koze ennek egyaltalaban az utasitasokhoz? Szerinted egy atlagos 4 utas szuperskalar chip eseteben hany read es write portja van egy register file-nak???
Elric

[vers]

Idézet: Elric - Dátum: 2005. márc. 24., csütörtök - 23:29

Huhhh, vers te mirol beszelsz? Milyen accumulator? Milyen RISC-ben?
Aztan meg mi koze a "minden utasitas"-hoz annak, hogy 3 read es egy write portja van egy register file-nak. Sot, tovabb megyek, mi koze ennek egyaltalaban az utasitasokhoz? Szerinted egy atlagos 4 utas szuperskalar chip eseteben hany read es write portja van egy register file-nak???
Elric

pédául a ps2 risc procijában van ilyen utasitás :

Rd=ACC+Rs*Rt

tehát 4 regiszterel dolgozik
és az SPE procikban , a képen láthato 3 reget olvas be , 1-et ir ki,



na szoval a regfile-nak összesen 6 read és 2 write portja van , mindegyik pipelinehoz 3-1,
ez nem azt jelenti hogy mindegyik utasitás ki is használja hanem csak azt hogy van pár köztük ami igen,
csak a kérdés az hogy hogyan

Szerkesztette: vers 2005. 03. 25. 01:35 -kor

[Rive]

Idézet: vers - Dátum: 2005. márc. 25., péntek - 1:06

na szoval a regfile-nak összesen 6 read és 2 write portja van , mindegyik pipelinehoz 3-1,

Izé

Ezt én a hlyedbn inkább hagyám. Egyrészt azért, mert az utasításoperandusok száma nem feltétlenül határozza meg a proci belsõ buszainak a szerkezetét - egy csumpi egybuszos, 'nyócbit' procinak is lehetnek sokoperandusos utasításai -, másrészt meg, ha a Te logikádat követjük, akkor pl. a BIU hol nyomul? Elég autonóm egység, minden további nélkül tekinthetõ önálló pipeline-nak... (Merhogy az is - bizonyos értelemben )

[Elric]

vers, szerinted az a pelda mi, amit leirtal??? Az bizony egy szep MAC utasitas....
Egyebkent bizonyos RISC-eknel az acc nem acc, hanem az is egy cimezheto regiszter, de ettol meg ez az utasitas egy MAC. Egyebkent lehet MSUB is, az is negy argumentumos lesz.  Megnyugtatlak a vilag piacanak legtobb RISC-jeben ahol van MAC/FMAC ott altalaban negy argumentumos az utasitas es abban nincs acc.
Elric

[vers]

Idézet: Elric - Dátum: 2005. márc. 25., péntek - 9:29

vers, szerinted az a pelda mi, amit leirtal??? Az bizony egy szep MAC utasitas....
Egyebkent bizonyos RISC-eknel az acc nem acc, hanem az is egy cimezheto regiszter, de ettol meg ez az utasitas egy MAC. Egyebkent lehet MSUB is, az is negy argumentumos lesz.  Megnyugtatlak a vilag piacanak legtobb RISC-jeben ahol van MAC/FMAC ott altalaban negy argumentumos az utasitas es abban nincs acc.
Elric

értem én , csak a többi risc általában 32 regiszterrel rendelkezik, ahol simán megoldhato a 4 regiszter, de 128 regiszternél már nem annyira, mivel a 32 bites utasitás kod hossz nem lenne elég

ha jol emlékszem itaniumon is 128 bitben van 3 utasitás ott se volt elég a 32 bit egy utasitásra, persze most  ez lehet hülyeség mer van vagy 10 éve mikor erröl olvastam...

Szerkesztette: vers 2005. 03. 25. 11:36 -kor

[SFIJ]

Idézet: vers - Dátum: 2005. márc. 25., péntek - 11:33

értem én , csak a többi risc általában 32 regiszterrel rendelkezik, ahol simán megoldhato a 4 regiszter, de 128 regiszternél már nem annyira, mivel a 32 bites utasitás kod hossz nem lenne elég

ha jol emlékszem itaniumon is 128 bitben van 3 utasitás ott se volt elég a 32 bit egy utasitásra, persze most  ez lehet hülyeség mer van vagy 10 éve mikor erröl olvastam...

nos már mért ne lenne elég 32 bit 4 regiszter szelekióra? 128 regiszter címzésére ugye 7 bit kell, 4 regiszter esetén ez 28 bit, maradt 4 bit az opkódnak, oké csak 3, mert 1 bit jelöli a 4 targetû utasításokat. 8 különbözõ 4 targetû utasítás meg több mint elég

Szerkesztette: SFIJ 2005. 03. 25. 14:12 -kor

[vers]

Idézet: SFIJ - Dátum: 2005. márc. 25., péntek - 13:03

nos már mért ne lenne elég 32 bit 4 regiszter szelekióra? 128 regiszter címzésére ugye 7 bit kell, 4 regiszter esetén ez 28 bit, maradt 4 bit az opkódnak, oké csak 3, mert 1 bit jelöli a 4 targetû utasításokat. 8 különbözõ 4 targetû utasítás meg több mint elég

na erre voltam kiváncsi, thx, igy tényleg jo, bár maszkolni nem lehet a regiszterben lévö adatokat, most igy hirtelen nemtudom mennyire fontos  ez

Szerkesztette: vers 2005. 03. 25. 14:20 -kor

[Elric]

Bocs, most mar ertem mit nem ertettel! Igazad van, az Itaniumban tenyleg nem eleg, ott 41 bit van azt hiszem - bocs, most eppen nem jut eszembe a tenyleges szam -, de ennek nem a 128-bites regiszterek az okai, hanem a predikatum logika. A maradek 5 bit meg a mask-ra megy el...
SFIJ, kosz, en sajnos sajat nagysagomtol elvakulva nem is ertettem, hogy hogy nem jon ossze.
Elric

[SFIJ]

urak errõl a maszkolásról beszéljetek bõven. mit is kell maszkolni és fõleg miért?

[vers]

Idézet: SFIJ - Dátum: 2005. márc. 25., péntek - 23:56

urak errõl a maszkolásról beszéljetek bõven. mit is kell maszkolni és fõleg miért?

a 128 bites regiszterekben 4 darab 32 bites adat van ugye, na  a maszk bitekkel  lehet beállitani melyik adat vegyen részt az utasitásban

pl:  add.xyzw r0,r1,r2.x

ez volt ps2-n, de az "AoS" tipusu, tehát egy regiszterben egy vector  adatai vannak(xyzw),

a cell "SoA" tipus ami az igazi SIMD , mert  a regiszter csak egyféle adatot tárol pl csak X-et
azt nem tudom szükség van e egyáltalán maszk bitekre ebben az esetben, mert ilyen procit még nem programoztam , jobban át kéne gondolnom....

[Laa-Yosh]

Idézet: vers - Dátum: 2005. márc. 24., csütörtök - 9:11

a raytracingel semmi gond nincs, elöbb utobb ugyis leváltja a mai fillezö algoritmusokat, a kérdés csak az hogy mikor, lehet hogy a ps3 már részlegesen használni fogja , kitudja

Ez sajnos nem fogadható el használható érvként a raytracing mellett, viszont elég sok szól ellene.
Pl:
- Mihez van feltétlenül szükség raytracingre?
A tükrözõdés már most is megoldható enviroment mapekkel, fénytörõ tárgyakra is vannak pixel shaderes megoldások. Az átlagos user már most sem venné észre a különbséget.
A teljes jelenetre alkalmazott globális illuminációs megoldások közös nevezõje, hogy most érték el az 1 db. gömb + 1 db síklap alacsony felbontásban, rendkívül zajos (randa) eredménnyel 3-4 fps sebességû frissítést produkál; komplexebb jelenetekre belátható idõn belül nem lesz alkalmas. Fõleg hogy a geometria összetettsége folyamatosan növekszik (pl amikor bejön a displacement mapping meg hozzá valamilyen nézõpont-függõ tesszeláció).

- Milyen sebességgel futna valójában egy teljesen raytracingre épülõ algoritmus?
Elméletben egy bizonyos poligonszám felett gyorsabb a raytracing a scanline renderelésnél, nem kell linket keresned hozzá Viszont a gyakorlatban van egy fontos különbség, és ez az adatok elérése.
Scanline renderelésnél streamelheted az adatokat - geometriát, animációt, textúrákat, shadereket - és mindig csak arra a pár tucat vagy száz Kbyte-ra van szükséged a renderelõ pipe-ban, ami az éppen feldolgozott (jelenleg 4 pixeles) képrészleten látszik a kamera felõl. Ez lehetõvé teszi, hogy mély futószalagot használjanak, ami elbírja a magas memória-késleltetést és jól cache-elhetõ az egész. Nem véletlen hogy mind az ATI mind az Nvidia legféltettebb titkai közé tartozik a textúra cache-ük felépítése és mûködése, gyakorlatilag egy deka info nincs még a méretükrõl sem.
A feldolgozás tehát szépen poligononként megy, azon belül spanenként, és mindig elõre tudod hogy kábé milyen adat kell majd, és szépen el tudod tolni a sorozatban érkezõ elemek feldolgozási fázisait. Erre a streamelésre a PS2 a legjobb példa, szóval tudnod kell hogy mirõl beszélek
Raytrace esetén viszont a sugarad akárhová pattanhat a scenében, ezért bármelyik adatodra bármikor szükség lehet. Nehezen cache-elhetõ, lerohadhat bármikor az egész render ha nem férsz be a memóriába, szóval bármilyen tükrözõdés/fénytörés esetén pillanatok alatt szét lehet lassítani az egészet megfelelõ méretû dataseteken.
Ráadásul a poligonszám sem jó érv, mert egyértelmûen nem fogunk 1-2 millió poligonosnál nagyobb scenékhez eljutni, helyette átáll a realtime ipar is a magasbbrendû felületekre (kvázi szabvány a catmull-clark subdivision surface). Ezt meg a sebesség érdekében úgyis csak render közben érdemes tesszelálni, és ez megint csak a scanline megközelítéssel oldható meg jobban.


Egyébként pedig a vizuális effektusokkal illetve egész estés CG animációval foglalkozó ipar az esetek 90-95%-ában scanline renderelést használ és a raytracinget csak akkor veszi elõ, ha muszáj - de akkor is inkább úgy alkalmazzák (vagy alkalmazzuk, ha fel akarok vágni ), hogy pl. a statikus bevilágítás kerül egy lightmap textúrába. Egy valós idejû, interaktív alkalmazásban ezek a csalások nem mindig engedhetõek meg, különösen pl. a bevilágítás terén (ma még sok a lightmap, de egyértelmûen a dinamikus/statikus  bevilágítási modellek egészséges kombinálása a jövõ).

Szóval, fenntartom hogy a raytracing célhardveres gyorsítása kidobott energia és ezért kerülendõ. Az, hogy tudós/matekos/kóder fejjel esetleg szimpatikusabb megoldás, sajnos nem elegendõ érv, mert a grafika alapvetõen a látványról kell hogy szóljon, és ezért a mûvészeti szempontok a fontosabbak, ezeket az igényeket kell kiszolgálnia a technológiának.

[vers]

a raytrace elönyét én abban látom hogy "gyorsabb" a rasterezésnél, és az árnyékok is tökéletesek, a tükrözödés annyira nem számit azt könnyü csalni
a trace hátránya szerintem nem az hogy nem tudod streamelni , mert tudod valamilyen szinten,
a fö probléma a döféspont keresés, poly-ray között  gyors de ki akar polyt használni, a gondok a magasabbrendü felületekkel vannak és a displacement mappingal, ezek a memoria  kihasználása miatt nagyon fontosak , de pont ezek lassitják a trace-t annyira hogy nem jön be az elmélet
az nvidia uj csalása kicsit már trace szerü a perpixel displacementre gondolok, de az se old meg mindent, gondoljunk csak egy displacement mapos görbe felület önárnyékára:)
ha a ps3 csak az árnyékok számolásához használna RT-t én már elégedett lennék
egyszer régen számolgattam mikor érné meg a RT-t használni, 100 milliárd poly fölött lene a határ és akkor még nem számoltam bele az egyre gyorsabb raszterezö procikat, viszont ekkora polyszámhoz meg már brutális felbontás kéne , és mivel tudjuk hogy a RT eröforrásigénye a felbontástol függ a leginkább, ezért ez a tulajdonsága az RT-nek lehetséges hogy meggátolja a valos alkalmazását
hacsak  valaki ki nem talál valami uj felületleiró rendszert, talán a wavelet lesz a megmentö kitudja...

a mai realtime grafika egy tömény fake gyüjtemény, elöbb utobb az elmélet ugyis utat tör magának és az RT  fog uralkodni , lehet hogy csak 10-30 év mulva de fog, ha a mai technologiával RT  -s GPU-t csinálnának nem lenne sokkal rosszabb mint a mai raszterezö procik csak az átmenet a probléma a 2 technika között sajnos, mind szoftverben mind hardverben , mert a nullárol kéne kezdeni

Szerkesztette: vers 2005. 03. 26. 23:28 -kor