[SFIJ]

Idézet: special - Dátum: 2007. aug. 11., szombat - 12:32

Elõször is a kérdés az, hogy valóban szükség van-e DP-re mindenhol a te munkádhoz, és nem elég esetleg csak a final rendert azzal végeztetni. Ez esetben ugyanis a munka folyhatna SP-ben, és itt a Cellnek nem lenne ellenfél még a leggyorsabb négymagos x86 chip sem.

mivel a renderek nagytöbbsége nem mérnöki tervezés igényû, a scenek nagyrésze nem haladja meg az 1 négyzetkilométert se, siman mehetne az egesz single floatban, csak akkor a szoftban levõ algókat validálni kéne numerikus stabilitásra, ami ugye cost. ehelyett az van hogy járjon inkább DP-ben, azmár tutira elég, nincs vele macera

Idézet: special - Dátum: 2007. aug. 11., szombat - 12:32

A másik dolog, hogy a peak throughputot összehasonlítása az alapvetõ architekturális és mikroarchitekturális képességek miatt kevéssé beszédes. A Cell nagyobb belsõ és külsõ sávszélességei, gazdagabb register setje és in-order jellege miatt _kioptimalizált_ kód esetén nagyobb hatékonyságot érhet el, mint egy ooo x86-os chip -- és vica versa: nem optimalizált, vagy az architekturának nem fekvõ (nehezen párhuzamsítható, rengeteg adatfüggõség, branch intenzív) kód esetén a teljesítmény a béka segge alatt van.

errõl van szó. a mental szereti a pénzt, de megdolgozni érte, kódot optimálni már nemigazán akar. teljesen egyértelmû, hogy egy belõtt jó SP-s cuccal, a sonytól vett PS3 mainboard kártákkal nagyon tiptop kis blade rackeket lehetne csinálni, gazdaságosan és egyszerûen.

Szerkesztette: SFIJ 2007. 08. 11. 12:50 -kor

[SFIJ]

Idézet: special - Dátum: 2007. aug. 11., szombat - 12:42

dn.r, készült már akadémiai papír a cell ray-tracing képességérõl, érdemes lehet elolvasni. azoknak, akiket a csík hosszúsága érdekel, akkor a kutatás arra a következtetésre jutott, hogy egy cell SPE egy x86-os maggal azonos teljesítmény tud nagyjából ray-tracingben -- optimalizált kóddal.

3 különbözõ scene, frame per sec. egymagos Opteron, a többi érthetõ.

           
ray casting,                                                       
  2.4GHz x86        7,2                     3                   2,5
 2.4GHz SPE 7       7,4       3,0%        2,6     -13,0%        1,9     -24,0%
  Single-Cell      58,1         8x         20       6,6x       16,2       6,4x
   Dual-Cell      110,9      15,4x       37,3      12,4x       30,6      12,2x
    PS3-Cell       67,8        9,4       23,2       7,7x       18,9       7,5x

http://graphics.cs.u...in/cellrt06.pdf

special ne szivassá' már minket ez ray casting, az kicsit más. ezmár pc desktopon is megy, valós idõben.

[special]

más, de talán relevánsabb, mint bármi más bench, ami eddig elõkerült. ha tudsz, hozzál ray tracing számokat.

[bogdan]

az elonezeti kep, amit birizgalsz, az komoly munkanal nem visz el teljesitmenyt. a komoly munkaban, ha jol ertem, orakig-napokig szamol a gep. az elokeszuleti munka az lopikula ehhez kepest.

[SFIJ]

Idézet: special - Dátum: 2007. aug. 11., szombat - 14:35

más, de talán relevánsabb, mint bármi más bench, ami eddig elõkerült. ha tudsz, hozzál ray tracing számokat.

várok ITEM-re hogy valamit óberkodjon már a blenderrel

[d n . r]

Single vs. double kérdéshez, a Gelato dokumentációjában nem találtam errõl semmit, viszont gondoltam rákeresek az open-source pov-ray-nél írnak-e errõl valamit, és ezt találtam (a 3dnow! és az Altivec-támogatás boncolgatásánál került elõ):

http://www.povray.or...view/3.6.1/185/

Idézet

3DNow uses single precision numbers while POV-Ray needs (yes, it needs) double precision numbers. Single precision is not enough (this has been tested in practice).
(...)
Note: There are a few things in POV-Ray that use single precision math (such as color handling). This is one field where some optimization might be possible without degrading the image quality.

http://mac.povray.org/support/faq.html

Idézet

Now, POV-Ray is a 3D application, but wait, there is another significant limitation! AltiVec uses single-precision floating-point numbers (there is no double-precision supported in the AltiVec architecture). By far the most floating-point code in POV-Ray uses (and needs) double-precision floating-point numbers. AltiVec (instructions) simply cannot be used to speed up those. So to make it short: AltiVec is good for a lot of things, but not high quality ray tracing.

Ha meg elég valamihez a SP, akkor én a GPU-kra fogadnék (a G80 már tavaly 500 gflops fölött tudott), de ami az igazán érdekes, hogy miközben a Gelato DP-képessége után kutattam:

http://forums.nvidia...showtopic=28383

Idézet

from the NVIDIA CUDA Release Notes Version 0.8 file:

Q: Does CUDA support Double Precision Floating Point arithmetic?

A: CUDA supports the C "double" data type. However on G80
(e.g. GeForce 8800) GPUs, these types will get demoted to 32-bit
floats. NVIDIA GPUs supporting double precision in hardware will
become available in late 2007.

[Laa-Yosh]

Idézet: SFIJ - Dátum: 2007. aug. 10., péntek - 23:11

ugye tod miaz, hogy rendrefarm? 

Nálunk két blade van, 28 node; dual Xeon 2x2GB memória, lassan három éve húzzák a szekeret. Kinéz majd egy bõvítés, mert már most is csak projekt végén tudunk normális minõségû rendereket indítani, az összes megelõzõ iteráció alulmintavételezett (egy átlag jelenetet legalább 10-20 alkalommal le kell renderelni és folyamatosan finomítgatni, nem ám majd csak egyszer...). Mostanában már pont csak MR megy rajtuk, PRMant hanyagoljuk.

Ami tuti, hogy 3D grafikához double prec kell, és a 2GB memória kell. Enélkül semmit sem ér. Lécci ne akarjon ebben senki szakérteni, aki PovRay szinteken mozog.

A bibi nyilván az, hogy ha nem PS3-akból építed a farmot akkor drága lesz. Ráadásul itt olyan tényezõk is vannak, hogy mondjuk a renderfarm, a storage meg a többi szerverek mind bent ülnek egy kis szobában, amit a 39 fokban néha már nem bírt el a speckó légkondi sem (mert beszívta ezeket a nyárfákról leszálló kis szöszöket, báz). Plusz súlyra sem mindegy, hogy mekkora a géptermed, nálunk a legtöbb irodaházbeli emelet nem bír ekkora per négyzetméter terhelést.

Fenti okok miatt nyilván az se reális alternatíva hogy összerakunk pár tucat selfmade gépet, fõleg százas nagyságrendû node esetén. Nem férnek el, nincs elég áram, kemencét csinálnak a szobából, satöbbi. Szóval az árban a blade kategóriával kell versenyeznie.

Bónusznak viszont nem csak MR fut elosztott renderként; az összes kompozit is ezen megy a Digital Domain által fejlesztett Nuke szoftverrel, de lehetne helyette Linuxos Shake, vagy win32 Digital Fusion vagy ilyesmi. Ja, és nem árt ha tudjuk saját fejlesztésû szoftverrel elosztani az erõforrásokat, pucolni a vinyót, letükrözni lokális eléréshez adatokat. Ja meg a ruhaszimulációt is kiküldjük valamelyik node-ra, amin parancssoros Mayát futtatva számol. Szóval, ha csak MR van arra a Celles gépre, akkor eleve nem lehet homogén a renderfarm, ami a saját gyártmányú szoftverek miatt plusz munkaidõ és odafigyelés, és ez egymagában kiütheti az ár/teljesítménybeli elõnyt.

[Laa-Yosh]

Idézet

egy rendert ugyanis fel lehet kaszabolni olyan méretû jobokra amikmár simán beleférnek a PS3 256 ramjába.

Lécci ne beszéljünk hülyeségeket. A piacon kapható off-the-shelf render szoftverek még elindulni se nagyon tudnak 256 megán, a mozgatott adatmennyiség akkora nagy hogy a 2 GB memóriával szerelt gépeken is mindenféle lazy loading meg cache varázslás kell, hogy egyáltalán lefusson a render. Eleve egy raytrace jelenetnél a BSP meg voxelekre darabolás felzabálná ezt a minimál mennyiséget sztem...

[Laa-Yosh]

Idézet: SFIJ - Dátum: 2007. aug. 11., szombat - 10:45

hánemtom kérdezd meg spielbergéket akik a méregdrága SGI onyxjaikat lecserélték büdzsé PCkre anno amikor a világban a lángelmék még nemis gondoltak arra, hogy a PCt ígyis lehet használni.

Te pontosan mire gondolsz "Spielbergék" alatt? Az ILM Lucas cége és az öregnek nem sok köze van a tech részletekhez.

Konkrétan az ILM az utolsók között állt át PC-re valamikor 3-4 éve, amikor végre kijött minden fontosabb kereskedelmi forgalomban kapható szoftverük Linuxra és megérte nekiállni átírni a saját cuccaikat is Irixrõl. Tudod egy ilyen stúdióban olyan mennyiségû saját szoftver van, hogy csak baromi lassan tudnak irányt váltani...

[Laa-Yosh]

Idézet: SFIJ - Dátum: 2007. aug. 11., szombat - 11:02

deha kicsit csipáznál itten, megkértem ITEm-et, nézze meg mit mûvel a kecskéjén a blender

Ne röhögtess a Blenderrel lécci...

Idézet

ILM, Dreamworks saját szoftverhergelõ R&D-vel operál, meghát odaszólnak a mentalnak, hogy jövõ ilyenkorra legyen meg a PS3 verzió és megvan...

Részben igaz, mert Maya, XSI, 3ds max, Photoshop meg ilyenek is vannak; továbbá sok évnyi termés az a saját kód, marhára nem fogják egy nap alatt totál új architektúrára átállítani.

[Laa-Yosh]

Idézet: special - Dátum: 2007. aug. 11., szombat - 12:32

Elõször is a kérdés az, hogy valóban szükség van-e DP-re mindenhol a te munkádhoz, és nem elég esetleg csak a final rendert azzal végeztetni. Ez esetben ugyanis a munka folyhatna SP-ben, és itt a Cellnek nem lenne ellenfél még a leggyorsabb négymagos x86 chip sem.

Renderhez DP kell. Ezzel ne vitatkozzunk már lécci. És itt nem a színmélység hanem a geometria miatt, egyszerûen nem elég a szimpla precizitás ahhoz a marha sok egymásra épülõ matekhoz.

[Laa-Yosh]

Idézet: special - Dátum: 2007. aug. 11., szombat - 12:42

dn.r, készült már akadémiai papír a cell ray-tracing képességérõl, érdemes lehet elolvasni. azoknak, akiket a csík hosszúsága érdekel, akkor a kutatás arra a következtetésre jutott, hogy egy cell SPE egy x86-os maggal azonos teljesítmény tud nagyjából ray-tracingben -- optimalizált kóddal.

Heh, akadémikus raytracer a Mental Ray 20 éve optimalizálgatott szoftvere helyett, mint mérce, na ne vicceljünk már. A render alkalmazások naon is szépen rá vannak optimalizálva az x86-ra, és csak akkor állnak neki trace-elni, ha nagyon kell... még az MR-ben is scanline az alap render üzemmód.

[Laa-Yosh]

Idézet: special - Dátum: 2007. aug. 11., szombat - 13:07

hát én valami szerkesztõi preview nézetre gondoltam, ahol munka közben lehet mozgatni, forgatni a dolgokat, és csak a kívánt részeket rendereltetin DP-ben, meg a végsõ képet.

Eccer majd megírom, hogy néz ki a workflow CG animációban, de nem így, egyelõre érd be ennyivel...

Egy darab autó meg hol van mondjuk a Pelennor mezõhöz, ami x-szer 10 kilométer, és a repkedõ nazguloktól le akarjuk vinni a kamerát a fûcsomókig? Ott fog elvérezni az SP, de keményen...

[special]

Nem vitáztam én, feltettem egy kérdést. Tisztában vagyok vele, hogy a pontatlanság halmozódása miatt nem megengedhetõ egy complex scene-en az SP, viszont mivel nem foglalkozom ilyennel, nem tudom, így felvetettem, hogy "elõnézeti" képen, szerkesztés közben nem lehet-e legalább részben SP-t alkalmazni (pl. az éppen nem editált részek közelítõ megjelenítéséhez). persze ha igen, akkor is csak egy elméleti lehetõség, mert szoftverben implementálni kellene. De ha azt mondod, nem, akkor nem.

Szerkesztette: special 2007. 08. 11. 18:45 -kor

[Laa-Yosh]

Idézet: SFIJ - Dátum: 2007. aug. 11., szombat - 13:46

mivel a renderek nagytöbbsége nem mérnöki tervezés igényû, a scenek nagyrésze nem haladja meg az 1 négyzetkilométert se, siman mehetne az egesz single floatban, csak akkor a szoftban levõ algókat validálni kéne numerikus stabilitásra, ami ugye cost. ehelyett az van hogy járjon inkább DP-ben, azmár tutira elég, nincs vele macera

errõl van szó. a mental szereti a pénzt, de megdolgozni érte, kódot optimálni már nemigazán akar. teljesen egyértelmû, hogy egy belõtt jó SP-s cuccal, a sonytól vett PS3 mainboard kártákkal nagyon tiptop kis blade rackeket lehetne csinálni, gazdaságosan és egyszerûen.

Ne legyél már ekkora szakértõ

Pont az MR listán írta egy kóderük pár éve, hogy tipikus példa egy kliens akinél a komplett reptér is adott, meg a pilótafülke belseje, és nem szeretné ha precizitás parák miatt átlógnának a kapcsolók a mûszerfalon, meg a fák a kifutópálya túlsó végén egymáson. És akkor még nincs displacement mapping ami megintcsak szeret némi kifutást magának a közeli képeken...

Kell a DP, és kész, 32 bites float adat per koordináta az lóf***.

[Laa-Yosh]

Idézet: special - Dátum: 2007. aug. 11., szombat - 14:35

más, de talán relevánsabb, mint bármi más bench, ami eddig elõkerült. ha tudsz, hozzál ray tracing számokat.

Raycasting: sugár kimegy a kamerából, eltalál valamit, vége. Szépen lehet streamelni az adatokat.

Raytracing: sugár kimegy a kamerából, eltalál valamit akkor visszapattan vagy irányt vált. Adatelérés ide-oda ugrál teljesen random (pl. felületi egyenetlenség is szanaszét szórja akár egy pixelen belül is). Cell SPE harakirit követ el unalmában.

[special]

Megtaláltam azt a videót, érdekességnek: http://www.youtube.c...h?v=oLte5f34ya8

[Laa-Yosh]

Idézet: bogdan - Dátum: 2007. aug. 11., szombat - 15:20

az elonezeti kep, amit birizgalsz, az komoly munkanal nem visz el teljesitmenyt. a komoly munkaban, ha jol ertem, orakig-napokig szamol a gep. az elokeszuleti munka az lopikula ehhez kepest.

A CG alapvetõen iteratív. Ideális környezetben az animátor minden este elindítja az aznap piszkált jelenetet és másnap megnézik a górék a vetítõszobában mozivásznon, hogy mûködik-e. Csak úgy lehet megmondani, ha a végsõ felbontásban és részletességgel látod, és attól lesz jó, ha minél többet lehet finomítani rajta. Tudjátok, a Pixarnál évente 1-2 percet animál le egy ember, azért van 50 animátor egy filmre.

(Ehhez kell egyébként a sok kód egy jelentõs része, hogy amikor a mûvészúr este megnyomja a buttont, akkro abból automatikusan legyen indítgatva sok kis command line taszk, ami elõször átrakja az anim modellrõl a render modellre, ami többnyire túl komplex ahhoz hogy akár 1fps visszajátszást elérjen; aztán mondjuk ruhát szimulál rá, aztán leküldi a szükséges rendert, aztán a kész rétegekbõl leküldi az új kompozitot, és a végén még emailt is küld az illetékeseknek. És nem kell közben valami dodinak nyomkodni a gombokat, hogy az új adat végigmenjen a pipeline-on.)

Az nem mûxik, hogy majd a végsõ render megy csak fullosan, és akkor vesszük észre hogy rossz a textúra, hibás az animáció, vagy túl sok idõbe kerül és nem lesz kész határidõre. Mindig is olyan gyors volt a render, hogy a stúdió aznapi munkájáról másnapra nézhetõ kész szekvencia legyen, különben vakon dolgozhatna a nép és az nem jó ötlet.
Ha meg egy képkocka 10-20 órát renderel, akkor meg annyi gépet kell venni, hogy belátható idõn belül így is lemenjen minden. Ezért van 1000+ processzora csak a renderfarmban az ILM méretû cégeknek.

Szerkesztette: Laa-Yosh 2007. 08. 11. 19:33 -kor

[special]

LY, a ray tracing a celles fejlesztések egyik kiemelt célterülete, és születtek már rá proof-of-concept technológiai demók bemutatók, versenyek alkalmával.

Blue Steel ray-tracer, 4 hét alatt tervezték meg és programozták le: http://www.youtube.c...h?v=C3ARXUSKXAM

Blie Steel prez: http://cag.csail.mit.edu/ps3/projects/blue...-blue-steel.pdf

Prezentáció a Cell célterületeirõl, képességeirõl: http://www.gpgpu.org/sc2006/workshop/prese...ni_IBM_Cell.pdf

30. slide-tól.

Szerkesztette: special 2007. 08. 16. 10:03 -kor

[special]

még egy régebbi videók, csak mert témába vág. több elsõgenerációs QS20-as dual Cell blade renderel klaszterben, real-time, ray-tracing.

http://www.youtube.c...h?v=eEg7q2lk3QM

Szerkesztette: special 2007. 08. 16. 10:00 -kor