Új hozzászólás Aktív témák
-
#241
rocket
nagyúr
shabbarulez
#240
rocket
nagyúr
válasz
shabbarulez
#240
üzenetére
Backup plan, ha megse lenne igazuk mi varhato majd
-
#240
shabbarulez
őstag
shabbarulez
őstag
NVIDIA Acquires RayScale Software - Bringing Ray Tracing to the GPU [link]
Úgy tűnik az Nvidia is helyezkedik és nyit az Intel Larrebee ray tracing projectjével szemben.
-
ddekany
veterán
Nem tudom ez alatt a "térszöges" szórt fény számítás alatt pontosan mire gondoljak, szóval ehhez nem tudok hozzászólni. Minden esetre én nem tudtok olyan szórt fénnyel normális minőségben számoló módszerről, ami akárcsak esélyesnek látszik valós idejű 3D esetén. Ha valaki tud ilyet, akkor adja meg itt a linket. Az sima Ambient Occlusion az nem ér, mert az még nagyon kevés a boldogsághoz (bár az is valami, és raszterrel nekem elég problémásnak tűnik).
"Ezeket raszternál nem tudom, hogy lehetne kezelni. A raszternél tudomásom szerint minden ilyen finomság csak spéci effektezéssel megy"
A konkrét valós időre esélyes global illumination számító módszer ismerete nélkül nehéz is lenne megmondani... (Pl. a tipikus "csempékre" felosztós radiance számítás esetén mindegynek tűnik hogy raszer vagy ray-trace, de persze az sehogy sem realtime, szóval az itt nem játszik.)
-
vati
senior tag
A fényforrások véges (>0) méretének és az indirekt megvilágításnak a problémáját a gyakorlati raytracing implementációk esetében le lehetne kezelni, nem túl rossz közelítésekkel. Persze nem olcsón... egy fényforrás helyett lesz pl. 100.
A véges méretre pl.azt, hogy vegyük a fényforrás kerületének N(~8-16) pontját, és nézzük meg, ebből hány van takarásban, ebből elég jó függvény jöhet ki a részleges árnyék mélységére. A szórt megvilágításra pl. lehet diszkretizálni térszögekre a környezetet, és ezeket egyenként kiterjedt fényforrásként kezelni, miután ismert az átlagos színük és fényességük. Plusz ereje lehet a módszernek, hogy lehet iterálni: első lépésben nem vesszük figyelembe a szórt megvilágítást (másodlagos fényforrások) a második, többedik iterációban már az előzőben megkapott környezet megvilágítottság is belejátszik mint plusz fényforrás. (persze a légköri szóródást direkben bele kell kódolni) Másik iterációs lehetőség, finomítani a környezet mint fényforrás felbontását.
A vége maga a teljes valóságleképzés, illetve amennyire akarjuk ezt közelíteni. De legalább lehetséges, az alapelv elég általános, elég fizikaközeli annyira, hogy megengedje a skálázást.
Végső soron különbséget sem kell tenni a fényforrás és a fényvisszaverő testek között. közöEzeket raszternál nem tudom, hogy lehetne kezelni. A raszternél tudomásom szerint minden ilyen finomság csak spéci effektezéssel megy, (ha megy) változó és limitált eredményességgel.
-
ddekany
veterán
"- a grafika jövője szerintem is a ray-tracing. A raszterezés [...] az elv nem alkalmas a valóságos látvány kompromisszumok nélküli visszaadására [...]"
Akkor szögezzük le, hogy mit is értünk ray-tracing alatt. Szerintem azt, mikor a szemből kiindulva a képernyő minden egyes pixelén keresztül indítasz egy (vagy jobb minőség érdekében néhány) sugarat, és azt követed, amíg el nem talál egy tárgyat. Ekkor ebből a metszési pontól (legyen ez a pont M) húzol egy sugarat miden egyes világítótestek felé (pontszerűek), és ez utóbbi sugárnak felülettel bezárt szöge és a világítótest ereje és színe szerint megállapítod a felület látszólagos világosságát és színét, ill. ha a sugár metszett vmi nem áttetszőt a fényforrás felé való útja során, akkor azt mondod, hogy árnyékban van a felület az adott fényforrás vonatkozásában. Aztán, ha felületed tükröző tulajdonsággal is bír, akkor megint csak az M pontból húzol egy a tökéletes visszaverés szabályainak megfelelő irányú sugarat, hogy megállapítsd, hogy mit fog visszatükrözni az M pont a szemedbe, és innentől a folyamat hasonló mint amikor a pixelen keresztül bocsájtottad ki a sugarat, ismétli magát, tehát követi a sokszoros verődéseket is. Ja, meg még van olyan, hogy ha eltalálsz egy felületet, akkor nem csak a fényforrás felé és a tükröző irányban indul egy sugár M-ből, hanem a felületen keresztül is (mert az részben áttetsző, pl. üveg), esetleg fénytörés miatt eltérítve. Ezt amúgy Whitted ray-tracingnak szokás hívni.
Na most ezzel a modellel egy fatálisan nagy gond van, hogy nem kezeli jól az indirekt megvilágítást, eltekintve a tökéletes tükrözés esetétől. Más szóval, nem kezeli jól a fény szóródását. Annyit tesz ezen a téren, hogy bocsájt egy sugarat a világítótest felé, és a szögből megállapítja a felület világosságát. Ez egy teljesen jó becslés, csak az a baj, hogy valósában nem csak néhány pontszerű világítótest van (és most ne foglalkozzunk vele, hogy a villanykörte nem pontszerű, mert az a legkisebb gond), hanem minden egyes tárgy minden egyes pontja is világítótestként viselkedik. Azért, mert ami beesik rá fény, azt gyakorlatilag véletlenszerű irányokba továbbpattintja, és ezzel olyan, mint ha ott egy pici nagyon halvány villanykörte lenne. És ez a sok kicsi "villanykörte" együtt nagyon jelentősen megváltoztatja a látképet. (Ray-trace-es szemlélettel úgy is megfogalmazhatnánk ezt, hogy csak tökéletes tükrözés van, nincs szórás, viszont a felületek rettentő apró kaotikusan össze-vissza álló lapból állnak. Viszont ezen érződik, hogy elmebeteg mennyiségű sugárral kéne dolgoznunk így, tehát a ray-trace megközelítés itt megbukott.)
A raszteres megközelítés talán legfőbb problémája a valósághűség terén megint csak ez... nem kezeli jól az indirekt megvilágítást. Pont ugyan azt teszi ezen a téren mint ray-trace! Húz egy egyenest a pontszerű világítótest felé, és a bezárt szög alapján megállapítja a világosságot, és ennyi. Ugyan az a nagyon gyenge megközelítő eredményt adó módszer! Igaz, a raszternek a tökéletes tükrözéssel és az árnyékokkal is gondja van. A tökéletes tükrözésnek viszont viszonylag ritkán van szerepe a valósághűég szempontjából, és ha van is, van rá trükkös megoldás, ami elmegy az esetek túlnyomó többségében, mert úgy is csak a gyors benyomás számít. Az árnyékra is van megoldás... jó, nem az igazi, de hát a ray-trace-é sem, mert az meg túl éles árnyékokat ad (mert az a fránya fényszóródás, amit nem szimulál szinte sehogy, az tesz be megint), tehát mindkettőnél trükközni kell az árnyékoknál.
Egy szó mint száz, a ray-trace gyakorlatilag nem ad lényegesen valósághűbb képet. Azért nem, mert a valós környezet nincs teli fényezett és áteresztő-fénytörő tárgyakkal. Ezek a jelenségek egyszerűen nem dominálnak, kivéve persze, ha direkt olyan scene-t építünk ahol igen, és OK, akkor dögösen fog kinézni ray-trace-el, de aztán ennyi, kifújt, ami a valósághűséget illeti.
A kérdés számomra továbbra is csak a skálázódás a scene komplexitással, de erősen dinamikus scence esetén is! Ha a ray-trace-nel ez jobban megy, akkor az lesz a nyerő, amúgy felejthető az egész. Ja, meg még kérdés, hogy ha vmivel tudsz hatékonyan sugarat követni, az még mennyi mindenre lesz jó a játékokban, mert hogy ez egy elég univerzális eszköznek tűnik. Szóval én nem temetem a realtime ray-trace, de a ray-trace valósághűség terén az emberek el vannak tévedve. Amit látnak hú de valósághű képeket, azok nem egyszerűen Whitted ray-trace-el készültek, volt ott más is, pl. valamilyen szórtfény kezelés (global illuminantion), és az végül is raszterre is alkalmazható.
"- a programozás mószertana és eszköztára vsz. nincs felnőve a hardver lehetőségei mellé, itt komoly tartalékok vannak, és egyelőre rossz az irány."
Ne keverjük össze az state-of-the-art cuccok irányát a átlag tendenciájával... A programozás egy fiatal szakma, és igenis erősen fejlődik, pozitív irányba. Más kérdés, hogy a programozó "iparban" is felütötte a "csinálunk sok sz*rt gyorsan és ólcsón" tendencia.
"Azt el tudom képzelni, hogy egy raytracingre kihegyezett processzor HD felbontásban, 30 frame per sec sebességgel renderel valós időben 1-2 teáskannát, egy autómodellt, de hogy egy komplexebb szcenárióra is működjön (pl. aprólékosan modellezett mozgalmas beltéri jelenet) már nem valószínű"
Ez a probléma viszont a rasztert is érinti, szóval a kérdés továbbra is csak az, hogy melyiket fogja jobban érinteni, hasonló minőségű látvány fenntartása mellett.
-
vati
senior tag
Az elkalandozás után csak hogy az ontopic véleményemet is leírjam.
- a grafika jövője szerintem is a ray-tracing. A raszterezés zsákutca, növelhetjük a felbontást, a textúraméreteket, a poligonszámot, az elv nem alkalmas a valóságos látvány kompromisszumok nélküli visszaadására. (a fizikai valóság nem így működik)
- a programozás mószertana és eszköztára vsz. nincs felnőve a hardver lehetőségei mellé, itt komoly tartalékok vannak, és egyelőre rossz az irány.
- a ray-tracing mint számítási probléma elég jól párhuzamosítható -> célproci, jó irány
- ami miatt mégis szkeptikus vagyok, két dolog: 1.) már látszanak a félvezető alapú processzorok teljesítményfokozásának elvi fizikai korlátai, ahol a hardver fejlődés majd falba ütközik. Ez jó esetben >=1 nagyságrend de <2 nagyságrend. 2.) Azt el tudom képzelni, hogy egy raytracingre kihegyezett processzor HD felbontásban, 30 frame per sec sebességgel renderel valós időben 1-2 teáskannát, egy autómodellt, de hogy egy komplexebb szcenárióra is működjön (pl. aprólékosan modellezett mozgalmas beltéri jelenet) már nem valószínű: a modell komplexitás növekedésével itt is elszáll a renderelés számításigénye, pár nagyságrenndel a lehetőségeken túl.
- lehetséges további fejlődési tartalék: interaktív monitor: a látás fiziológiáját figyelembe véve, az "okos" monitor szenzorral figyeli, éppen merre néz a felhasználó. (Egy kis területen látunk valóban élesen, azon kívül gyakorlatilag csak a mozgást érzékeljük a többit az agyunk/szemünk kiszűri, hiába hisszük azt, hogy real-time látjuk. Csak pontatlanul látjuk, részben egy korábbi állapotát érzékelve. Az agy nem pazarolja az energiát fölöslegesen.) Tehát a visszacsatolás hatására a VGA csak a monitornak a látótér közepére eső részére rendereljen nagy tér-és idő felbontásban. A képernyő többi részét ritkábban frissítse, esetleg durvább felbontásban tegye ki a képet. (valahogy úgy, ahogy az MP3 tömörítés is tkp ügyesen becsapja a hallásunkat.)
Persze ez még sci-fi... de tökéletes valóságillúziót csak hasonló módszerekkel lehet majd elérni. Leszámítva a még scifibb módszereket. -
ddekany
veterán
A feketedoboz hegyek egymásraépítése márpedig nem fog alábbhagyni, csak fokozódni. Erre ugyanis nem csak a fejlesztés gyorsítása miatt van szükség, hanem a komplexitás ember által kezelhető szinten tartására, ugyan is amit új alkalmazások megvalósítanak, az egyre komplexebbek és komplexebbek lesz. Mindez ráadásul találkozik azzal, hogy az elérhető munkaerő (programozók) egyre silányabb és silányabb lesz, tehát minél kevesebb dolog van ami rajtuk múlik, annál jobb. A kevés jobb programozó csinálja a fekete dobozokat, a tucatprogramozó meg építkezik belőlük...
-
vati
senior tag
"Megbocsáss, de ma nem így működik a dolog. Az összes komolyabb szoftvert optimalizálják. Hja, nem az egészet: régi szabály, hogy a futásidő 90+ százalékában a kód 5 százaléka fut. Na, ezt az öt százalékot nyomorítják kézzel. Pl. játékban a grafikus motort mindenestül, a videokódolásnál a codecet, estébé."
Jó, a játékprogramozás nem asztalom, elhiszem hogy az alacsony szintű grafikát (driverek, directx, opengl, grafikus motorok magja) rendesen beoptimalizálják.
De, jópár éve alkalmazás-programozásból élek, és ott látom mi megy.A rövid termékciklus-probléma igenis létezik, és játékoknál is fennáll. (vannak jól megírt játékok, vannak memória- és cpu/gpu zabálók ez közhely. Van egy projekt, X éven belül ki kell hozni a sw-t, akár megoldják rendesen a fejlesztési problémákat akár nem.)
Játékos példa: egy Civilization4-stílusú játék (turn-based, stratégiai, táblás) mitől eszik sok száz mega RAMot, mitől tölti magát perc nagyságrendű ideig, olyan gépen ami a játék újkorában csúcs erőműnek számított volna? Viszonylag kisszámú terepkocka mintát kell felrakni a térképre, fölé a unitok animált rajzait. Semmi fizika, semmi valós látvány, csak kirajzolunk egy szép színes sakktáblát és animáljuk hogy ne legyen unalmas. Ehhez kell erőmű? (jó, van egy pörgetett glóbusz is, hogy el lehessen mondani, ez aztán 3D game)Egyszerűen nincs idő valóban hatékonyra megírni egy szoftvert, túl rövidek a termékciklusok. Tapasztalatom szerint a legkisebb memóriaigényű és leggyorsabb megoldások mindig azok, amit C/C++ban raktak össze, Ádámtól-Évától kőbaltával.
Ha korlátlan idő lenne sw-fejlesztésre, akármit meg lehetne így írni, hogy egyetlen fölösleges memset, memcpy, egyetlen fölöslegesen allokált byte nincs ötmillió sor kódban. Persze ez kivihetetlen, nem lehet így dolgozni, mert rég elavul az alkalmazás és a megcélzott hardverkörnyezet, mire kész lenne a fejlesztés.
De ez nem mindig volt így és nem mindig lesz így, erre céloztam.Visszatérő élmény: nézegetek egy csilivili überintegrált alkalmazást, amibe tucatnyi szupermodern "technology" be van építve, és csak hümmögök, hogy mi a péknek allkolál fél giga memóriát, mitől tölti be magát egy percig, és általában tetű lassú az egész - és megeszem a monitort, ha nem lehetne C-ben tizedekkorára, tizedannyi erőforrásigényűre és tízszer ilyen gyorsra megírni, ha az érdemi funkcionalitást nézzük, és nem kellene egy rakat fekete doboz jellegű technológiát pazarló módon (ágyúval verébre jelleggel) egymásra építeni -a komplexitás miatt- a gyors fejlesztés érdekében. Nagyon komplex dolgot nagyon gyorsan csak erőforráspazarlóan lehet összerakni, Márpedig a gyorsaság gazdasági kényszer. Ez a módszertani probléma.
-
-
Raymond
titán
Aztan meg ami lejon az eddigi uj(abb) in-order chip reszleteibol az az hogy dugig vannak cache-el meg akkor is ha a memoria savszelesseg nem gyenge. Mindegy melyikrol van szo. Talan meg a CELL az ahol a legkisebb az arany (kb. 50/50 a logic es a cache), a POWER6-ban a magok kisebb teruletet foglalnak mint a cache. Az IO is eleg sok helyet foglal. Tukwila-nal ugyanez van. Szoval az in-order ad tobb frekvenciat es jobb SMT kepessegeket de tobb core nemigen fer a chip-re mint OoO magokkal.
-
fLeSs
nagyúr
Ez igaz.
Egyébként mot hogy nézem, nem jelölték külön az RS/ROB-ot (meg L1 cache-t sem), mert a Powerben nincs is. A proci a dekódolás után utasítás-csoportokat hoz létre, itt történik némi OoO végrehajtás, de ez annyira primkó (és sztem ezért is szedték ki belőle, mert több hátránya volt, mint előnye), hogy nagyságrendilag valszeg kevés tranzisztorba kerül. -
-
Rive
veterán
Szerintem minden további nélkül összejöhet. Bár ez tényleg csak filozofálgatás, hiszen efféle átalakítás esetén nem a design szimpla kiherélése történik, hanem újragondolása... De abba gondolj bel, hogy pl. egy hipotetikusan in-orderré gyalázot K8 magban az Integer részen nem csak az OoO cuccok tűnnének el, hanem valószínűleg a párhuzamos VE-k egy része is feleslegessé válna...
-
fLeSs
nagyúr
2-3-as szorzó? az brutálisan soknak tűnik nekem.
sztem a részegyésgek amiket felsoroltam jó ha a mag (cache nélkül) 50%-át kiteszik, ha x86-osról van szó, a dekódolóra is sok tranzisztort el kell pazarolni.
az igaz, hogy a powerben csak egy kezdetleges dekódoló van, de még így sem hinném, hogy 2-3x-os lehetne a különbség, az nagyon durva lenne. -
Rive
veterán
Ha ez az idő eljön, a szoftverfejlesztés módszertanának kell felnőni a hardverhez: a jelenlegi "cseszünk az optimalizálásra, jövő évi vasakon úgyis elfut, kit érdekel mi lesz 3 év múlva" mottójú, rövid termékciklusos modell nem lesz többé nyerő.
Megbocsáss, de ma nem így működik a dolog. Az összes komolyabb szoftvert optimalizálják. Hja, nem az egészet: régi szabály, hogy a futásidő 90+ százalékában a kód 5 százaléka fut. Na, ezt az öt százalékot nyomorítják kézzel. Pl. játékban a grafikus motort mindenestül, a videokódolásnál a codecet, estébé. -
Rive
veterán
Nem tudom hova tenni azt, hogy az in-order hozzáállás egyre több helyen tűnik fel újra a CPU-knál. Talán a kérdés eleve értelmetlen, de mégis felteszem: egy mai, fejlett out-of-order mag helyére mennyi klasszikus in-order, non-speculative magot lehet betenni, és vajon milyen órajellel? A sokszor akár fordítói szinten megoldható (Itanium?) problémákat lekezelve mennyiben csökkenthető fajlagosan az adott mag komplexitása, gyártási költsége, tervezhetősége, és a feladat párhuzamosíthatósága?
Az OoO tényleg nagyon sok aerőforrást igényel, de nem hiszem, hogy a szorzó nagyobb lenne 2-3 körülinél. Azaz egy OoO helyére SZVSZ 2-3 IO mag kerülhet: a sebesség dolgában talán a Power család adhat némi iránymutatást. Ezzel szemben áll az OoO extrém rugalmassága - nagyon sz@r és nehezen párhuzamosítható kódból is képes egész sokat kihozni. A fordítás dolgait a múlt eseményeinek tükrében kissé túl szokás becsülni. A helyzet az, hogy rengeteg fordítással kapcsolatos problémára egész egyszerűen nem sikerült jó megoldást adni már ott sem, ahol az architektúra eleve a fordító kedvére épült. Ezzel szemben a klasszikus (kézi) optimalizálás kielégítő hatékonyságot tudott biztosítani.Én azt mondanám, hogy általános feladatokra marad az OoO, legföljebb kicsit belevariálnak a hozzáállásba. Aminek végülis van helye: a mai többszörös kibocsátású procik is csak a ~ 1-es IPC-t kostolgatják.
Lehet, hogy rosszul látom, de a GPU-k egyre jobban/mélyebben programozhatóvá, egyre általánosabbá szeretnének válni; a (az x86?, vagy a hibrid) CPU-k pedig egyre komplexebben programozhatóbbakká. Vajon hol lesz az arany középút ebben a kérdésben a kínált teljesítményben (figyelembe véve az algoritmusok igényeit), így, hogy mindkét oldal elindult egymás felé?
Szerintem a 'középút' itt a hibridizáció lesz. -
ddekany
veterán
"Tippem szerint valamikor 2015-2020 között elérjük a fizikai határokat.
Ha ez az idő eljön, a szoftverfejlesztés módszertanának kell felnőni a hardverhez: a jelenlegi "cseszünk az optimalizálásra, jövő évi vasakon úgyis elfut, kit érdekel mi lesz 3 év múlva" mottójú, rövid termékciklusos modell nem lesz többé nyerő."Ez nem így működik. Azoknál a szoftverrészeknél amik kritikusak a sebesség szempontjából most sem csesznek az optimalizálásra. OK, van hogy vmi szarra sikerül, de nem jellemző az a stílus amit mondasz ha valósidejű dolgokról beszélünk, pl. játékokról. Amit te mondasz, az inkább az átlagos alkalmazásoknál jelentkezik, pl. indokolatlanul erőforrás igényes böngészők, vagy, hogy az új generációs Catalyst Control Center kb lassabban jön be mint Photoshop CS2. De az ilyesmi (jellemzően) pont nem érinti a 3D grafikát, fizikát, AI-t.
"Nem igazán látom, a mostani 60 gflops csúcsprociból kiindulva hogyan lehetne 1000 gflops teljesítményt megcsinálni egyáltalán, 2010-re."
Azért a csúcs GPU-k (nem CPU-k) már most is a néhányszor 100 GFLOPS tartományban mozognak (ha jól tudom), szóval az 1000 GFLOPS elérése nem elképzelhetetlen, persze nem általános célú CPU-n, hanem masszívan párhuzamos feldolgozásra specializálódott cuccon (pl. GPU).
Más kérdés, hogy akár az 1000 GFLOPS mire elég, mert pl. ahhoz hogy még jobb és jobb legyen a grafika, egyre "gazdaságtalanabb" mértékű GFLOP növekedés szükséges. Pl. normálisan kinéző (tehát még csak nem is korrekt) szórt fény számításhoz realtime-ban nagyságrendileg sem elég, így szemre. Anélkül meg a ray-trace sok újat nem tud hozni látványban. Mármint, a látvány valóságosságában.
-
fLeSs
nagyúr
Meg lehet becsülni, ha szerzel egy die fényképet, amin berajzolgatod a futószalag egyes részeit (vagy találsz olyat, amin be van jelölve, akkor annál jobb, ehhez jó kezdés a chip-architect.com). Ezután kiszeded belőle az ütemezőket (reservation station, reorder buffer), a regiszterfileokat, ha vannak benne OoO queue-k, akkor azokat is, és akkor kiderül ha kiszámolod az előtte/utána die méretek különbségét.
szerk: AMD K8 mag.
-
vati
senior tag
"Szóval röviden és tömören az OoO elhagyásával nagyon leegyszerűsödik a chip megtervezése"
Lehet-e (értelmes-e) kvantitatív becslést adni arra, hogy egy OoO chip hányszor több tranzisztort igényel mint egy in-order chip, feltéve hogy ray-tracing jellegű a megoldandó feladat?
Adott feladatban adott számítási teljesítmény eléréséhez X tranzisztor szükséges (nagységrendileg) Ezek mérete nem csökkenthető tetszőlegesen. A tranzisztor átmenetek mint hődisszipácó, a GHz sem növelhető az égig mert előbb-utóbb instabil lesz a procimag akármivel hűtik. A tranzisztorok száma nem növelhető (magszám), mert a rendszer össz hőtermelése fog elszállni.
Tehát létezik egy határ, aminél több gflops nem hozható ki egy mai fogalmaink szerint értelmezett desktop PCből. Ezt a határt megközelíteni is nehéz (és drága, lassú, körülményes) lesz, nemhogy elérni. -
#216
vati
senior tag
shabbarulez
#44
vati
senior tag
válasz
shabbarulez
#44
üzenetére
"És ez 2012-ben, 2014-ben az új gyártástechnológiák 22, 16 nm kijövetelével ugyanúgy növekszik majd ahogy eddig is."
Halkan megjegyzem, a szilícium rácsállandója kicsivel több mint fél nanométer. 16 nm már csak kb. 30 atom, valamiből ki kell hozni stabil p-n átmeneti réteget, megbízhatóan működő (nano)tranzisztort csinálni.... Lefelé haladva, falba fog ütközni a miniatürizálás pár éven belül, amit a fizika törvényei (Heisenberg-reláció) cövekelnek ki.
Nem látom, hogyan lehetne nagyságrendeket ugrani számítási teljesítményben a PC architektúrán belül maradva. Extenzív növekedésnél -magméret,darabszám- a hőtermelés válna kezelhetetlenné. (tegyük fel, nem lesz kötelező a folyékony nitrogénhűtés) Tippem szerint valamikor 2015-2020 között elérjük a fizikai határokat.
Ha ez az idő eljön, a szoftverfejlesztés módszertanának kell felnőni a hardverhez: a jelenlegi "cseszünk az optimalizálásra, jövő évi vasakon úgyis elfut, kit érdekel mi lesz 3 év múlva" mottójú, rövid termékciklusos modell nem lesz többé nyerő. Meg kell tanulni majd újra hatékonyan (ez most a sokszálúsítást jelenti) programozni, mint az 1960-as években, amikor minden bitért meg kellett küzdeni, és a legolcsóbb tényező a programozó munkaideje volt.Nem igazán látom, a mostani 60 gflops csúcsprociból kiindulva hogyan lehetne 1000 gflops teljesítményt megcsinálni egyátalán, 2010-re. Vagy akár 2015-re. (és a mainstream proci még csak 25-30 gflops)
-
fLeSs
nagyúr
OK, csak te Xeont írtál n nélkül, ez kavart nekem be.
Abban a hsz-ben amit este belinkeltem ott ugyanezt írtam le: "hogy egy csomó üres ciklust iktattak be az in-order végrehajtás miatt a végrehajtókhoz, hogy a függő utasítások egymásutánban hajtódhassanak végre (kalkuláció után következzen a load/store). Ezért tudták ennyire megemelni az órajelet."
üres ciklus vagy futószalag fokozat = delayed execution pipeline.
viszont a Power6-ban csak az FP végrehajtásnál van OoO, az LSU-ban nincs. -
dezz
nagyúr
"The PPE core can fetch four instructions at a time, and issue two. In order to improve performance from its in-order pipeline, the PPE utilizes delayed-execution pipelines and allows limited out-of-order execution of load instructions. This allows the PPE to get some of the advantages of out-of-order execution without any significant increase in complexity." [link]
(Valahol volt szó róla kicsit bővebben is, de most nem találom.)
[És persze Xenon, mint ahogy először írtam.] -
dezz
nagyúr
Közben láttam pár GT5P screenshotot (ha tényleg azok), hát meg kell hagyni, tényleg elég jól néz ki. [link]
A Power6 valószínűleg nem full in-order, hanem a Cell PPE-jéhez és a Xenon magjaihoz hasonlóan pipeline-os trükközéssel 1, esetleg 2 utasítás mélységben képes variálni a végrehajtást.
-
ddekany
veterán
"Egy x86-os procival is meg lehetne ezt játszani, csak ahhoz kompletten át kéne tervezni"
Na, akkor várjuk az Intel következő generációs CPU-ját (tehát bőven Nehalem utánit), vajon in-order lesz-e...
(Az Itaniumot meg nem nagyon illik ide, mivel az, hogy úgy mondjam, csak hardveres szemüveggel in-order...)
-
fLeSs
nagyúr
Asszem 4,7 GHz-es a legalacsonyabb órajelű változat.
És a leggyorsabbat a különböző ipari szabvány tesztekre értem, speccpu, specjbb, tpc-c, oracle, sap meg mittomén mik vannak még. De elsősorban a spec a lényeg.Egy x86-os procival is meg lehetne ezt játszani, csak ahhoz kompletten át kéne tervezni, bármelyikről is legyen szó. A mondandóm lényege annyi lett volna, hogy az in order nem feltétlenül jelenti azt, hogy lassú/gagyi.
Pár év múlva lehet, hogy az Itaniumot hoznám fel példának, mert az is in order. -
ddekany
veterán
"A Power6 in order, asszem 5 GHz-es, és a világ leggyorsabb (GP) processzora jelenleg."
Mi a fene (bár, számomra még hiányzik, hogy miben leggyorsabb, és hogy vajon hány százaléka a kihozatalnak megy 5 GHz-n stabilan.) Nem hittem volna, hogy annyi órajelet tudnak az in-orderság miatt emelni, hogy megérje az IPC csökkenést... És mi lenne, ha x86-os ISA-s CPU-val is megjátszanák ezt? Csak nem merték eddig, vagy eddig a gyártástechnológia miatt nem lett volna még nyerő, vagy x86 esetén ez valamiért nem jönne be? Már ha nem rengeteg amúgy is egyszerűsített magot akarnak rakni egy helyen (Larabee), mert az más tészta.
-
fLeSs
nagyúr
Egy részét kicsit rosszul látod.
"Amíg az egyszálas teljesítmény a döntő, mert alapvetően egyszálasak (vagy néhány szálasak) a programok, addig nincs más lehetőség, mint OoO-val gyorsítani."
Ha OoO helyett in-order chipet tervezel annak megvan az az előnye, hogy az egyszerűbb felépítés miatt sokkal magasabb órajelet érhetsz el. A Power6 in order, asszem 5 GHz-es, és a világ leggyorsabb (GP) processzora jelenleg.
Szóval összességében az in order felépítés kedvez a chip egyszerűbb felépítésének, ebből következően több magot köthetsz össze, tehát a TLP-nek is, amiről te beszélsz.
-
ddekany
veterán
"Lehet, hogy rosszul látom, de a GPU-k egyre jobban/mélyebben programozhatóvá, egyre általánosabbá szeretnének válni; a (az x86?, vagy a hibrid) CPU-k pedig egyre komplexebben programozhatóbbakká. Vajon hol lesz az arany középút ebben a kérdésben"
Szerintem sehol... Más jellegű feladatok megoldására más megközelítésű architektúra az ideális. Orba-szájba elágazó és úgy általában nehezen párhuzamosítható feladatra a CPU jó (lehetőleg OoO-s), rasztergrafikára meg úgy általában a csináljuk-pont-ugyanazt-sok-szálon-csak-más-adattal feladatra a GPU a jó, és fizikára meg ray-trace-re meg gondolom a kettő közötti, mert hogy ott sok a párhuzamosság, de a párhuzamos szálak eléggé külön utakat tudnak járni.
-
ddekany
veterán
Ehhez még hozzáfűzném, hogy nem csak, vagy talán főleg(?) nem arról van szó, hogy egy in-order gyorsabb-e a magasabb elérhető órajel miatt mint egy OoO. Eleve valószínű, hogy nem lesz gyorsabb, viszont a kisebb terület és fogyasztás miatt sokat lehet belőle egy tokba elhelyezni. Pl. 8-at (+1 fő mag), mint a Cell-ben. Igen, azok más szempontból is egyszerűbb magok mint mondjuk egy x86, de épp ez lesz a lényeg. Ennek sok-buta kevés-okos helyett megközelítésnek viszont csak akkor van értelme, ha valami használ is annyi magot (szálat). Amíg az egyszálas teljesítmény a döntő, mert alapvetően egyszálasak (vagy néhány szálasak) a programok, addig nincs más lehetőség, mint OoO-val gyorsítani. De ha masszívabban párhuzamos feladatot kell végezni, pl. ray-tracing-ot vagy fizikát, akkor már többet érsz -- csak hasra -- 12 egyszerű in-order maggal mint mondjuk a helyén 4 böhöm és amúgy is mindent tudó OoO-ssal, hiszen az OoO soha nem fog 3x-os párhuzamosságot kinyerni egy szálból, meg egyébként is specializálható a mag bizonyos feladatokra (fitika, ray-trace, stb), tehát még egyszerűbb lesz. Na szerintem inkább ez van a tendencia mögött... jönnek desktopra egyre inkább a nagyon-párhuzamos dolgok, és ott plusz néhány buta mag már többet hoz, mint kevesebb ami viszont OoO. (Mondjuk igaz, hogy szerveren meg szuperszámítógépen akkor is OoO volt/van jellemzően, pedig ott sok szál van. De ott pl. hűtés, helyfoglalás, meg költségek területén más az elfogadható szint. Bár, most már ott is néhányan mozdulnak el az egyszerű magok felé, pl, Sun-ék Niagara-ja.)
-
P.H.
senior tag
Fenntartom ebben a (jobbára grafikus) témában továbbra is a tévedés lehetőségét
- A gyártási költségnél olyasmire gondoltam, mint ami pl. P1 esetén volt, amikor egymás mellé tett az Intel kb. két (akkor asszimetrikus) 486-pipe-ot. Ha a második mégse működne, el lehet adni pl. egy in-order chip-et magszintű párhuzamosság nélkül is.
- Az is eszembe jutott, hogy az Intel 3.8 GHz-en fejezte be a Netburst-vonalat, tehát csináltak ott és akkor pár egyszerű (integer- és ütemező)egységet már akkor 7,6 GHz-esnek tűnően.
-
fLeSs
nagyúr
Az OoO elég szép számú tranzisztort felemészt. A megvalósításához tényleg komplex tárolókat kell létrehozni (tudod te is, RS és ROB), nekem van egy leírásom, hogy egy RS-nek és ROB-nak milyen mezőket kell tartalmaznia.
Emellé gátolja a chip órajelbeli skálázhatóságát.
Szóval röviden és tömören az OoO elhagyásával nagyon leegyszerűsödik a chip megtervezése, viszont a szó szoros értelmében vett gyártási költség szerintem nem olyan lényeges a mai gyártástechnológiák mellett (persze az OoO megtervezésénél chipbe ölt pénz elég sok lehet, bár ha már egyszer megtervezték, akkor másodjára talán már nem akkora kunszt).
Az, hogy teljesítményben melyik a jobb szvsz abból derül ki, hogy melyiket hol alkalmazzák. Ha a szimulációk azt mutatják, hogy egy in order 5 GHz-es chip jobban teljesít, mint egy OoO 3 GHz-es, akkor az in ordert fogják megvalósítsani. Ezt láthatjuk az Itaniumban, Cellben, Xenonban, Power6-ban. -
P.H.
senior tag
Én azt várom, hogy milyen szemléletmódbeli váltást fognak mutatni ebben az évtizedben a gyártók (akár az Intel színre lépése által). Hisz mind a háromnak (vagy ki tudja még, kinek) vannak előremutató megoldásai; kérdés, mire tudják használni? "Használni", mint arra alkamas algoritmusok alapjaként, vagy "használni", mint kihegyezett hardware-ként alkalmazni azt.
Nem tudom hova tenni azt, hogy az in-order hozzáállás egyre több helyen tűnik fel újra a CPU-knál. Talán a kérdés eleve értelmetlen, de mégis felteszem: egy mai, fejlett out-of-order mag helyére mennyi klasszikus in-order, non-speculative magot lehet betenni, és vajon milyen órajellel? A sokszor akár fordítói szinten megoldható (Itanium?) problémákat lekezelve mennyiben csökkenthető fajlagosan az adott mag komplexitása, gyártási költsége, tervezhetősége, és a feladat párhuzamosíthatósága?
Lehet, hogy rosszul látom, de a GPU-k egyre jobban/mélyebben programozhatóvá, egyre általánosabbá szeretnének válni; a (az x86?, vagy a hibrid) CPU-k pedig egyre komplexebben programozhatóbbakká. Vajon hol lesz az arany középút ebben a kérdésben a kínált teljesítményben (figyelembe véve az algoritmusok igényeit), így, hogy mindkét oldal elindult egymás felé?
-
ddekany
veterán
Ami azt illeti, a dolognak ebben a fázisában dezz és Raymond már igazán rádöbbenhetne, hogy mivel már rajtuk kívül senki sem követi a csatájukat, pl. hogy ki mit csavart ki és mit nem, semmit nem veszítenek a státuszukból mások szemében, ha csak úgy abbahagyják. OK, tudom a tesztoszteron... de javaslok egy megoldást: egyszerűen egyezzetek ki abban, hogy úgy simán a kúrva anyját a másiknak és kész.
-
dezz
nagyúr
válasz
#06658560
#185
üzenetére
Hogy pontosak legyünk, első pár alkalommal, amikor a real-time ray-tracing, és annak jelenlegi lehetetlensége volt emlegetve, és én belinkeltem, amit belinkelgettem, nem volt kiemelve, hogy asztali gép vagy sem, csak később, és arra reflektáltam, hogy egy blade is elfér egy asztalon, mint mondjuk egy workstation. Persze nyilván nem játékosok számára, de működik a dolog.
Mégegyszer mondom: azzal, hogy azt mondtam, hogy a raszteres grafika műies, még nem azt mondtam, hogy a belinkelt animok az élethűség netovábbjai (csak legalább pár effekt élethű), eddig fogod? Logika? Azt mondtam, hogy RT alapon lehet igazán élethű képeket csinálni. Jó lenne, ha nem kavarnál itt feleslegesen te is, hanem pl. inkább jobban utánanéznél a ray-tracingnek, meg az optikának.
(#193): Mint Ddekany is írta, ha nem lenne szemlencsénk akkor is láthatnánk élesen a lyuk-hatás segítségével (ez is 8.-os anyag), de mint szintén írta, azon jóval kevebb fény jön át, így csak jól megvilágított helyen látnánk. Végülis vehetjük úgy, hogy az RT is ezen alapul, mert a virtuális ablakon (képernyő) áthaladó sugarak itt is egy pontban metszik egymást. Tehát azokkal a sugarakkal számol, amik maradnának egy ilyen lyuk-hatás után.
A természet inkább nem ezt választotta (bár még az is lehet, hogy pl. egyes rovarok így látnak). Persze lehet ezt is külön szimulálni, de ez már csak egy ráadás.
Legjobb lenne olyan hologramokat létrehozni, aminél oda fókuszálunk, ahová akarunk, mert pontosan úgy érkeznek felőle a fénysugarak, ahogy a valóságban is, de az ilyesmi még nagyon odébb van.
(#187) Raymond: "Hahahahahahahaha - bagoly mondja verebnek Gondolkodj mar el ezen meg azon hogy minket hordtal itt ossze-vissza."
Aham, szal megint kezded végtelenül rosszindulatú, jól kiforgatott ki-mit-mondottat, jó adag személyeskedéssel nyakon öntve műsorod...
Nem hordtam semmit "össze-vissza".
"Odaig sulyedtel"
Te sűllyedsz le, de nagyon. Sajnos elvakult "hadakozásodban" észre sem veszed, pedig ideje lenne.
"hogy azokra a Q4 kepekre es a Ferrari-s demora allitottad sokszor hogy neked inkabb az tetszik mint a mostani raszteres megoldasok mu vilaga mert hogy azok milyen realisan neznek ki."
Most vagy a saját félreértésedet próbálod rám verni, vagy szándékosan forgatod ki a dolgokat. Ezt így nem mondtam. Általánosságban mondtam az RT-ről, hogy élethűbb képeket lehet vele csinálni. A autós animok lényege a valósidejűség volt, olvass csak vissza, mire linkeltem be őket. A Quake-esekre azt mondtam, szerintem azért (GI hiánya, stb, ellenére) jól néznek ki (szubjektív!).
Fenntartom, hogy a raszteres grafika számomra műbb. Ha másért nem, a kiábrándítóan élethűtlen és hiányos, vagy épp hiányzó tükröződések, fénytörések, kiábrándító és élethűtlen füst, stb. miatt. És hiába kifinomultabb az árnyalás, akkor is mű érzetű marad. A ray-traced Quake-ekben nincs (még) ilyen kifinomult árnyalás, de az élethűbb árnyékok, tükröződés, stb. miatt legalább nem illúzióromboló a számomra. És úgy tűnik, az én szememnek jobban fekszik egy alapabb RT-s árnyalás is, mint a trükkökkel teli raszteres. Kinek a pap, kinek a papné.
"Ha az otvar szemelyeskedes alatt azt erted hogy megmodtam vilagosan a leirtak szerint nem ertesz ahoz amirol irt irogalsz akkor igen, az volt."
Kár, hogy egy csúsztatással próbáltad ezt alátámasztani. Azt magam is írtam, hogy a raszteres grafikában nem vagyok túlzottan otthon (azért az alapokat tudom), ezen felesleges ugrálnod. Szubjektív véleményem viszont így is lehet róla.
1-2 dologban igazad van, el is ismertem (de ezt meg sem látod, mert mindent-vagy-semmit játékot játszol) - mást meg vitatok, de attól még nem kellene így eltorzulnod.
"Egyebkent meg jo kifogas sose rossz. Perszehogy azert nem valaszoltal ra mert meg vagy sertodve, nem azert mert gozod sincs mit irjal."
Te nagyon el vagy tévedve, illetve a szociális érzékeddel valami komoly gáz lehet.
"Egyebkent nem azert hagytam ki mert nincs ra mit valaszolni hanem mert egyszeruen mar faradt voltam az este es meghagytam mara."
Persze, persze.
"Nem akarom a lelkesedesed letorni, de ha lenne fogalmad a temarol akkor tudnad hogy van ra mit valaszolni csak sajnos gozod sincs hogy mi lenne az."
És, miért nem írod le? Még mindig fáradt vagy - miközben személyeskedésre mindig van energiád?
"Ezert hanyagolod a feltett lenyegi kerdeseket es ilyen hozzaszolasokra tellik csak mint a mostani."[/i]
Nem én kezdtem ezt a stílust...
"Ugy oszinten sajnalom azt is hogy ezt elirtam. Egesz technikai lett ez a tema csak az ilyen szarsagok ronditjak ossze amikor allitasz valami egetvero baromsagot aztan kotod az ebet a karohoz teljesen orult "ervekkel" (pl. mint a realisztikus Q4 demo, asztali vagy asztalon elfero blade furt meg halom CELL). Aztan a tema lassan atmegy abba hogy mondatonkent valaszolsz egy-egy hozzaszolasra finoman valtoztatva a mondandon hogy hulysegeken tudj kesobb fennakadni a vegen meg hogy mindenki csak szemelyeskedik es bant teged pedig te olyan pizitiv es jo voltal. Aztan az egesz egy ilyenbe megy at mint most. Ezt mar nagyon sokszor eljatszottuk es tenyleg unom."
Valóban? A múltkor véletlenül nem te kezdtél belekötni apró részletekbe (de azt is kiforgatva), miközben a lényegben ordasan tévedtél, de a hasonló hadakozásodban csak nagyon lassan jutott ez el a tudatodig?
Mint írtam, most sem veszed észre, hogy az érveid egy részét nagyon is elfogadtam. Csak nem mindent. De te annyira elvakult vagy, hogy csak a teljes és tökéletes győzelem érdekel. Ami lehetetlen elvárás.
"Normalis minosegben ember, es nem egy tobbtizezer $ blade furton vagy egy halom PS3-on."
Ezek a kikötések nem szerepeltek az elején. És ami ma többtízezer dollár, az éveken belül ennek töredéke lehet, ugyebár. Márpedig a fő kérdés az volt, mi lesz 2 év múlva. Azt meg magad is írtad, hogy a Larrabee megjelenéséig a kódjukon is faraghatnak még.
"Csak azok nem realtime. Itt meg arrol beszelunk. Vagy ha van realtime akkor ne tartsd vissza magad."
Ami ma nem real-time, az "holnap" azzá válhat.
"Csakhogy azok a Q4 kepeken semmi nincs. Se tobb poligon, se bumpmapping, se normal mapping. Nezz mar meg par kepet a rendes Q4 verziobol hogy kene kineznie minium. Egyebkent ha annyira jo a raytracing a sok poligon feldolgozasaban akkor miert csak max 200-300 ezerbol allo sceneket demoznak? Es meg meg a felso hatar, az a Q4 annyi sincs."
A cikkben még példát is mutat erre. Ne az én torkomnak ugorj már légyszives, ha nem volt igaz.
Ez különben is csak egy CPU-n futó demó, később a Larrabee-n kell majd futnia, ami vélhetően optimálisabb lesz különféle mappingekre is.
(#188): "Te beszlesz csusztatasokrol? Vagy csak siman a szovegertessel van gond? Realtime RT-rol van szo nem offline! Lassan fel kene fogni. Es arrol hogy egy pusztan RT-n alapulo jatek engine kivitelezhetetlen a raszteres megoldason minosegeben ma es ugyanugy kivitelezhetetlen lesz 2 ev mulva is amikor kijon a Larrabee."
Most is te csúsztatsz, mert az a kijelentés, hogy a raszterezésben 1000x gyorsabb megoldások vannak mindenre, megközelítőleg élethű eredménnyel, egy teljesen általános megfogalmazás. Ebből arra lehetne gondolni, hogy az RT lényegében felesleges, akár gyorsan, akár lassan.
"A belinkelt kep meg azert lett linkelve amit odairtam - az emlekeztetett a 3DS env mappingra a legjobban."
Akkor is manipulatív volt betenni azt a képet. Miért? 1., egy játékban nem csak ilyen helyzetek vannak, hogy egy ilyen vékony lábú pókféle van egyedül a képernyőn. (Vagy ilyenkor át kellene váltani raszterezős grafikára, aztán meg vissza?) 2., mozgásban amúgy is kibukik, hogy env map, vagy valódi pontos tükröződés.
"Ezt nem jelenti azt hogy a tobbinek nem hanyadek a minosege. Mert az."
Jól van. De ezt véleményt lehetne közölni normálisan is. Lehet, hogy szakmai vélemény, de nem mindenkire kötelező törvény, lehet ettől eltérő szubjektív vélemény is.
"Meg most mar eleg az effekthez egy egyszeru envmap szerinted is? O RLY? Mert eloszor azt allitottad az RT tuti megoldas es amikor mondtam hogy ha nem tudnad hogy van lekepezve nem mondanad meg hogy RT vagy envmap arra azt allitottad hogy mozgasnal igen. Csak aztan godolom megnezted a videot is es leesett a tantusz"
Milyen videót, és milyen tantusz? Csak ahhoz az állóképhez elég.
-
Ati_X_321
aktív tag
válasz
#06658560
#181
üzenetére
Interferencia: annyira nem ritka jelenség
nyílván nem ritka jelenség, sőt mindenhol ott van, csak éppen nem veszed észre, mert nem monokromatikus fénnyel szoktál találkozni, hanem fehérrel, ami mindenféle frekvenciájú fény szuperpozíciója, és ebből egy hullámhosszra teljesül az interferencia feltételeA fény hullámtermészetével nem fognak játékok számolni, mert felesleges, ritka jelenség, hogy észrevehető.
ha valahol annak kell látszódnia (árnyék széle), majd valamilyen csalással ott leszhelyette van sok más dolog, ami tényleges képminőség javulást hozna, például anyag felületébe behatoló fény, ami ott ideoda verődik, egy része elnyelődik (BSSRDF), de szintén egy nagyságrendet dob a számításokon.
-
ddekany
veterán
válasz
#06658560
#193
üzenetére
"de szerintem a melysegelesseg letrejotte egyszeru fizikai kovetkezmeny"
Persze hogy az, mi más lenne. Viszont ez a fizikai jelenség akkor lép fel, mikor lencsével egy érzékelőre (pl. CCD, vagy ideghártya) vetíted a képet. Lehet vizsgálni hogy pontosan optikailag mi történik, de felesleges, mert itt egy egyszerű információhiány problémárol van szó: a perspektívikus látásnál el kell döntened, hogy egy beérkező fénysugár (ha úgy tetszik foton) forrása (tehát az a pont a térben, ahonnan legutóbb lepattant a fénysugár, hogy végül a szemedbe kössön ki) egy meghatározott térbeni ponttól -- itt áll a néző -- milyen szögben helyezkedik el (tehát ez két szög, mert térben vagyunk, ezért is 2D végső soron a kép amit látsz). Ez teljesen triviális, ha a fény egy nagyon pici lyukon lép be, mert akkor az érzékelő ernyőn pont a szögnek megfelelő cellába fog becsapódni a fénysugár. Ha viszont nagy a belépő lyuk, akkor csak akkor tudod kitalálni hogy az említett ponttól milyen szögben van a fénysugár forrása, ha tudod, hogy a forrás milyen messze van a ponttól. Ez egyszerű geometria -- le kell rajzolni, úgy érthetővé válik. De nem tudod, mivel nem érződik a fényen, hogy mennyi ideje verődött vissza utoljára, csak beérkezés iránya áll rendelkezésre az érzéklelés helyén (nem meg a spektrum, de az most mindegy), szóval ez az összes információd ami rendelkezésre áll ott. Tehát kínodban hasraütésre feltélezel egy távolságot, hogy milyen messziről jött a fény, és ha eltrafáltad, akkor éles lesz a kép. Aztán ha látod hogy életlen a kép, akkor tippelsz kicsit kisebb vagy kicsit nagyobb távolságot, és figyeled, hogy élesebb vagy életlenebb lett a kép, és így fokozatosan megkeresed mi a valódi távolság. Ezt csinálja a szem meg az autómatikus fókusz is (mondjuk a szem táposabb, mert van benne komoly képértelmezős rásegítés). Szóval mint látható, ez gyökerében egy információ hiány miatt fellépő jelenség.
-
#06658560
törölt tag
Hat, az optika teruleten eleg reg melyedtem el, de szerintem a melysegelesseg letrejotte egyszeru fizikai kovetkezmeny. Van egy lencsed, van egy vasznad, amire a ke3pet vetited
sargafolt) A ketto egymastol mert tavolsagat is ismered. A kostellaciobol ket dolgot tudsz valtoztani: a lencse formajat, es tavolsagat. Ezen felallasban egy adott lencsetavolsaghoz es lencseformahoz csak egy tartomany tartozik, amibol a kep eles lehet sajna. A tobbibol mar annyira meredek szogekben erkezik a feny, hogy ott torzul a toreskor az irany az elmelethez, vagyis nem eleg nagy a lencse. Vegtelen kiterjedesu lencsevel vegtelen messzesegig lehetne rendesen fokuszalni a kepet. De azzal meg kozelre nem lehetne semmit elerni. A melysegelesseg egyebkent szerintem kifejezetten hasznos a tavolsag felmeresehez pl.,valamint rengeteg folosleges- adott tevekenyseghez nem szukseges informacio kiszuresehez.Azaz egy autoszimulatornal szerintem meg lehetne csinalni, hogy bevisznek melysegelesseget a kepbe: alapesetben a palya egy adott szakaszara fokuszal az ember, pl kanyar. Na nanak a tavolsagat kell beloni elesre, a tobbit el lehet mosni, mondjuk egy-ket pixelnyit. meg is lenne a hatas.
-
Raymond
titán
Ettol fugg milyen megoldast hasznal a scene strukturara elmeleitel a statikus reszeknel nem lett volna gond a tobb poligon de valami nymomos oka lehet hogy sem bump sem normal mapping nincs legalabb azokon. Mivel igy az eredeti valtozat minseget sem eri el a demo. A problemaja szerintem az lehetett hogy egyszeruen nincs eleg rendelekezre allo ido a shading-re mert a raytracing annyit lefoglal. Az engine reszleteinek ismerete nelkul max talalgatni lehet.
-
ddekany
veterán
válasz
#06658560
#189
üzenetére
"Melysegelesseg,bevakitas mindketto kell a tenyleges elethuseghez, hiaba hibaja ez az emberi szemnek."
A bevakítás az még igen, de mélységélesség úgy általában nem működik jól monitoron, mivel nem tudja a számítógép hogy épp melyik pontját nézed a képernyőnek (az ahhoz tartozó távolságnak kéne automatikusan élessé válnia).
"Illetve nem is annyira hibaja, mint inkabb a felepitasabol kovetkezo egyszeru fizikai torvenyek miatti teny."
Technikai gyengeség az, csak valószínű igen nehéz lenne kiküszöbölni, ha a természet sem tette. A mélységélesség jelensége pl. egyszerűen abból adódik, hogy a fény egy viszonylag nagy átmérőjű lyukon lép a szemgolyóba. (Nagyon kicsi lyukkal meg nem kapna elég mennyiségű fényt.)
-
ddekany
veterán
"Csakhogy azok a Q4 kepeken semmi nincs. Se tobb poligon, se bumpmapping, se normal mapping."
Mivel a scene túlnyomó többsége statikus, nem hiszem hogy a poligon szám növekedés jobban földhözvágáná mint a raszterest, max. nem akartak még lassabb megjelenítést. A bump ill. normálmapping esetén meg vajon több a büntetés mint raszter esetén phong (vagy afféle normál interpolálós) shadingnál? Elvileg tök ugyan az az eset... aztán nem tudom van-e valami csel raszernál ami itt nem működik.
-
#06658560
törölt tag
Ahogy korabban is irtam, kicsit masfele nezve beszelgetunk, de nem allunk egymastol tavol.
A bevakitasos dolog meg, attol lesz eletszeru valami, ha ezeket is tudja. Melysegelesseg,bevakitas mindketto kell a tenyleges elethuseghez, hiaba hibaja ez az emberi szemnek. Illetve nem is annyira hibaja, mint inkabb a felepitasabol kovetkezo egyszeru fizikai torvenyek miatti teny.
Egyebkent pont arrol beszelek en is, hogy a RT-hoz igen sok fenysugarat kell szamolni minden ponthoz, hogy az elethuve valjon. Addig felesleges itt hozni ezeket a remek "elethu" demokat.
-
Raymond
titán
Te beszlesz csusztatasokrol? Vagy csak siman a szovegertessel van gond? Realtime RT-rol van szo nem offline! Lassan fel kene fogni. Es arrol hogy egy pusztan RT-n alapulo jatek engine kivitelezhetetlen a raszteres megoldason minosegeben ma es ugyanugy kivitelezhetetlen lesz 2 ev mulva is amikor kijon a Larrabee.
A belinkelt kep meg azert lett linkelve amit odairtam - az emlekeztetett a 3DS env mappingra a legjobban. Ezt nem jelenti azt hogy a tobbinek nem hanyadek a minosege. Mert az.
Meg most mar eleg az effekthez egy egyszeru envmap szerinted is? O RLY? Mert eloszor azt allitottad az RT tuti megoldas es amikor mondtam hogy ha nem tudnad hogy van lekepezve nem mondanad meg hogy RT vagy envmap arra azt allitottad hogy mozgasnal igen. Csak aztan godolom megnezted a videot is es leesett a tantusz
-
Raymond
titán
"Csak (újfent) rá kellett jönnöm, hogy nem vagy vitaképes (csevegni lehet veled, de vitatkozni nem), mert nálad vagy fullra az egyik, vagy fullra a másiknak lehet csak igaza, és természetesen csakis neked. Annyira eszelősen ragaszkodsz az utóbbihoz, hogy a cél érdekében már otromba csúsztatásoktól sem riadsz vissza"
Hahahahahahahaha - bagoly mondja verebnek
Gondolkodj mar el ezen meg azon hogy minket hordtal itt ossze-vissza. Odaig sulyedtel hogy azokra a Q4 kepekre es a Ferrari-s demora allitottad sokszor hogy neked inkabb az tetszik mint a mostani raszteres megoldasok mu vilaga mert hogy azok milyen realisan neznek ki."amit a #165-ösben Ati_X_321 le is reagált, persze te véletlenül elkerülted a válaszadást"
"lásd #155-ös eleje, amit a #165-ösben Ati_X_321 le is reagált, persze te véletlenül elkerülted a válaszadást). Amivel mellesleg ótvar személyeskedést próbáltál alátámasztani. Szívesen válaszoltam volna pár dologra, de elvetted a kedvem a beszélgetéstől."
Ha az otvar szemelyeskedes alatt azt erted hogy megmodtam vilagosan a leirtak szerint nem ertesz ahoz amirol irt irogalsz akkor igen, az volt. Egyebkent meg jo kifogas sose rossz. Perszehogy azert nem valaszoltal ra mert meg vagy sertodve, nem azert mert gozod sincs mit irjal. Egyebkent nem azert hagytam ki mert nincs ra mit valaszolni hanem mert egyszeruen mar faradt voltam az este es meghagytam mara. Nem akarom a lelkesedesed letorni, de ha lenne fogalmad a temarol akkor tudnad hogy van ra mit valaszolni csak sajnos gozod sincs hogy mi lenne az. Ezert hanyagolod a feltett lenyegi kerdeseket es ilyen hozzaszolasokra tellik csak mint a mostani.
Ugy oszinten sajnalom azt is hogy ezt elirtam. Egesz technikai lett ez a tema csak az ilyen szarsagok ronditjak ossze amikor allitasz valami egetvero baromsagot aztan kotod az ebet a karohoz teljesen orult "ervekkel" (pl. mint a realisztikus Q4 demo, asztali vagy asztalon elfero blade furt meg halom CELL). Aztan a tema lassan atmegy abba hogy mondatonkent valaszolsz egy-egy hozzaszolasra finoman valtoztatva a mondandon hogy hulysegeken tudj kesobb fennakadni a vegen meg hogy mindenki csak szemelyeskedik es bant teged pedig te olyan pizitiv es jo voltal. Aztan az egesz egy ilyenbe megy at mint most. Ezt mar nagyon sokszor eljatszottuk es tenyleg unom.
A temahoz:
"egyesek szerint ma még lehetetlen a real-time ray-tracing pl. egy asztalon elférő géppel."
Normalis minosegben ember, es nem egy tobbtizezer $ blade furton vagy egy halom PS3-on.
"Ha az RT felsőbbrendűségét akartam volna demonstrálni, akkor ezeknél sokkalta jobb animokat is be tudtam volna linkelni, nem gondolod?"
Csak azok nem realtime. Itt meg arrol beszelunk. Vagy ha van realtime akkor ne tartsd vissza magad.
"Bump-mapping állítólag nem is kellett, mert poligonokból volt kirakva, ami korábban bump-mapping volt"
Csakhogy azok a Q4 kepeken semmi nincs. Se tobb poligon, se bumpmapping, se normal mapping. Nezz mar meg par kepet a rendes Q4 verziobol hogy kene kineznie minium. Egyebkent ha annyira jo a raytracing a sok poligon feldolgozasaban akkor miert csak max 200-300 ezerbol allo sceneket demoznak? Es meg meg a felso hatar, az a Q4 annyi sincs. Lehet mert ahoz van valami koze amit a #155-ben (is) mar leirtam?
-
ddekany
veterán
válasz
#06658560
#172
üzenetére
"Ez szép és jó, perspektíva létrehozásához. DE. A teljesen máhonnan betükröző napfénnyel mi van? AMi esetleg bevakít?"
Bevakítás, és ha már itt tartunk, a mélységélesség az emberi látószervek technikai gyengeségei (és a fényképezőgépé), így ezek a jelenségek nem "adódnak" a raytrace-ból. A bevakítás mesterséges létrehozásához talán a már 2D-s kép utófeldolgozása fekszik a legjobban (meg HD-s dinamika az kell hozzá), és akkor ott mindegy hogy ray-trace vagy raszter. A mélységélességnél passz, bár az ray-trace szerű elven pont lehet utánozni (mivel egy lencsés optikai jelenség), csak számításilag elég kínos lenne...
"RT tud kezelni hullámtermészetű jelenségeket? Rács és réseffektust?"
Nem hullámként szemléli a fényt a ray-trace, inkább a pattigó labdákban (kb elhízott foton) gondolkodik, így ez sincs. Másfelől a benyomásra élethű képhez ez nem is kell.
Konkretizálva. Egyetlen pixelhez 1, tíz, tizenöt, száz, ötszáz, ezer, vagy mennyi sugár információja fog tartozni?
Minél többel csinálod, annál jobb a minőség... Ahhoz, hogy ray-trace elven minden további csel nélkül jó képet kapj, állati sokat kellene. De gyakorlatban a ray-trace is csak egy megközelítési forma (sőt rengeteg sugárral, mikorrücskös felületekkel, és rengeteg pattanás végigkövetésével is az lenne, bár elég jó), akárcsak a raszter, amire utólag még plusz rétegként ráraksz mindenfle trükköt (pl. GI). A kérdés csakis a már sokszor említett skálázódás, na meg az, hogy HA megoldod a sugárkövetést hatékonyan (tehát akkor nem csak úgy tudsz sugarat követni hatékonyan, ha a sugár a szemedből indul ki), akkor azzal a módszerrel mennyi dögös elfektet lehet létrehozni. Amiért én hosszú távon adok esélyesnek a ray-trace alapötletét hasznosító megjelenítésnek, az egy úgy általában mindenre vonatkozó tendencia: minél inkább igény van a valósághű utánzására egy jelenségnek, annál inkább a valóságos szabályokat jobban megfogó megközelítés (algoritmus) lesz sebességben is nyerő. De én egyáltalán nem vagyok benne biztos, hogy a ray-trace lesz a nyerő hosszútávon... ezek a mostani tesztek számomra nem sokat bizonyítanak, bár egyébként pozitív értelemben meg voltam lepve, hogy mit tudod 8 kóró maggal az a ray-tracer.
-
#06658560
törölt tag
Köhöm, az asztalon elférés. Végülis egy rack is elfér az asztalon, ha eléggé nagy. Egyébként mindenki más nem asztalon elférő gépet emlegetett, hanem asztalit. Plusz ha visszaolvasod saját magad ezt, hogy asztalon elférő csak a legvégén kezdted mondani, előtte egyáltalán nem. Valamint te kezdted modnani, hogy mennyire élethű, meg élethűbb a tükröződés miatt a rasztere megoldáshoz képest.
A másik mondandójának értelmezése megy végre?
-
dezz
nagyúr
"Nem mondja senki hogy a raytracing felesleges vagy nem lesz belole semmi"
Érdekes, hányszor is írtad le, hogy mindenre van az RT-t megközelítő kinézetű, de 1000x gyorsabb raszteres megoldás...? Meg hogy hiába gyorsul az RT, a másik is ezt teszi, tehát...
Meg az a belinkelt kép... Ügyi vagy, sikerült kiválasztanod azt, amihez tényleg elég egy egyszerű environment map (mert hogy semmi más nem mozog a képen, a vékony lábakon úgysem kivehetőek a dolgok, stb.). Csak éppen értelme nem volt.
-
dezz
nagyúr
A nénikéd futamodott meg - hogy szépen fejezzem ki magam. Csak (újfent) rá kellett jönnöm, hogy nem vagy vitaképes (csevegni lehet veled, de vitatkozni nem), mert nálad vagy fullra az egyik, vagy fullra a másiknak lehet csak igaza, és természetesen csakis neked. Annyira eszelősen ragaszkodsz az utóbbihoz, hogy a cél érdekében már otromba csúsztatásoktól sem riadsz vissza (lásd #155-ös eleje, amit a #165-ösben Ati_X_321 le is reagált, persze te véletlenül elkerülted a válaszadást). Amivel mellesleg ótvar személyeskedést próbáltál alátámasztani. Szívesen válaszoltam volna pár dologra, de elvetted a kedvem a beszélgetéstől. Ez nagyon megy neked. Hát gratulálok. Csak így tovább!
Kopi31415: "mert dezz nagyon egysíkúan csak a RT-t tarotta valósághűnek, miközben az általa linkelt dolgok, amiket meg tudtam eddig nézni nem igazán voltak azok."
Kissé kevered a dolgokat. Alapvetően arra válaszul linkeltem ezeket, hogy egyesek szerint ma még lehetetlen a real-time ray-tracing pl. egy asztalon elférő géppel. Ha az RT felsőbbrendűségét akartam volna demonstrálni, akkor ezeknél sokkalta jobb animokat is be tudtam volna linkelni, nem gondolod? Kapís végre!?
kisfurko: Bump-mapping állítólag nem is kellett, mert poligonokból volt kirakva, ami korábban bump-mapping volt, azon az alapon, hogy az RT több poligonnal boldogul. Egyébként amit a #177-ben írtál, arról már volt szó.
-
Raymond
titán
válasz
kisfurko
#180
üzenetére
Azert a Larrabbe kicsit mas kategoria lesz a mostani C2D-hez kepest. Az a 16 vagy 24 core 512bit SIMD operaciora kepes (16x32bit vagy 8x64bit) egyenkent. Ez magonkent eleve tobb mint amit egy C2 magbol most kisajtolsz. 16-24 darab ebbol azert mar teljesit valamit, az in-order voltuk nem szamit. Lehet akkora mar valami bump vagy normal map is rafer arra a Q4 level-re
Szvsz az lesz a vege hogy az Intel kihoz egy hibrid engine-t es halalra hypeolja majd a raytrace-es reszet. -
#06658560
törölt tag
válasz
Ati_X_321
#176
üzenetére
igen, láttam a számolásod, de már később. És szerintem megegyezhetünk abban, hogy ha tényleg élethűt akarunk, akkor még mindig kevés. Fénytörést, prizmahatást, stb-t figyelembe véve azért van még mit cinálni ezen a téren.
Interferencia: annyira nem ritka jelenség: ajtó nyitása sötét szobára, pl. ott azért érződik kissé a dolog. tudom, hogy veszettóül számolásigényes a történet, de elvileg maga a matematikai képlet nem túl bonyolult egy adott fényforrásból kiinduló fotonok ilyetén eloszlásfüggvényének meghatározására. megírni a programot rá, meg kiszámoltani valószínűleg már más tészta.
-
válasz
Ati_X_321
#179
üzenetére
De mi az, hogy lesz alá célhardver? Van rá javaslat, elképzelés? Van olyan kutatási eredmény, ami azokat a korlátokat átlépné, amiket Raymond említett, meg amik pl. a linkelt Pixaros anyagban vannak? A Larrabee nevű "célhardver" sima in-order x86-os magokat tartalmaz izmos SIMD egységekkel felturbózva. És mivel nem out-of-order, cache-miss esetén állunk egy helyben. Hiába lesz ebből mondjuk 16 benne, a belinkelt kvéket szerintem max. egy nagyságrenddel fogja gyorsabban futtatni, ugyanebben a ratyi minőségben. És ahogy Raymond is mondta, még ekkor sehol sincsenek a material shaderek.
-
Ati_X_321
aktív tag
A szures azert kell mert ha csak egy sugar van keppontonkent akkor gyakrolatilag point sampling "minoseget" kapnal. Ami nem kivanatos. Legalabb egy bilinearnak megfelelo kene ha mar tenyleg igenytelenek vagyunk.
ezt vágom, csak én a korábbi hsz-edben úgy értettem, hogy emiatt akarsz még sugarakat lődözni, valószínű megoldható a bilineáris hatás elérése enélkül is -
Az elejétől fogva olvasom a topicot, és már nem bírom ki szó nélkül én sem.
Folyton ezt a RT Quake-et hozod fel, amikor a Riva128-am 1998-ban jobb minőségű képet produkált Half-Life alatt. Ebből egyszerűen minden hiányzik. Se lightmap, se bumpmap... Ja, hogy ahhoz kurblizni kéne még 3-szor annyi textúrát? Érdekes módon akkor már nem lenne realtime. Vagy ok, nem kell lightmap, se bumpmap, hanem legyen GI, meg csillió poligon, jéé, így se realtime. Az, hogy a reflection/refraction életszerűbb, az egy dolog, de a körülöttünk levő dolgok kis része annyira áttetsző/fényvisszaverő, hogy ezen elvek oltárán fel kéne áldozni minden mást.
A másik probléma a Larrabeevel, hogy nincs semmi kutatási anyag, ami alátámasztaná, hogy a jelenleg ismert RT sebességet hogyan lehetne annyira megnövelni, hogy beérje a raszterizálós cuccokat. Ahhoz, hogy megjelenjen reális alternatívaként, már eredményeknek kéne lenni, hogy el tudják kezdeni a gyártást. -
Ati_X_321
aktív tag
válasz
#06658560
#172
üzenetére
RT tud kezelni hullámtermészetű jelenségeket? Rács és réseffektust?
nem mostanában fogsz látni diffrakciót, meg interferencia jelenségeket az tuti, de ha kisétálsz az utcára, ott sem olyan gyakori, hogy észrevenné az embernem a fény hullámtermészetével operál a sugárkövető
mivel minden átlátszó anyag minden hullámhosszon eltérően töri a fényt (prizma), ezért elvileg minden hullámhosszra külön kellene lekövetni a sugarakat (spektrális képszintézis), ehelyett 3 hullámhosszra (RGB) is épp elég hosszú ideig tart.
Konkretizálva. Egyetlen pixelhez 1, tíz, tizenöt, száz, ötszáz, ezer, vagy mennyi sugár információja fog tartozni?
fent leírtam, függ a rekurzió mélységétől, azt hogy hány visszaverődési, törési mélységet engedünk megMásrészről én inkább a hagyományosabb sugárvizasgálatot tartanám helyesnek, azaz a fényforrásból menni előre. igaz, hogy sokkal nagyobb a számítási kapacitás, de azért mégiscsak az lesz élethű, ha mindenáron azt akarjuk előhozni.
sugárkövetés a szemből kiinduló sugarak követésére szakosodott, a fényforrásból kiinduló sugarak csak elenyésző hányada éri el a szemet, ami nem, annak a számítása felesleges volt, és az pedig mindegy hogy a fényt milyen irányból követjük mindegy
más a helyzet Global Illumination esetén, ahol pont a fényforrások által kibocsátott fényutakból csinálnak fotontérképet/PRT-t, ezáltal "leleplezik" az indirekt fényforrásokat,
ez valóban jóval élethűbb és közelebb van a valósághoz, de ezt realtime esélytelen, nagyságrenddel nagyobb számításigénye van, mint a sugárkövetésnek, azonban statikus scenehez készül ilyen előre számított, globális illuminációs módszereket használó textúra, mai játékok is használják -
Raymond
titán
válasz
Ati_X_321
#174
üzenetére
A szures azert kell mert ha csak egy sugar van keppontonkent akkor gyakrolatilag point sampling "minoseget" kapnal. Ami nem kivanatos. Legalabb egy bilinearnak megfelelo kene ha mar tenyleg igenytelenek vagyunk.
A masik ami meg beleszol a sebessegbe az eddig emlitetteken kivul az a material shading. Mert a megvilagitas raytrace alapon OK, de tisztesseges feluletanyagok nelkul nem nez ki az egesz valami jol. Ez latszik meg az autos (Ferrai es Lambo) demokon is. A lakkozas magvalositasa nagyon sok kivetni valot hagy maga utan. Mert amig nem komoly minosegu feluletekkel dolgozol addig a shading nem problema ugyanis a raytrace resolve sebessege lesz a limitalo tenyezo. De bonyolult jo minosegu anayoknal mar beleszol a temaba a shading is.
-
Ati_X_321
aktív tag
ok, hogy nem holnap lesz, de én már nagyon várom
textúrázást, szűrést nem vágom, hogy kell raytracerben, csak raszteresnél
de tényleg összejön a sok sugár, én így számolom, hogy miből:
az első metszett objektumtól az összes fényforrás irányába + visszaverődés irányába + törésirányba = ez legalább 3 sugár, amiből az utsó kettő rekurzívan továbbhaladjátékban bőven elég lenne kezdetben 3-as mélységkorlát, ez esetben a sugarak száma
3+3*2+4*3 = 21 ha nem rontottam el -
#06658560
törölt tag
"szélére kell dönteni. Olyanok a sugarak, mint egy összegömbölyödött sündisznó tüskéi, ahol a sündisznó a képernyő közepén fekszik. És mivel a sugarak iránya adja ki a perspektívát, azok iránya fix, teljesen mindegy, hogy mi van a 3D-s modellen."
Ez szép és jó, perspektíva létrehozásához. DE. A teljesen máhonnan betükröző napfénnyel mi van? AMi esetleg bevakít?
RT tud kezelni hullámtermészetű jelenségeket? Rács és réseffektust?Konkretizálva. Egyetlen pixelhez 1, tíz, tizenöt, száz, ötszáz, ezer, vagy mennyi sugár információja fog tartozni?
Szerintem a nézőpontunk nem áll messze egymástól, csak másfele nézünk. Te próbálsz meggyőzni a RT nagyszerűségéről, amit nem vitatok, sőt, közben a hátrányait, kételyeit is szépen sorbaveszed, azonban amiért én beleszóltam itt eme komoly vitába az az volt, mert dezz nagyon egysíkúan csak a RT-t tarotta valósághűnek, miközben az általa linkelt dolgok, amiket meg tudtam eddig nézni nem igazán voltak azok.
Másrészről én inkább a hagyományosabb sugárvizasgálatot tartanám helyesnek, azaz a fényforrásból menni előre. igaz, hogy sokkal nagyobb a számítási kapacitás, de azért mégiscsak az lesz élethű, ha mindenáron azt akarjuk előhozni. -
#06658560
törölt tag
olvasd el mire írtam, és miért. dezz jött azzal, hogy a raszteres megjelenítés a nullához tart. A kétszeres sebesség is. Ezért kérdeztem, hogy a RT akkor vajh hova?
Egyébként amit ezzel kapcsolatosan pont emlegetett, hogy a kétszer lyan erős proci sem számít semmit... Hát, csak éppen minden poligonszámnál kb kétszeresére nő a teljesítmény, ha rendesen sikerül megduplázni a számításokat végző egység erejét. És mivel azon csodadiagramm függőleges tengelyelineáris volt, így a mentén a változások azért nem voltak oylan kicsik egy duplázásnál...Egyébként pont műszaki ember vagyok, különösen megspékelve matematikai érdeklődésel.
A problémám a megközelítéssel volt, hogy azért, mert midnen egyfele konvergál, ha az egyiknél közben fejlődött a technika, akkor annyival elintézzük, hogy a duplája nem a nullához tart szintén?// Lehet ha azt is megnézed mire válaszolok az könnyíti megérteni azt, amit írok miért írom.//
jelen esetben kérdéses az i, hogy egy raszteres megjelenítést, vagy egy RT megjelenítéest számoló hardvernél a számoló egységek milyen tempóban tudnak gyorsulni. Mert Ha valamelyik gyorsabban tud a technológiai lépések során, akkor nicns értelme a skálázódáson vitázni, amelyik ebben jobb, az le fogja hagyni a másikat mindenféle elemszámnál, még ha netalántán meredekebb is a görbéje. Jó dolog egy logaritmikus görbe, ahogy egy exponenciális is.
Az utolsó mondatoddal teljes mértékben egyetértek a kételyben.
-
Raymond
titán
válasz
Ati_X_321
#164
üzenetére
"se CPU, se Cell, se GPU nem raytracingre lett kitalálva, tehát az ilyen mondatok, hogy jelenleg 8 magnyi CPU-val 200k-s scene megy pl raytrace-szel, raszteres megoldással (egyelőre szebb végeredménnyel) meg 8M-s, és ezért a raytrace szar felesleges"
Lehet hosszuk voltak az utolso hozzaszolasok es igy elvaszett eredetileg mirol volt szo. Nem mondja senki hogy a raytracing felesleges vagy nem lesz belole semmi majd egyszer, hanem azt hogy nem lesz itt hasznalhato minosegu es sebessegu raytracing alapu engine 2 even belul (de szvsz meg 3-4 sem) amivel eladhato mainstream jatekokat lehet produkalni.
"akkor lenne egy fokkal jobb az összehasonlítási alap, ha a raytracinget és a software raszteres rendert hasonlítanák össze"
Ennek nem sok ertelme lenne. A vegeredmenyt kell osszehasonlitanod.
Kis perspektiva a szamokhoz amit irtal es ami szukseges normalis minoseghez/sebesseghez a raytracing alapu engine-el:
Az 1280x720-as 0.9MPixel-es felbontas mint pelda jo, de mar ma is csak a konzolokon ervenyes. A PC-n magasabb felbontasokban jatszik a nep mar ma is (1.3 vagy 1.76) es a konzolok is a magasabb, 2MP felbontasok fele mennek (1080p). De maradjunk a kb. 1MPixel felbontasnal. Ahoz hogy a generalt kepnek valami minosege is legyen nem eleg egy sugar egy pixelre. A textura filterezesnek (biliner, trilinear, aniso) is kell tobb suga, az AA-nak is es az arnyekoknak is. A minimum elvaras 10-15 sugar pixelenkent, de a mai rasteres mainstream-el megegyezo minoseg (Aniso, 4xAA-nak megfelelo elsimitas, arnyekok, masodlagos sugarak) kell 30 sugar is. Kompromisszumkent szamojunk 20-al. Igy az eredeti 1M pixelbol lett:
1M x 20 x 30 (FPS) = 600 millio sugar masodpercenkent
Egy kevesbe konzervativ jo minosegel es felbontassal (1920x1200) szamolo valtozat:
2.3M x 30 x 60 = 4+ milliard sugar masodpercenkent
A linkelt Q4 demo jelenleg kb. 100M rays/s sebesseget produkal az adott minoseg melett az adott hardverrel. Ezert van az hogy a 2 ev rovid ido arra hogy a vilagot megvaltsak ezzel.
Es akkor meg nem volt szo a scene komplexitasrol. Ezek a szamok nagyban fuggenek ettol is, mivel a szamolas forrasakent mukodo struktura felallitasa es pasztazasa novekszik a scene komplexitasaval meg ha statikusrol van is szo. Az igaz hogy ez utana nem valtozik a staikus scene eseteben, de ilyan jatekoknal nincs. Ha megnezed mi tortenik mondjuk egy CoD4 multi palyan akkor lathatod mennyi geometriai valtozas megy vegbe allandoan. Ezekhez ujra kell a strukturat generalni es pasztazni (nem az egeszet, csak update). Ez viszont mint idobe kerul. Az OK hogy a statikus reszekre szant KDtree megvan par masodperc alatt a parszaz poliginbol allo scene-re es azzal mar nem kell majd torodnod, de a dinamikus valtozasokkal meg mindig kell. Es ha az gyorsabb is a kevesebb poligonszam es arra valo optimalizalasnak koszonhetoen meg mindig problema. Mert ahoz hogy egy hasznalhato 30FPS-t el tudj erni egy frame generalasa csak 3.33 miliszekundumot vehet igenybe az inicializalastol a megjelenitesig. Ebbe kell beleferni a struktura valtoztatasoknak is ami ha csak 1 miliszekundum is mar eleve elvette majd a harmadata rendelkezesre allo idobol. Es akkor meg csak 30FPS-rol beszelunk. 60FPS-nel csak 1.66 miliszekundumod van egy frame-re. Igy abbol 1 ms nagyon sok
Szoval nem arrol van szo hogy feleslegesen fikazunk valamit, hanem arrol hogy a hype altal generalt almok es a rideg valosag per pillanat nagyon messze vannak egymastol.
-
-
ddekany
veterán
válasz
Ati_X_321
#164
üzenetére
"tehát (egy naív raytracer esetében) 1280x720-as felbontás esetén 921600 szál nyugodtan számolhatna a másiktól függetlenül"
Viszont ölnék egymást a memória elérésért, hisz mind el akarja érni a scene-t, és előre sokkal kevésbé kiszámítható, hogy milyen adat kell az egyes "szálaknak", mint raszternél. Mondjuk lehetne azt, hogy pl. 32 szálas csoportokban vannak, és minden csoportnak saját memóriája van, amibe kérdés nélkül replikálva van a teljes scene... kicsit RAM igényes.
-
Ati_X_321
aktív tag
Mert amint valtozik a scene ujra kell generalnod a KDtree-t es ez masodpercekig tart egy scenen.
ugyanez meg van raszteresnél is, mindkettő háromszögekkel dolgozik, szóval nem értem, hogy jön ez idea mostani játékok is kd fát használnak a pálya statikus részének leírásához (source engine, quake4), a dinamikushoz meg nem, ez eddig is így volt, továbbra is így lesz
raytracingnél is lehet ugyanez
mostani játékoknál kezd bejönni a full rombolható környezet, asszem láttam valami UE3-as videot ezzel kapcsolatban
BSP fát nem implementáltam még, kifejthetnéd, hogy miért kell újra felépíteni az egészet, ha módosítás történik, olyan megoldás nem jöhet szóba, hogy kiegyensúlyozatlan lesz a fa a módosítás után? erősen véges számú módosítás esetében talán nem olyan nagy probléma, mostani játékokba se rajzolhatod újra a pályát rakétavetővel.
vagy másik ötletem a módosuló partícióban lévő adatokat érvényteleníteni, és onnan egy pointerrel kimutatni egy dinamikusan jól karbantartható adatszerkezetre, persze ekkor is "kiegyensúlyozatlanná" válik
Most mar vili hogy miert nem mozog semmi azokon a CELL relatime RT demokon?
pedig simán mozoghatna, csak nem az objektumot kell eltranszformálni (nem háromszög esetén amúgy is bajos), hanem a sugarat kell inverz transzformálni -
Ati_X_321
aktív tag
se CPU, se Cell, se GPU nem raytracingre lett kitalálva, tehát az ilyen mondatok, hogy jelenleg 8 magnyi CPU-val 200k-s scene megy pl raytrace-szel, raszteres megoldással (egyelőre szebb végeredménnyel) meg 8M-s, és ezért a raytrace szar felesleges
akkor lenne egy fokkal jobb az összehasonlítási alap, ha a raytracinget és a software raszteres rendert hasonlítanák össze
az meg hogy melyik proci hány GFLOP teljesítménnyel rendelkezik, az még nem árul el semmit affelől hogy raytracingre mennyire alkalmas
korábban is írták, hogy a raytracing teljesen párhuzamosítható, konkrétan minden pixel kiszámítása futhatna párhuzamosan a többivel, tehát (egy naív raytracer esetében) 1280x720-as felbontás esetén 921600 szál nyugodtan számolhatna a másiktól függetlenül.
CPU-nál általában annyi szálat érdemes futtatni, ahány magos
GPU nagyon sok szálat tud párhuzamosan futtatni (és kell is), de a szálak nem függetlenek egymástól, ugyanazt csinálják (MAD), csak más adatokon (pehelysúlyú szálak, buták, ha vmi elágazás jönne az egyik szálban, akkor kb szétesik a pipeline, többi szálat is megfogja, stb..). Asszem egy G80-ban 14 körüli a multiprocesszorok száma, amik tudnak szálakat vezérelni (multiprocon belül a szálak ugyanazt csinálják).Raytracing esetében az egyes sugarak más fényutat járnak be, más tárgyakkal ütköznek, emiatt a szálak külön életet élnek, futásuk működés szempontjából is független egymástól, nem csak a feldolgozott adatok szintjén.
A logaritmikus skálázódást konkrétan a BSP-fa teszi lehetővé statikus esetben, de van megoldás dinamikus scene-re is.
nyílván intelék picit jobban értenek hozzá
), de sztem olyan proci kell, ami vhol a CPU és GPU között van, tehát lebegőpontos számításra kihegyezve mint a GPU, de nem pehelysúlyú szálakkal, és inkább több multiprocesszor legyen, kevesebb hozzátartozó szállal (a szomszédos pixelre jutó sugarak jó eséllyel ugyanazt a fényutat járják be, ugyanazokkal a tárgyakkal ütköznek) + vmi hardveres BSP cache -
ddekany
veterán
válasz
#06658560
#153
üzenetére
"masik: hova konvergal a RT szamolas? Csak nem ugyanoda, mind a masik variacio? Mert ha igen, akkor miert is tepjuk a szankat?"
Hm... gondolom te nem vagy műszaki ember, de legalábbis nem szereted a matekot. Rengeteg más problémára vannak különféle megközelítések, pl. lista sorbarendezésre, hogy a legegyszerűbbet mondjam, és naná, hogy mindnek az ideje ugyan oda konvergál a lista elemszámának a növekedésével, a végtelenbe. Hiszen egy hosszabb listát mindig több idő rendezni, mint egy kicsivel rövidebbet. Csúnya is lenne, ha egyszer csak megállna a lassulás. De állatira nem mindegy a jelleg, annyira, hogy az már nagy listáknál fájni tud. 1 másodperc és 1 óra, hát nagyon nem mindegy. És persze a lista hosszától (is) függ, hogy melyik rendező ötlet a nyerő. Na, ugyan ez még kiderülhet a ray-tracing-ról, bár ha ki fog, akkor kétlem hogy 10 éven belül.
-
ddekany
veterán
válasz
#06658560
#151
üzenetére
Ezekre szerintem már mind válaszoltam... A ray-trace a fény pattanásokkal is kalkulál (hiszen azokat is ki lehet következtetni visszafelé haladva), mint mondtam, és a mögötted lévő falról pattanó fény sem speciális eset. Aztán persze a kevés sugár és egyéb egyszerűsítések miatt még sem tőr ki a Kánaán, de ezt már írtam.
Ja, a perspektíva... a szélére kell dönteni. Olyanok a sugarak, mint egy összegömbölyödött sündisznó tüskéi, ahol a sündisznó a képernyő közepén fekszik. És mivel a sugarak iránya adja ki a perspektívát, azok iránya fix, teljesen mindegy, hogy mi van a 3D-s modellen.
-
Raymond
titán
Olvasd el azt az elso bekezdest es probald meg megerteni. Koncentralj a masodik felere ahol a dinamikus scene-rol, az azokat gyorsito struktorahoz es a veluk elert sebesseg/minosegrol van szo. Aztan ha a sajat magad altal linkelt Pohl cikkben nem jutottal volna el a szovegig csak a kepekig beidezem neked:
"The demo system that was on display at IDF was running a dual-quad core (total 8 cores) system as you can see from the 8-threads being processed in the task manager on screen."
"In the upper left corner you can see a frame rate counter for this live test running at a 1280x720p resolution (or slightly smaller since it is in a window form). We have a 99 frames-per-second rate being shown..."
Tehat 8 Kentsfield mag kell ahoz hogy a videon es kepeken lathato "minoseget" elerjek 1Mpixel-nel kisebb felbontason. Super.
Hasonlo okorkodesek helyett inkabb probalj a feltett lenyegi kerdesekre valaszolni.
-
Raymond
titán
-
Raymond
titán
Valasz a #136 "fejezetedre"
"Arról van szó, hogy az élethű füstnek nem csak a gomolygása számításigényes, hanem a megjelenítése is. Mivel hogy nem néhány poligon egy füst textúrával, undorító és illúzióromboló (még azt a kicsit is, ami volt) éles élekkel a metszéseknél, stb."
"Nem láttam még ilyenekben élethű füstöt - nem a gomolygást illetően, bár az is megér egy misét: ha egyszer textúráról van szó, az nem térbeli, így élethű térbeli gomolygást sem igazán lehet vele összehozni."
Lassuk csak hogy is mondtad? "Ha valamit nem értesz meg, az nem biztos, hogy hülyeség." Egy ujabb ekes bizonyiteka a temahoz valo "hozzaertesednek". Azon kivul hogy a jatekokban is mar eleg szepeb meg van oldva a fust meg lehet rajta javitani persze de mondjuk a felhozott problemara is van mar megoldas nem egy jatekban. Pl. az emlitett Bioshock-ban sem latod a poligon szeleket normalis minoseg beallitasa mellett. A CoD is megoldotta. Ami igazan tetszett az a Lightwave es a Maya beszolas volt
Egesz Hollywoodnak jo volt nem egy tobbszoros dijnyertes filmhez a minoseg, de legyen igazad...total nem elethu Valasz a #137-es reszre:
"Ha esetleg jobban megnézted volna, itt interactive preview-ről van szó. Biztos bolondgombát ettek, hogy a végső rendereléskor mégis a sokkal lassabb ray-tracinget használják."
Tudom hogy mirol szol amit linkeltem neked, nem most latom eloszor. Azert adtam meg hogy lasd milyen minoseget es sebesseget lehet elerni azzal a preview method-al. Hogy lasd az idobeli kulonbsegeket amibolt ket dolgot kellett volna leszurnod kis gondolkodas utan. Az egyik hogy a minoseg csokkenese sokkal kisebb mint amire a nyert szamolasi sebessegbol gondolnad (0.1 mp versus 2000mp). A masik hogy a megvilagitas fontosabb mint az hogy a kromozott lokharitoban fizikailag realis visszaverodesek legyenek.
"Naná, hogy észrevettem, a Pixar filmek mindig is totálisan "plasztikusak" voltak a számomra."
Basszus mennyire kiszamithato volt ez a valasz
"Naná, hogy észrevettem, a Pixar filmek mindig is totálisan "plasztikusak" voltak a számomra."
Ez mar komolyan szanalmas....szoval a Bioshock vagy egy Crysis ami osszehasonlithatatlanul jobban nez ki es azert valami jatekmenet van mogotte nem tud lekotni csak 2mp0ig de a Pohl fele Q4 RT level igen? Fantasztikus. Legalabb kicsit normalisabb erveket kene felhoznod.
"Nézd már meg, mennyit számít a két kártya közötti kb. 2x-es különbség egy idő után! Semmit, együtt konvergálnak a nullához. Egy 5x gyorsabb kártyának is ez a sorsa."
Par aprosag ha mar nem jossz ra magadtol. A cikkbol idezek:
"In fact we measured this and found that the intersection point is in the vicinity of the 1M triangle range, i.e., when the scene complexity exceeds 1M triangles, a SW ray-tracing solution will always outperform a HW raster solution."
Ez mar most hulyeseg. Ha osszehasonlitod egy G92 vagy R670 sebesseget az FX5900Ultraval akkor vilagos hogy a tablazatban szereplo mondjuk az 1M poligon 22FPS sebessege boven a 100 felett kell hogy legyen. Es most csak a hasamra csaptam. Jo lenne az a program hogy ki lehessen probalni
Tehat hiaba konvergalnak a nullahoz ha meg a 3M scene-t is gyorsabban kepzi le jobb minosegben mint a softveres RT. Meg milyen engine volt mar az ugy igazabol? Azota kicsit masok a hardverese lehetosegek shader ugyben is. Meg talan az Intel nem eroltette meg magat annyira a raszteres verzio irasa kozben
"Melyikeken? A cikkben? Ha már screenshotok, inkább ezeket."
Ja, azokat neztem en is. Nem estem toluk haszra. Onnan linkeltem azt is ami arra a gyonyoru 3DS environmental mappingra emlekeztet
Az egesz sehogy nem nez ki. Nemhogy normal mapping meg bump mapping sincs rajtuk. Az meg azert mar tenyleg nem mai gyerek.[I]"Jaj, hagyjuk már szegény golyókat, nem csak azokról van szó.
Kár, hogy ez csak egy csalás, ami csak így első ránézésre életszerű (vagy még így sem)."[/I]
En hagynam, de ha mindig azzal jossz vissza. Meg a linkeld cuccaidban sincs mas normalis dolog mint a golyo vagy golyo nelkuli tukrozodes.
"Én meg azt remélem, hogy az életszerűség igényéből nem nőttek még ki."
Nem nottek eppen ezert nem az a norma amiket eddig it linkelgettel. Mert azok mind nagyon-nagyon messze vannak az eletszerusegtol.
-
Raymond
titán
En: "Az nyirja ki a raytrace enginedet hogy egy jatek scene nem statikus. Es akkor a frame setupnal meghalsz."
Te: "Nem felejtem el. Miért halnék meg jobban, mint raszterezésnél?"Gyakorlatilag ezzel a kijelentessel automatikusan diszkvalifikaltad magad minden tovabbi diskurabol mert vilagos hogy fogalmad sincs mirol beszelsz. Ahoz hogy elkezdhess szamolni raytracing-el egy scene-t eloszor fel kell allitanod a strukturad. Miutan a KDtree (legelterjedtebb mert a legnormalisabb egyelore) megvan akkor kezdheted a leptetest rajta keresztul hogy elvegezd a szamolasokat. Itt jon a kepbe az hogy miert problema a dinamikus scene (tehat minden program/jatek ahol az objektumok mozognak is. Mert amint valtozik a scene ujra kell generalnod a KDtree-t es ez masodpercekig tart egy scenen. Annyi idod nincs mivel a cel nem "X seconds per frame" hanem "X frames per second" es az az X lehetoleg 30+ legyen. Most mar vili hogy miert nem mozog semmi azokon a CELL relatime RT demokon? Azok az akceleracios strukturak amik a dinamikus scene-eket celozzak meg egyelore nem segitenek rajtad (es ezen a Larrabbe sem fog sokat valtoztatni) mert azok meg a scene statikus reszeire nem jok (ertsd lasabb mind a KDtree traversal). Egy kombinacios megoldas mar jobb, csak meg azzal is csapnivalo eredmenyeket (minoseg/sebesseg) ersz el ahoz kepes amit a mainstream jatekoknal latsz.
"Persze, de éppen erről beszélek, hogy mi van, ha ott nem csak egy kép van, hanem egy dinamikus scene."
Lasd az elobbi valaszt. Az lenne hogy azt a Lambo demot nem mutattak volna be mert senki nem kivancsi ra ha tobb masodpercig tart egy frame szamolasa.
"Itt nincs semmi a háttérben?"
Van, statikus nem mozgo epuletek mas nem. Irrelevans a jatekokrol szolo temanal. Lasd megintcsak az elobbi valaszt.
"Ott hol van fénytörés?"
Nem azert linkeltem hogy van vagy nincs fenytores hanem azert hogy lasd megkapod azt a minoseget mint a Lambo-s demonal es mert hasonlo volt a scene (egy auto forog korbe). A masik ok amiert linkeltem hogy lasd nem a raytracingtol lesz realisztikus a dolog hanem a surface shaderek minosegetol. Ezet nez ki ugy peldaul a Ferraris demoban az auto a GT5P-hez kepest mint a muanyag jatekauto mert a feluletet nem tudtak normalis minsegben lekepezni. Ehez a raytracing nem eleg, a material shader-nek kell normalis minosegunek lennie. Es ha meg figyelembe veszed hogy jatek kozben ezekbol 16 hajkuraszik a palyan nem egy forog csak korbe az pedig eleg sokat mond az RT es a mostani megoldasok kozti szakadeknyi (kontinensnyi?) sebessegkulonbsegerol.
"Úgy, hogy ott is ugyanazt a tengely+metszés eljárást használják, csak nem egyet számolnak ki, hanem pl. 3-at, és átlagolják az eredményt."
Nezd meg mennyi munka ment az utobbi ket evben a jatekoknal a kulonbozo arnyekszamolasok fejlesztesebe es hogy milyenek a minosegi es sebessegi eredmenyek. Az arnyekokrol szolo eddigi nyilatkozataidbol azt hiszem meg leszel elpodve. Egyebkent most lett vege a GDC-nek, ott is volt egy-ket erdekes eloadas foleg Marco Salvi-tol.
"A 14 Cell eleve nem otthoni környezet, így az az érv, hogy sok fényforrás, vagy más efféle alaposan leterheli, nem igazán ésszerű érv... Mert itt mindegy, hogy 14 vagy 25. Lényeg, hogy egy íróasztalon elférő cuccal képesek elég jó ray-tracingre real-time ma is."
Nem tudom megfigyeted-e de azt (is) probaljuk veled megertetni mar egy jo ideje hogy a 14 CELL demok linkelese nem otthoni kornyezet igy lenyegtelen a jatekokrol szolo diskuraban. Egyebkent nem ertem miota "iroasztalon elfero cucc" a 7 darab QS20/QS21 blade server. Meg meg persze ott van az is hogy az az "elég jó ray-tracingre real-time ma is" eppenhogy nem eleg jo. Ennel messze jobbat kell produkalni kevesebb vassal hogy "eleg jo" legyen.
"Azért nézzél meg párat ebből is. Aztán szorozd meg úgymond az egészet annyival, amennyivel több mag lesz a Larrabeeben, mint a mai procikban."
Megneztem mar joparat es eddig semmi hasznalhato nem jott elo. Te is csak a szarul kinezokat linkeled azt ami jol nez ki meg nem. Csillogo-tukrozodo golyokal linkelni semmi ertelme. Ebbol kinottem az Imagine 2.0 hasznalata alatti elso par hetben mar vagy 15 eve.
"Éppen ezért nem teszek olyan állításokat, mint te..."
Az allitasaid minsegehez ott az elso pont amire valaszoltam. Egyebkent meg mast mint a marketing szovege meg egyelore nem hallottam. Sem ertelmes szamokat sem normalis minosegu kepeket/videokat nem linkeltel.
"Na ja, egy autót könnyű viszonylag élethűre csinálni ilyen fake tükröződésekkel, stb. Attól még nagyon műen néznek ki a mai játékok, főleg ami a külső tereket illeti, az olyan, mint egy rajzfilm."
Akkor megsem kell araytracing ha lehet a temat elethure csinalni? Az tetszik igazan hogy lemondod a GT5P-s minoseget es a raytracing ueberseget meg a Ferraris es Lambos muanyag csodakkal tamasztod ala
"Kit érdekel, hogy most mi van, amikor itt pont a Larrabee a lényeg? Azon kell jól futnia a ray-tracingnek, az Intel szerint."
Az elobb meg azt mondtad nem tudod milyen fejlesztesek folynak a szinfalak mogott ezert "nem teszek olyan állításokat, mint te..." most meg egy nem latott chip a fo argumentum hogy az lesz a kanaan amikor kijon? Pliiz...
"hiába gyorsabb az a 3850, ha az élethűségtől kb. ugyanakkora távolságra van."
Mar megint ezzel a mu hulyeseggel jossz? Ez majd akkor lesz erv a kezdben amikor legalabb egy jobb kinezetu RT demot belinkelsz.
A masik kettore kulon valszolok, direkt osztottam fel. Nincs ertelme kilometeres hozzaszolasokat irni.
-
dezz
nagyúr
Azért hozzátenném, hogy a valóságban a fény nem részecske alakban terjed, hanem kvantummechanikai hullámok formájában, szóval a tökéletes lemodellezés szinte lehetetlen dolog.
(#149): Ez rendben is van, én sem mondtam, hogy minden szempontból élethűbb. Viszont:
- A gagyi environment mapping helyett jó lenne már valami életszerűbb tükrőződéseket látni.
(Nézd meg pl. ezt a videót! És az az "approximate ray-tracing" még mindig csak egy fake megoldás. Szal ha más is mozogna ott, rögtön nem lenne ilyen jó. És már ettől is a felére esik az fps, pedig a golyó a képernyő kis részét teszi ki.)
- Az sem baj, ha a fénytörések sem olyan rosszak.
- Meg ha az árnyékokkal sem spórolnak.Ezen kívül, ha eleve így kezdjük leképezni a dolgokat, egy sor egyéb effektust is élethűbben oldhatunk meg.
(#150) Kopi31415: "Pontosan mennyi lesz az a sok?"
Asszem többtíz."Plusz a mostanaban mutogatott szamitasokhoz mekkora szamitasi kapacitast fogtak be? Pl Lambo a 3 PS3-mal. 24 mag, a ha jol tudom jelenleg letezo egyik legjobb processzorban."
3 Cell = ~600 GFLOPS. (De ezek nem egy-az-egyben összevethető adatok, mert pl. a G92 egymagában is 500 körül van, sokmindenben mégis sokkal lassabb, mint akár 1db Cell.)
"Osszesen mennyi az ara mondjuk ennek?"
3 PS3 = 1200 dollár.
"Es mekkora tempot volt kepes elerni?"
Az autós demókban 5-10 fps-t.
"Mennyivel lesz ehhez kepest gyorsabb a Larrabee, amikor megjelenik, figyelembe veve, hogy meg nem lesz optimalizalva hozza semmi?"
Azt nem tudom, de az IBM ray-tracere nem éppen game-orientált, miközben az Intelé igen, és állítólag 10x gyorsabb a szokásosnál.
"Mennyi fog belole kelleni egy elvezhetoen futtathato jatekhoz?"
A 90fps-es ray-tracelt Quake4-hez 8 mag kellett. 32 maggal már egy jóval komplexebb scene is elmegy...
(#151): Így van, de sem mondtam, hogy az alap ray-tracing máris 100%-osan reális képet ad.
Viszont:
"Perspektivahoz: merre kell donteni a sugarat? Szelre, kozepre? Rengeteg esemeny van, ami fenyt=informaciot kepes juttatni ugyanabba az erzekelobe( szembeli receptor, CCd egy erzekeloje, monitor egy keppontja ha RT) Es ha valosaghu kepet akarunk, akkor ezt midnet meg kell hatarozni. Ahogy fogalamztad, ebben leolvadna minden gep, mire megcsinalna egy sima szobaban is akar."Talán nézd meg ray-tracing alapjait.
(#153): "Ehhez ket kerdes: te beleszerelmesedtel a fenytoresbe? Minden RT demo eddig azt feszegette, holott nagyreszuknek ezzel semmi koze nem lett a valosaghoz. Es folyamatosan a fenytorest, mitn szamolast hozod elo.Neked csak a fenytores jelenti az eletszeruseget? Csak kromkalitkak es falak kozott tudod elkepzelni a vilagot?"
Ezt miből vontad le? Mert ezek sokkal jobbak a ray-tracingben? Attól még van ott más is.
"masik: hova konvergal a RT szamolas? Csak nem ugyanoda, mind a masik variacio? Mert ha igen, akkor miert is tepjuk a szankat? Meg ha lenyegesen bonyolultabb modelleknel is fog ez bekovetkezni."
Azért nem egészen mindegy...
"Azert a RT-s fps-ek sem valami hudefenyes teljesitmenyrol arulkodnak. Es azokat nem C2D-n futtatjak. Te emlegeted folyamatosan, hogy hozzadobunk meg egy adag Cellt. Akkor miert lesz ebbol barmi othhon elvezheto? Magyarazd mar meg, ha jelenleg tizensok Cell kell valami kiszamolasahoz, max 20 fps-herz, es azt hozod elo, ha bonyolodik, akkor meg egy adag Cell, mikor fogja ezt egyetlen Larrabee kiszamolni?"
Lásd kicsit feljebb.
-
#06658560
törölt tag
Ehhez ket kerdes: te beleszerelmesedtel a fenytoresbe? Minden RT demo eddig azt feszegette, holott nagyreszuknek ezzel semmi koze nem lett a valosaghoz. Es folyamatosan a fenytorest, mitn szamolast hozod elo.Neked csak a fenytores jelenti az eletszeruseget? Csak kromkalitkak es falak kozott tudod elkepzelni a vilagot?
masik: hova konvergal a RT szamolas? Csak nem ugyanoda, mind a masik variacio? Mert ha igen, akkor miert is tepjuk a szankat? Meg ha lenyegesen bonyolultabb modelleknel is fog ez bekovetkezni. Azert a RT-s fps-ek sem valami hudefenyes teljesitmenyrol arulkodnak. Es azokat nem C2D-n futtatjak. Te emlegeted folyamatosan, hogy hozzadobunk meg egy adag Cellt. Akkor miert lesz ebbol barmi othhon elvezheto? Magyarazd mar meg, ha jelenleg tizensok Cell kell valami kiszamolasahoz, max 20 fps-herz, es azt hozod elo, ha bonyolodik, akkor meg egy adag Cell, mikor fogja ezt egyetlen Larrabee kiszamolni?
-
#06658560
törölt tag
Az rendben is van, de mekkora teruletet akarunk bemodellezni? Legyen csak egy szoba, aminek alljunk egyik csuicsa fele kb harmadolotavon, a ter minden iranyaban. nezzunk kisse ferden a velunk atellenes el melle valamennyire. Vegyuk fel az emberi latomezot. Az elethu kephez amig ezt a latomezot nem kepesek a kiinditott sugarakkal lemodellezni, addig nem szabad itt meg a nagy dezznek sem elethusegrol beszelnie.Mert barmily meglepo te az adott pozicioban meg azon fenysugarakbol is fogsz informaciot szerezni, amik tortenetesen a mogotted levo falon tornek meg, es melloled indultak. Csak mire eljutnak a szemedig addig rengetegmas elemen is torni fognak, szorodni, es csokkenni intenzitasban. De megis lesz komoly hatasuk. mivel a szem kettos integralast vegez a kep kialakitasakot-ill lehet az agy- ezert valahogy ezt kell osszehozni.
Perspektivahoz: merre kell donteni a sugarat? Szelre, kozepre? Rengeteg esemeny van, ami fenyt=informaciot kepes juttatni ugyanabba az erzekelobe( szembeli receptor, CCd egy erzekeloje, monitor egy keppontja ha RT) Es ha valosaghu kepet akarunk, akkor ezt midnet meg kell hatarozni. Ahogy fogalamztad, ebben leolvadna minden gep, mire megcsinalna egy sima szobaban is akar. -
#06658560
törölt tag
Pontosan mennyi lesz az a sok? Plusz a mostanaban mutogatott szamitasokhoz mekkora szamitasi kapacitast fogtak be? Pl Lambo a 3 PS3-mal. 24 mag, a ha jol tudom jelenleg letezo egyik legjobb processzorban. Osszesen mennyi az ara mondjuk ennek? Es mekkora tempot volt kepes elerni? Mennyivel lesz ehhez kepest gyorsabb a Larrabee, amikor megjelenik, figyelembe veve, hogy meg nem lesz optimalizalva hozza semmi? Mennyi fog belole kelleni egy elvezhetoen futtathato jatekhoz? Elerheto lesz?(GYk.: 600e/proci)
amennyiben ezek kozul nem midnre igen a valasz, akkor meg a kozeljovo odebb van/lesz.
-
ddekany
veterán
"Kár, hogy ez csak egy csalás, ami csak így első ránézésre életszerű"
Ezeken szerintem kár lovagolni, mert eltekintve néhány szélsőséges esettől (pl. imént általam említett asztal csendélet) nem attól lesz valami életszerű, hogy a tükröződések meg fénytörések korrektebbek. Úgy általában én nem hiszem, hogy a realtime ray-tracing eredendően lényegesen élethűbb mint a raszter. A kérdés itt a skálázódás (azaz, hogy igaz-e, hogy valós alkalmazásokban is gyorsabb lesz bonyolult modelleknél), és hogy majd milyen relatime speciális effekteket lehet ráépíteni egy ray-trace alapú megjelenítésre, amikről most még esetleg nem is tudunk. Pl, jobb füst, ki tudja...
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
ddekany
veterán
"nem lenne egyszerűbb egy olyan 3D-s kivetítő/megjelenítőt tervezni ahol igazi fény renderelhetne valós időben?"
Na ja, a természet nem csak a legvalósághűbb, hanem a leggyorsabb 3D látvány "számoló" is... Már csak az az aprócska kérdés maradt ki, hogy hogyan hozol másodperc törtrésze alatt létre térben olyan 3D-s struktúrákat, amik megfelel a digitálisan tárolt scene-nek...
Pl. a GPU helyén egy kis doboz lenne, amiben kis robotok gyorsan megcsinálják gyurmából rendesen 3D-ben a frame-et, és lefényképezik digitális fényképezőgéppel... (V.é., mélységélességélesség effekt ingyen!) -
ddekany
veterán
válasz
#06658560
#138
üzenetére
Nem teljesen viágos mit akartál mondani, de azért megjegyetném, hogy tényleg csak az a "fénysugár" (vagy képzeld el fotonnak, mindegy) számít, ami -- javarészben több pattanás után! -- eléri a szemedet. A többi nem számít, nem érzékeled, ez fizikai tény. Innen ered az raytracing alapötlete, miszerint a szemtől visszafelé követik a fény útját, mert így a "fotonok" 99.999999%-ával (a szám csak hasra volt) nem kell számolni, mivel a valóságban sem számítanak, csak azt 0.000001%-ot kell vizsgálod, ami bármilyen hatással is van a látványra. Mármint csak kellENE... a dolog ott bukik, hogy még ezt a 0.000001%-ot sem lehet lekövetni, közel sem, és a kevés sugárral meg aztán az egyéb egyszerűsítésekkel (tökéletesen sima tárgyak, stb) csomó jelenség nem jön magától létre (pl. szórtfény), és akkor próbálják utólag pótolni ezeket, pl. GI-vel meg AO-val, meg speciális árnyékot létrehozó trükkökkel. A "sima" raytracing ezért ad ugyan olyan "műanyag" képet (mintha tökéletes tárgyakról készült volna a kép a világűrben), mint a "sima" raszter. Persze csak eltekintve a pontosan tükröződő felületektől vagy az görbeüvegen való átnézéstől, mert abban a raszter rosszabb... csak hát nem ezeken múlik, hogy élethűnek érzel-e egy képet, hacsak nem egy poharakkal teli asztalt ábrázol fényes fémedényekkel.
"Azaz nem csak a monitorra merolegesen kell kiinditani egy keppontbol a fenyt"
Egyébként természetesen nem merőlegesen indítják őket, hiszen akkor nem lenne perspektívikus a kép (azaz a távoli dolgok nem látszanának kisebbnek). Csak a képernyő közepén induló sugár merőleges a képernyő síkjára, a széle felé közeledve meg egyre inkább a képernyő széle hajló szögben indulnak már.
-
dezz
nagyúr
válasz
#06658560
#138
üzenetére
Na jó, mégis.
"Lencsehatas mond valamit? Fentores, tukrozodes (8-as optika)"
Itt a mi végünkön nincs semmilyen lencse... (Csak a saját szemünkben, amivel a monitort nézzük.
)"Azaz nem csak a monitorra merolegesen kell kiinditani egy keppontbol a fenyt, mert a valosagban sem csak egy pontbol fog oda beesni, hanem sok iranybol. Akkor mirol beszelsz most?"
Eleve nem csak derékszögben, mert akkor csak egy monitor méretű hasábot jelenítenél meg.
Amiről te beszélsz, az akkor kellene, ha a fókuszálást is szimulálni akarnánk."A valosagban ha neked van egy x*y meretu erzekelod, akkor annak minden pontjaba a kornyezo ter minden pontjabol szamolnod kell a beeso fenyt, ha az ott megjeleno kepet kell merned. Ertelemszeru szukitesekkel: objektiv lencseje, stb. De ez akkor is minden egyes kepponthoz az objektiv teljes feluletebol kell, hogy kiinduljon, nem csak egy meghadott iranyban, kulonben nicns ertelme az egesznek. Gondold csak vegig."
Lásd fent.
"Azt azonban meg midnig nem tudtad bebizonyitani, hogy ez lesz a kozeljovo otthoni felhasznalasnal. amig olyanokkal jossz, hogy betesznek meg egy bladet, addig nem lehet ezt otthoni felhasznalasnak tekinteni. Erre valamiert folyamatosan nem reflektalsz."
De igen. A Larrabbe eleve sokmagos lesz, és utána évente duplázzák. Mint ahogy a Cellből is jönnek kifelé majd a sokmagos változatok.
(#139): Mint írtam, nem minden esetben jön be. De nézd majd meg azt az izosurface-es papert.
(#140): Mint írtam, egyelőre nem hologramot akarunk létrehozni.
-
polika
senior tag
Teljesen laikusként egy hipotetikus kérdés fogalmazódik meg bennem...nem lenne egyszerűbb egy olyan 3D-s kivetítő/megjelenítőt tervezni ahol igazi fény renderelhetne valós időben? Szal ha lenne vmi olyan OLED vagy anyag ami fényt meg mintát szolgáltatna és aztán csak azt kéne verzérelni mit sugárzik ki a fény meg egy megfelelő mátrixban visszaverődne, renderelődne stb.
-
dezz
nagyúr
"Ja, es a raytracing is nem csak a sugarkovetesbol all. Ezt valahogy elfelejted mar tegnap ota minimum Az nyirja ki a raytrace enginedet hogy egy jatek scene nem statikus. Es akkor a frame setupnal meghalsz."
Nem felejtem el. Miért halnék meg jobban, mint raszterezésnél? És itt legalább nem kell mindenféle map-generálásokkal kezdeni. (Már amikor azok dinamikusak raszterezésnél, mert ugye sokszor nem azok.)
"Mondtam ha nem igy van, bizonyits be egy mukodo demoval. Sok sikert."
Azon leszek, köszi.
"Az R300 demonal nem tudom melyik masik hasonlorol beszelsz. Azok alapjan amit leirtal az volt amit irtam."
Mint írtam, az egyik egy múzeumféle volt lebegő tárgyakkal, a másik meg egy tisztás egy szoborfélével.
"A scene komplexitasrol meg annyit hogy annak a demonak pont az volt a lenyege - az a hatterkep volt a IBL forrasa. Egyebkent a Lambo- raytrace demoban sem latom hogy tomve lenne a hatter barmivel is"
Persze, de éppen erről beszélek, hogy mi van, ha ott nem csak egy kép van, hanem egy dinamikus scene. Raszterezésnél minden képkockánál a 6 fő irányban le kell renderelni az egészet, ráadásul nagyfelbontásban, hogy nagyító hatásnál ne legyen randa. Ray-tracingnél meg annyi sugár megy tovább, mint ahány pixelt elfoglal az objekt a képernyőn. (AA-t mindkét esetben félretéve.) (Az olyan statikus, 1x számolt mapot inkább hagyjuk, amikoris a táj látszik, a mozgó objektek viszont már nem.)
Itt nincs semmi a háttérben?
"Nezd meg az a sok belinkelt GT5P videot es kepet - hat ugy Egesz jol megy nekik szeritem."
Ott hol van fénytörés?
"A GI-t nem valtod ki Ambient Occlusion-nal mert mindketto masrol szol. Kicsit olvass utana."
Megtettem (még linkeltem is): "However, it is a very crude approximation to full global illumination." [link]
"Az arnyekok megoldasa meg milyen erv mar? Ha mas megoldast hasznalsz akkor hogy tamasztja ala a raytracing-es ervedet?"
Úgy, hogy ott is ugyanazt a tengely+metszés eljárást használják, csak nem egyet számolnak ki, hanem pl. 3-at, és átlagolják az eredményt.
"Kismilliomodszorra leirva - mi koze van ennek az otthoni megoldasokhoz hogy a jatekok raytracing enginet hasznalhassanak? Semmi."
A 14 Cell eleve nem otthoni környezet, így az az érv, hogy sok fényforrás, vagy más efféle alaposan leterheli, nem igazán ésszerű érv... Mert itt mindegy, hogy 14 vagy 25. Lényeg, hogy egy íróasztalon elférő cuccal képesek elég jó ray-tracingre real-time ma is.
"Wow - offline render? Es akkor mi van? Semmi koze ahoz amirol most beszelunk. Mehet vagy nem az egy dolog a masik meg hogy nem latni sehol hogy menne."
Talán mert az offline renderelőkkel manapság nem is erre törekednek? Hanem nagy precizitású, a játékok grafikáját alaposan meghaladó minőségre.
"A realtime raytrace demok meg ugy neznek ki ahogy."
Azért nézzél meg párat ebből is. Aztán szorozd meg úgymond az egészet annyival, amennyivel több mag lesz a Larrabeeben, mint a mai procikban.
"Az hogy mi megy a szinfalak mogott milyen erv mar megint? Honnan tudod a tobbi megoldasnal mik mennek a szinfalak mogott? Ja ugy hogy par honapjara ra kijon valami es lathatod a sajat szemeddel egy jatek formajaban? "
Éppen ezért nem teszek olyan állításokat, mint te...
"Na ne rohogtess mar. A belinkelt GT5P autovalsztas jobban nez ki mint a Ferraris demo es minimum egy szinten van a Lambo-val. Es 60FPS-el megy egy PS3-on raytracing nelkul."
Na ja, egy autót könnyű viszonylag élethűre csinálni ilyen fake tükröződésekkel, stb. Attól még nagyon műen néznek ki a mai játékok, főleg ami a külső tereket illeti, az olyan, mint egy rajzfilm.
"Azert mert a Larrabee nincs itt es nem is lesz meg 2 evig."
Kit érdekel, hogy most mi van, amikor itt pont a Larrabee a lényeg? Azon kell jól futnia a ray-tracingnek, az Intel szerint.
"A mostani 140 EUR vegaru grafikus kartyak meg megeszik az ilyen scene-t reggelire."
Nagyszerű, kár, hogy teljesen mű.
"Talan azert mert azt a chip-et hasznalod argumentumkent? Lasd: "A Larrabee-n kellene ezt megvalósítani az Intel szerint". Egy kis konzisztancia nem ertana az argumentumaidnal mert igy csak random szovegre valaszolgatok."
Az olvasásnál sem ártana a konzisztencia, ugyanis ez a kérdés az RSX-re vonatkozott. És hiába gyorsabb az a 3850, ha az élethűségtől kb. ugyanakkora távolságra van.
"Ha a szamolas a limitalo faktor a tobbi resz nem jaszik szerepet."
Arról van szó, hogy ha bejön egy ilyen számolnivaló a képernyőre, nem lesz előnyben a raszterezés. Ha közben nagy komplexitású a scene, akkor sem lesz, ha ez kimegy a képernyőről...
(#136): "Komolyan...ahelyett hogy ileyn hulyesegeket irkalnal inkabb vagy alugy ilyenkor, vagy eloszor nezd meg es olvass utana mirol szolt az a demo aztan meg annak minek kene a fust es a tuz renderelesehez raytracing."
Ha valamit nem értesz meg, az nem biztos, hogy hülyeség. Arról van szó, hogy az élethű füstnek nem csak a gomolygása számításigényes, hanem a megjelenítése is. Mivel hogy nem néhány poligon egy füst textúrával, undorító és illúzióromboló (még azt a kicsit is, ami volt) éles élekkel a metszéseknél, stb.
"Javaslom a par evvel ezelotti offline rendererek megoldasait nez eloszor. A regebbi Lightwave es Maya verziokat - az elsot a fist miatt a masikat a tuz miatt."
Nem láttam még ilyenekben élethű füstöt - nem a gomolygást illetően, bár az is megér egy misét: ha egyszer textúráról van szó, az nem térbeli, így élethű térbeli gomolygást sem igazán lehet vele összehozni.
"G80? A 7800GT OC-n teszteltek. A masodik linkedben van benne. Azt kerdezted hogy menne ez most egy GPU-t rasztarizalassal. Arra irtam hogy meg a raytrace verzio is menne ugyanugy mint a CELL-en. Egy shader-es megoldas pedgi sokkal gyorsabb lenne."
Azt nem tesztelték semmi máson, mert az eredeti 7800-as változat továbbfejlesztése/módosítása, csak Cellre. A nyuszisnál viszont G80-nal hasonlítanak, és továbbra is 4-es a szorzó...
(#137): "A Pixar oldalarol a Cars-os dolgot direkt nem raktam be neked tegnap mert sokkolo hatasu lenne de egye fene, itt van: [link]"
Ha esetleg jobban megnézted volna, itt interactive preview-ről van szó. Biztos bolondgombát ettek, hogy a végső rendereléskor mégis a sokkal lassabb ray-tracinget használják.
"Egyebkent azt tudod hogy a Cars votl az elso filmjuk amiben raytracing-et hasznaltak? Addig elvoltak nelkule es par filmjuk megjelent"
Naná, hogy észrevettem, a Pixar filmek mindig is totálisan "plasztikusak" voltak a számomra.
"A Pohl fele munkarol mar volt szo sokszor es mondtuk hogy hanyat. Mert az is. Istenem hogy nez mar ki. Nezz meg egy DX10 alatt futo Bioshock-ot mondjuk (ha mar a sotet environment-nel tartunk..."
Bizonyos szempontból kezdetlegesebb, más szempontból meg életszerűbb. A Bioshock és társai 2mp-nél tovább nem tudnak lekötni.
"Egy 5900Ultra-n alapulo grafikon? Really? 2008-ban a G92 es az R670 idejeben? Ezt nem gondolod komolyan. Raadasul az Intel-tol?"
Nézd már meg, mennyit számít a két kártya közötti kb. 2x-es különbség egy idő után! Semmit, együtt konvergálnak a nullához. Egy 5x gyorsabb kártyának is ez a sorsa.
"Most komolyan, mi nez ki jol azokon a screenshotokon? Barmi ami ma vagy tavaly a piacon volt jobban nez ki."
Melyikeken? A cikkben? Ha már screenshotok, inkább ezeket. De inkább ne csak screenshotokat, hanem a videókat. Mozgásban kicsit más. Lehet, hogy nem szuperrealisztikus, meg nem olyan alaposan kimunkált, mint az újabb raszterezős enginek és játékok, de az életszerűbb árnyékok, vetített textúrák, nem-statikus, (ön-)tükröződések, nem metsző füst és tűz, stb. nekem bejönnek.
"Olyan egy hetig amikor elkezdesz egy 3D modellezo programot hasznalni. Aztan attersz normalis dolgokra."
Jaj, hagyjuk már szegény golyókat, nem csak azokról van szó.
"Vagy peldaul ez a kep: [link] Ehez abszolute felesleges a raytracing. Cube es Env mapping-al megcsinalod ugyanilyenre."
Kár, hogy ez csak egy csalás, ami csak így első ránézésre életszerű (vagy még így sem).
"Nem tudnad megmondani hogy raytrace-e vagy nem."
Legfeljebb amíg meg nem mozdul... Statikus fake az egész, öntükröződés sincs. Az árnyék meg már most sem stimmel, vagy talán lebeg az út felett?
"A regi sok eves 3D Studio (meg a max elotti) kepek jutnak rola az eszembe."
Én inkább az Amigás ray-tracerekre emlékszem szívesen.
"Ennyire azert nem kene. A csillogo gombokbol regen kinottek az emberek. Legalabbis remeltem."
Én meg azt remélem, hogy az életszerűség igényéből nem nőttek még ki.
-
#06658560
törölt tag
válasz
#06658560
#138
üzenetére
kozben modositom, atgondoltam, az objektivnek a beeso feny odlali feluletenek midnen pontjat kell vizsgalni, ertelemszeruen nem lehet a fokuszpontokat kihagyni.
ellenben ha nem objektiven belulre, hanem mondjuk mint 3D latvany akarjuk megjelenitani a dolgot, akkor kenytelenek vagyunk a ter midnen pontja felol odamerni. Reshatas, racshatas, stb...
-
#06658560
törölt tag
Epp ezt akarnank megmagyarazni Dezznek, hogy emiatt nem szabad meg otthoni felhasznalasra erotletni a RT-t.
A RT-t sehol nem szoltam le, csak amikor jonnek itt a milyen lethu videok, akkor modnom, hogy koze nincs a valosaghoz, aki latott mar jarmuvet az tudja.
Az altalam emlitett nyeregnel a problemat a korrekt fuggvenymeghatarozas jelenti, mert egy min ketvaltozos fv-re raultetnek masik kettot, vagy esetleg valami komplett fuggvenysot. Eleggel belehalhat egy szamolo, mire kiszamolja hol van, mikozben a fuggvenysorbol adodoan periodikus lesz, azaz siman lehet ugy felpiteni, hogy egy kis rweszletet ismetelgetem, ami kisse gyorsabbra veszi a format. Es nem roszabbra... A tulzott fuggvenyben gondolkodas eroltetese sok esetben visszaut.
-
#06658560
törölt tag
dezz:
Lencsehatas mond valamit? Fentores, tukrozodes (8-as optika) Azaz nem csak a monitorra merolegesen kell kiinditani egy keppontbol a fenyt, mert a valosagban sem csak egy pontbol fog oda beesni, hanem sok iranybol. Akkor mirol beszelsz most?
A valosagban ha neked van egy x*y meretu erzekelod, akkor annak minden pontjaba a kornyezo ter minden pontjabol szamolnod kell a beeso fenyt, ha az ott megjeleno kepet kell merned. Ertelemszeru szukitesekkel: objektiv lencseje, stb. De ez akkor is minden egyes kepponthoz az objektiv teljes feluletebol kell, hogy kiinduljon, nem csak egy meghadott iranyban, kulonben nicns ertelme az egesznek. Gondold csak vegig.Boeing. Ahol a kep volt, en megtalatam a cikket is.
A logos kepet koszonom, bar becsapos: ha a szamitasi teljesitmenyt nezzuk, akkor az nem logaritmikus, sot, nagyon nem, mivel ez itt log skala, es a megjelenitett kepeket mutatja idoegyseg alatt. Ez min loglog fuggveny. Nem sima log.
A tobbi uj lkinket nem tudtam megnezni, munkahelyen azert iyleneket nem illik (
de este megteszem.Azt azonban meg midnig nem tudtad bebizonyitani, hogy ez lesz a kozeljovo otthoni felhasznalasnal. amig olyanokkal jossz, hogy betesznek meg egy bladet, addig nem lehet ezt otthoni felhasznalasnak tekinteni. Erre valamiert folyamatosan nem reflektalsz.
-
Raymond
titán
#127:
Orulok hogy lassan fedezgeted fel azokat a dolgokat amiken mar akkor vegigmentem amikor kijotted. Par aprosag:Az a gyuruk ura kep minden csak nem raytracing
A Pixar oldalarol a Cars-os dolgot direkt nem raktam be neked tegnap mert sokkolo hatasu lenne de egye fene, itt van:
[link] Egyebkent azt tudod hogy a Cars votl az elso filmjuk amiben raytracing-et hasznaltak? Addig elvoltak nelkule es par filmjuk megjelentA Pohl fele munkarol mar volt szo sokszor es mondtuk hogy hanyat. Mert az is. Istenem hogy nez mar ki. Nezz meg egy DX10 alatt futo Bioshock-ot mondjuk (ha mar a sotet environment-nel tartunk...
#128:
Egy 5900Ultra-n alapulo grafikon? Really? 2008-ban a G92 es az R670 idejeben? Ezt nem gondolod komolyan. Raadasul az Intel-tol?#131:
Most komolyan, mi nez ki jol azokon a screenshotokon? Barmi ami ma vagy tavaly a piacon volt jobban nez ki. "(A sokszorosan tükröződő golyók is jópofák, de szerintem nem csak az néz ki jól.)" - ja, jopofak. Olyan egy hetig amikor elkezdesz egy 3D modellezo programot hasznalni. Aztan attersz normalis dolgokra. Vagy peldaul ez a kep: [link] Ehez abszolute felesleges a raytracing. Cube es Env mapping-al megcsinalod ugyanilyenre. Nem tudnad megmondani hogy raytrace-e vagy nem. A regi sok eves 3D Studio (meg a max elotti) kepek jutnak rola az eszembe.#132 es #133
Aha, csak a kinezeten meg mindig olyan amilyen. Hiaba a 90FPS (egy 8 magoson!)"Ja, tudom, ez nem 500 csillió poligon... De legalább kinéz valahogy."
Ennyire azert nem kene. A csillogo gombokbol regen kinottek az emberek. Legalabbis remeltem.
-
Raymond
titán
"Ha meg lehet állítani a füst mozgását, próbáld ki, felugrik-e az fps. Szerintem komolyabb, élethűbb füstnél, tűznél egyszerűbb és gyorsabb ray-traciggel csinálni. És nem a keretet, meg a padlót, hanem magát a föstöt, tüzet leképezni."
Komolyan...ahelyett hogy ileyn hulyesegeket irkalnal inkabb vagy alugy ilyenkor, vagy eloszor nezd meg es olvass utana mirol szolt az a demo aztan meg annak minek kene a fust es a tuz renderelesehez raytracing. Javaslom a par evvel ezelotti offline rendererek megoldasait nez eloszor. A regebbi Lightwave es Maya verziokat - az elsot a fist miatt a masikat a tuz miatt.
"Kötve hiszem, hogy a dynamic branching miatt lett volna olyan lassú G80-on, "
G80? A 7800GT OC-n teszteltek. A masodik linkedben van benne. Azt kerdezted hogy menne ez most egy GPU-t rasztarizalassal. Arra irtam hogy meg a raytrace verzio is menne ugyanugy mint a CELL-en. Egy shader-es megoldas pedgi sokkal gyorsabb lenne.
"Azért 1.6m poligon már nem olyan kevés, tekintve a korábban említett számokat..."
Pedig keves. Nezd meg minket nyomnak a mostani jatekok. PC-re vagy PS3-ra teljesen mindegy. Es normalis FPS mellett.
-
Raymond
titán
"Annyi értelme van, hogy előbb-utóbb elérünk arra a pontra, amikor már a ray-tracing a hatékonyabb."
"A shaderek igen, de ugyebár a raszteres grafika nem csak abból áll."
Csak hol van az a pont ez a lenyeg mar egy ideje. Mert egyik fel fejlodese sem all meg es egyelore a raytracing ugy le van maradva hogy egy F15 vs. csaladi auto sebesseg felzarkozassal sem tudod megmondani mikor lesz elerheto otthoni koulmenyek kozott. Ja, es a raytracing is nem csak a sugarkovetesbol all. Ezt valahogy elfelejted mar tegnap ota minimum
Az nyirja ki a raytrace enginedet hogy egy jatek scene nem statikus. Es akkor a frame setupnal meghalsz. Mondtam ha nem igy van, bizonyits be egy mukodo demoval. Sok sikert.Az R300 demonal nem tudom melyik masik hasonlorol beszelsz. Azok alapjan amit leirtal az volt amit irtam. A scene komplexitasrol meg annyit hogy annak a demonak pont az volt a lenyege - az a hatterkep volt a IBL forrasa. Egyebkent a Lambo- raytrace demoban sem latom hogy tomve lenne a hatter barmivel is
"Ray-tracingnél egyszerűen csak megy tovább a sugár(vissza)követés a kilépő ponton, raszterezésnél hogyan tovább?"
Nezd meg az a sok belinkelt GT5P videot es kepet - hat ugy
Egesz jol megy nekik szeritem.A GI-t nem valtod ki Ambient Occlusion-nal mert mindketto masrol szol. Kicsit olvass utana. Az arnyekok megoldasa meg milyen erv mar? Ha mas megoldast hasznalsz akkor hogy tamasztja ala a raytracing-es ervedet? A mas algoritmust hasznalhatod es hasznaljak most is. A soklampas metodus nem a soft shadows miatt van hasznalva hanem a GI es ILB szimulalasara.
"Max. beraknak még pár Cell blade-et..."
Kismilliomodszorra leirva - mi koze van ennek az otthoni megoldasokhoz hogy a jatekok raytracing enginet hasznalhassanak? Semmi."Láttam már sokkal szebb ray-tracelt animot - jópár évvel ezelőtt, PC-n számoltatva. Persze az nem real-time volt, csakhogy sokkal lassabb gép is volt egy ilyen Cell alapú clusternél, szal talán az is real-time mehetne ma egy ilyenen"
Wow - offline render? Es akkor mi van? Semmi koze ahoz amirol most beszelunk. Mehet vagy nem az egy dolog a masik meg hogy nem latni sehol hogy menne. A realtime raytrace demok meg ugy neznek ki ahogy.
Az hogy mi megy a szinfalak mogott milyen erv mar megint? Honnan tudod a tobbi megoldasnal mik mennek a szinfalak mogott? Ja ugy hogy par honapjara ra kijon valami es lathatod a sajat szemeddel egy jatek formajaban?
"Akkor is mű az egész... Hol vannak a nagyszerű, és szupergyors raszterezős megoldások, amik ezen segítenek?"
Na ne rohogtess mar. A belinkelt GT5P autovalsztas jobban nez ki mint a Ferraris demo es minimum egy szinten van a Lambo-val. Es 60FPS-el megy egy PS3-on raytracing nelkul.
"Miért egy ilyen konfigon? A Larrabee-n kellene ezt megvalósítani az Intel szerint"
Azert mert a Larrabee nincs itt es nem is lesz meg 2 evig. A mostani 140 EUR vegaru grafikus kartyak meg megeszik az ilyen scene-t reggelire.
"Ez most nekünk miért is fontos?"
Talan azert mert azt a chip-et hasznalod argumentumkent? Lasd: "A Larrabee-n kellene ezt megvalósítani az Intel szerint". Egy kis konzisztancia nem ertana az argumentumaidnal mert igy csak random szovegre valaszolgatok.
"Hát egy teljes scene kirajzolása, összességében."
Megint az a franya konzisztencia....Ha a szamolas a limitalo faktor a tobbi resz nem jaszik szerepet. Gondolkozz el ezen legyszi mielott valaszolsz.
-
dezz
nagyúr
Ide teszem a videokat, hátha lusta valaki klikkelgetni.
Q3RT - Video 1
Q3RT - Video 2 (azért poén az a rengeteg tükörgömb )
Q4RT - Video (szerintem nem néz ki rosszul..)
Mindezt többtíz fps-sel... 8 magon. És akkor még hol van a Larrabee, a többtíz magjával.. Ja, tudom, ez nem 500 csillió poligon... De legalább kinéz valahogy. -
dezz
nagyúr
Izé, azért még álljon itt ez is: Ray Tracing and Gaming - One Year Later (Pohl) - ez jóval alaposabb. (Kár, hogy következetesen kötőjel nélkül írja a ray-tracinget.
)
"At HD resolution we were able to achieve a frame rate of about 90 frames per second on a Dual-X5365 machine, utilizing all 8 cores of that system for rendering."
(
) -
dezz
nagyúr
Na, mára az uccsó.
Eddig csak "Pohl ray-tracelt Quake 3-a" lett itt emlegetve, ha jól vettem észre, de van neki ray-tracelt Quake 4-es is, az kicsit érdekesebb: [link] (A sokszorosan tükröződő golyók is jópofák, de szerintem nem csak az néz ki jól.)Meg van itt egy ilyen: SaarCOR - A Hardware Architecture for Real Time Ray Tracing (RPU
) -
ddekany
veterán
Na, ne fan-oskodjál, mert.
De ha már felhoztad, azt is érdekes lenne tudni, hogy hány film használ raszteres elvű megjelenítést, és vajon milyen minőségi és sebesség vonatkozásai voltak ennek -- ezek igazán összetett modellek. Ami Daniel Pohl-t illeti, hát... nem mintha ez ítéletet mondana a raytrace jövője felett, de nekem elég PR szagúnak tűnik amiket irkál. Utálom pl. az olyan grafikonokat, amelyikeknek egyit tengelyén sincs semmi. Tudom, csak a jelleget mutatja a "butáknak", na de akkor is, miért nem áll elő néhány konkrét kísérlettel? Itt van ez a scene, adott CPU-val lerendelereltem kb hasonló kinézetűre raytrace-al és a raszerrel, és hupsz, 200M háromszögnél már kevesebb szívás volt a CPU-nak, hát még a busznak. Vagy valami ilyesmi. Tudom hogy ilyenben nehéz mérvadó kísérletet csinálni, de ez most így olyan, mintha csak hülyítene mindenit, aztán közbe tudja, hogy ebből bizony nem lesz semmi még 50 évig, vagy hogy soha, de hát tök jó fizetést kap, még hülyíti a fejeseket amíg lehet... Áh, gyanús. -
dezz
nagyúr
Na, találtam egy ilyen grafikont (nem az, amit kerestem - ott újabb kártyákkal hasonlítottak, bár az látszik, hogy felfelé haladva nagyságrendben már nem számít):
(nagyban)
Innen: Compute-Intensive, Highly Parallel Applications and Uses (Intel) -
dezz
nagyúr
Náhány példa a "haszontalan" ray-tracing felhasználására...
Ray tracing for the movie ‘Cars’
Per Christensen - Pixar Animation StudiosInteractive Isosurface Ray Tracing of Large Octree Volumes
Stackless KD-Tree Traversal for High Performance GPU Ray Tracing (ezek is minek szórakoznak ilyen hülyeséggel, amikor a GPU-kat sokkal okosabban is lehet használni...)
A Gyűrűk uránál is mi a fenének szórakoztak ray-tracinggel...?Na, akkor már a cikket is beteszem:
Ray Tracing and Gaming - Quake 4: Ray Traced Project (Daniel Pohl)ddekany: Nem baj az...
Egy színkiolvasás, és egy távolságmeghatározás (igaz, az pontosan számolva igényel egy gyökvonást, de azt talán meg lehet spórolni) - ez már csak egy ráadás. -
ddekany
veterán
Na ja, csak akkor már mindjárt GI lesz belőle... Amúgy nem hiszem hogy a mostani realtime OA úgy működne mint amit te beidéztél. Valószínűbb, hogy csak kinövesztenek néhány rövid tüskét, és ha eltalál valamit, akkor azért fényerő levonás jár, ha nem, akkor megúszta és kész.
-
dezz
nagyúr
A linken ezt írják:
"Ambient occlusion is most often calculated by casting rays in every direction from the surface. Rays which reach the background or “sky” increase the brightness of the surface, whereas a ray which hits any other object contributes no illumination."Nos, ha ezt kicsit továbbvisszük, és megnézzük a elért objekt színét és távolságát is, és az elsőt a második mértékében hozzáátlagoljuk az adott pont színéhez, máris jobb a helyzet...
-
dezz
nagyúr
Ha meg lehet állítani a füst mozgását, próbáld ki, felugrik-e az fps. Szerintem komolyabb, élethűbb füstnél, tűznél egyszerűbb és gyorsabb ray-traciggel csinálni. És nem a keretet, meg a padlót, hanem magát a föstöt, tüzet leképezni.
(#110): Nem tudom, nálam 6600-ason megy.
Kötve hiszem, hogy a dynamic branching miatt lett volna olyan lassú G80-on, mert akkor a szerző nem mondta volna azt, hogy "This kind of algorithm is pretty much ideal for the GPU"... Miközben G80 Dynamic Branching 20x slower than X1950XTX... A G92-n mitől is lenne hirtelen 5x gyorsabb, amikor az alig más, mint egy G80, kisebb csíkszélen? Mellesleg az SPE-k sem szeretik a túl sok ugribugrit.
"Az 1.6M poligonos auto modell raytracing-el 10 FPS-t produkal 2 CELL-en (16 SPE). A normalisabb minosegu pedig csak (majdnem) 4-et."
Azért 1.6m poligon már nem olyan kevés, tekintve a korábban említett számokat...
(#111) Kopi31415: Külön Boeinges link még nem volt, csak kép, és ott a Roadrunnert nem említettem. Mint már írtam, nem így tervezték. De korábban nem nagyon jelenítették meg egyben az egészet.
A fénytörést eléggé befolyásolja a sűrűség, azaz a fénytörési index. Attól függően eléggé eltérő lehet két anyag között.
"Egyébként meg: ha olyan jól skálázódik a raytracing egy bizonyos bonyolultság fölött, és jobban megéri függvényként számolni vele, akkor vajh miért diszkretizálnak midnen modellt végeselemhez, ha meg akarnak kapni valamit, akár áramlást, akár rezgést, akár bármit, CFD, FEA területen?"
A jobb (majdnem tökéletes) skálázódást és a függvényes tárgyleírást ne egyszerre tárgyaljuk. Az egyik egy általános tény ray-tracingre vonatkozólag, a másik természetesen csak bizonyos esetekben igaz.
"Te tényleg azt akarod bemesélni, hogy egy felületi mikro és makroegyenetlenséggel megáldott nyeregfelület fényvisszaverési viselkedését gyorsabb, könyebb lemodellezni egy pontos függvénnyel, mint közelíteni egy síklapokból áló elemmel?"
Ezt így nem mondtam. Bizonyos esetekben gyorsabb lehet, más esetekben nem. Ha pl. folyamatosan változik egy komplex függvénnyel leírható felület, vagy test, akkor gyorsabb lehet kihagyni a poligonokat. Lásd pl. azt a "deformálódó gömbös izé"-t, ami egy térbeli Julia...
"A folytonos függvényre minden pontban ki akarod számolni az értékeket?"
Ezt hogy kell érteni?
"Vagy valahol diszkretizálsz? Ha utóbbi, akkor mégis mi az a nagy jobb skálázódás?"
Ha már ott vannak a poligonok, nem mindegy, hogy honnan származnak? Nem attól skálázódik jobban a ray-tracing a szálak számával, hogy honnan származnak.
"Az a bizonyos logaritmikus teljesítmény: kéne valami link róla, vagy bármi. Így eléggé messziről jött ember jellege van."
Szerintem ezt itt nem vitatja senki rajtad kívül. Kénytelen leszel rákeresni.
(#119): "Ez szép és jó, de egy pixelbe mennyi irányból eshet be a fény? Innentől akkor hol lesz valósághű? Köszönöm, ez nem lesz az."
Ajjaj. A "rossz" irányból jövő (és nem beeső) rossz irányban is folytatja az útját, azaz nem a szemünk adott pixelt leképző pontjára érne, így kit érdekel, honnan jött, és hová ment...
Vagy te már rögtön hologramot akarsz renderelni? (Egyébként 8.-os optika.) -
ddekany
veterán
"A Global Illumination többé-kevésbé kiváltható az Ambient_occlusion-nal, amit használ is."
Inkább kevésbé, vagy méginkább nem, tudtommal. A GI-nél egymásra "tükrözik" a tárgyak a fényt (már megszórva, tehát pl. ha egy piros fal mellet áll egy ember, akkor a fal felöli fele kicsit pirosabbnak látszik), AO-nál meg csak a szórtfény csökkenését utánozzák, mikor két tárgy közel kerül egymáshoz. Szóval ha elterjed is a távoljövőben a realtime raytrace, akkor bizonyosan az sokáig még csak AO-s lesz, ami azért nagy szottyadás egy offline renderhez képest. Persze még GI nélkül is jobban néz ki mint a raszter.
-
ddekany
veterán
válasz
#06658560
#119
üzenetére
"Ez szép és jó, de egy pixelbe mennyi irányból eshet be a fény? Innentől akkor hol lesz valósághű? Köszönöm, ez nem lesz az."
???
Basszus ez van, nincs jobb. Ha fotont követnénkek becsületesen, lebomlana a számítógép mire kész lesz a frame. És persze amit mondtam az az alap, ezt még megspékelik minden csellel, de mivel jobbára azok is csak sugarakat lövöldöznek (tehát pl GI számításoknál, legalábbis bizonyos megvalósításokban, AO-nál meg megint csak), kétlem hogy azokat alapelvükből következően zavarná az általad említett face-etlen nyereg. Az ilyesmi a raszteres megközelítéssel nem illik csak össze (alapelvét tekintve). A másik meg, hogy a raszteres grafikánál, ha annak is csak az alapjait vesszük, még ez is élethűbb. Szóval ilyen téren szerintem nem lehet panasz a raytracing alapú megoldásokra, mert legalábbis rosszabbul nem néznek ki, "csak" a sebességgel vannak még gondok, aztán meglátjuk hogy a virtuális világok bonyolódásával lelőzi-e sebességben a rasztert. (Igazából szerintem már akkor is elkezdené megérni, ha csak fele olyan gyors... na de ez már mindegy.) -
dezz
nagyúr
"Megint semmi konkret adat nincs. Majd ha megtalalod a grafikont visszaterhetunk ra. Addig semmi ertelme es addig itt a valosag amit lathatsz az altalad linkelt demok es a mar ma jatszhato jatekok kozt."
Annyi értelme van, hogy előbb-utóbb elérünk arra a pontra, amikor már a ray-tracing a hatékonyabb.
"Mert a mostani shader alapu grafika nem parhuzamosithato? Mert egyelore ugy nez ki hogy igen ezert olyanok a GPU amilyenek."
A shaderek igen, de ugyebár a raszteres grafika nem csak abból áll.
"A raytracing minden eleme ennyire jol parhuzamosithato? Nincs semmi ami visszafogna?"
Úgy tűnik. [link] (ezt már magad is linkelted), [link] (MS-os anyag ), stb."Az R300 demo a "HDR demo volt". Meg ma is jol nez ki. Es az igazan jo minseg shader alapu refractionnal ugyanugy realtime mint a tobbi. Itt nincs ertelme olyan algoritmusnak ami nem megy interaktiv framerate-en."
Volt egy másik hasonló is. Hát eléggé belassult fénytörésnél, pedig csak egy object volt. Azt se felejtsd el, hogy nem mindegy, hogy csak egy kép van mögötte, vagy egy egész scene. Ray-tracingnél egyszerűen csak megy tovább a sugár(vissza)követés a kilépő ponton, raszterezésnél hogyan tovább?"Az hogy a Ferrari demo ugy nez ki ahogy nem csak annak koszonheto hogy amator munka. Itt megint elojon az amirol vagy elfeledkezel, vagy nem tudod vagy elhallgatod mert nem illik a mantradba. Az hogy a jobb megvilagitashoz nem lenne eleg az amit csinalnak mert a raytracing nem a szent gral. Es ehez nincs mit hozzafuzni. Annyit csinalhattak volna meg hogy (eleg komolyan) megnovelik a fenyforrasok szamat (GI szimulacio) es javitanak az algoritmuson"
A Global Illumination többé-kevésbé kiváltható az Ambient_occlusion-nal, amit használ is. És vannak más, nem olyan lassú megoldások is a megvilágítás élethűségének növelésére, vagy pl. a soft shadows-ra (és nem a sok lámpa - lásd pl. MS-os paper), stb.
"de akkor mar hoppa - oda a realtime tenyezo."
Max. beraknak még pár Cell blade-et...
"Egyebkent meg nem nez ki jol. Ahogy mar irtam meg a realtime jatekok vilagaban is messze afolott a minoseg folott jarunk mint ami ott volt. Az egyetlen amit fel lehet hozni az a tukrozodesek minosege (micsida meglepetes). Semmi mas. Meg a kocsi lakkozasanak megoldasa is elmarad egy normalis szinvonaltol."
Láttam már sokkal szebb ray-tracelt animot - jópár évvel ezelőtt, PC-n számoltatva. Persze az nem real-time volt, csakhogy sokkal lassabb gép is volt egy ilyen Cell alapú clusternél, szal talán az is real-time mehetne ma egy ilyenen.
"Az hogy ez nem egy jatek engine nem jelent semmit. Mert jatekok reszerol meg itt sem tartanak. Lattad mi letezik - a Pohl Quake3 cucca ami olyan poligonszamokkal dolgozik az egesz levelre amilyenek az ujabb jatekoknal 1 (egy) karakter tartalmaz."
Honnan tudod, milyen fejlesztések mennek még színfalak mögött? Meg aztán megnézhetnél pár PC-s ray-tracing demót... Azokat átvíve Cellre szerintem kicsit gyorsabb lenne, mint ez az IBM-féle iRT (amiben pl. követelmény volt, hogy automatikusan szétossza magát x Cellre, a memória-kezelésben is van automatizmus, stb.).
"Ha ezt megnoveled a tizszeresere akkor sem ersz el semmit. Egy normalis jatek manapsag tobb millio poligont nyomat framekent komolyabb minosegben es nagyobb FPS melett."
Akkor is mű az egész... Hol vannak a nagyszerű, és szupergyors raszterezős megoldások, amik ezen segítenek?
"De mondom, ha tudsz olyan megoldasrol amivel beolvasol egy (ne legyunk telhetetlenek) 1 millio poligon/frame scene-t es megjeleniti legalabb mondjuk 25FPS-el 720p-ben mondjuk ket darab 3Ghz 4magos C2 procin akkor azt megnezem. Meg komolyabb minoseg sem kell, eleg az ami a Ferraris demo vegen volt. Meg AA sem kell."
Miért egy ilyen konfigon? A Larrabee-n kellene ezt megvalósítani az Intel szerint.
("NV45=G70/71 derivát.")
"Legyen G71-es hogy komolyabb szamokkal dolgozhass (pedig nem az)."Pedig az.
"Meg igy sem valtoztat a lenyegen hogy sehol nincs az a chip a main low-mainstream kartyakhoz kepest teljesitmenyben."
Ez most nekünk miért is fontos?
"Varj csak...valtik azt allitottad a fust es voxel peldakkal hogy azert kapcsolodnak a temahoz mertt ott is szamolasrol van szo. Akkor a 4x shader teljesitmenyen kivul meg lenne meg fontos?"
Hát egy teljes scene kirajzolása, összességében.
"Aztan ott van meg a FlexIO-n keresztuli 20 ha jol emlekszem csak az nem mindenre hasznalhato"
Hozzáférhet az XDRAM-hoz, szóval legalábbis textúrát olvashat onnan, de egyébként írni is tud oda is (ezt 15 GB/s-sel).
"A Larrabee arat te jelentetted ki olyan magabiztosan hogy alacsony lesz. En csak mondom hogy minden eddigi sokeves tortenelembol itelve nem lesz alacsony aszerint amit a chiprol tudni lehet. A 32nm technologiat is mar figyelembe veve."
Én nem mondtam árat, csak piaci szempontokról beszéltem.
"Megint vissza oda amirol mar szo volt. Hogyan csinalsz meg egy levelt nem sik feluletekbol?"
Ha körülnézel magad körül, van bővel nem-sík felület... De persze nem tiltott a sík felület használata sem.
"Hiaba gyors ott a raytracing ha nem tudod felhasznalni semmire. Vagy ha felhasznalod, ok, de hany szazalekat fogja egy scene-bol kitenni? Es mit csinalsz a tobbi resszel amit poligonbol kell megcsinalnod. Reszletesen, texturazva, animalva stb? Ha szarra losz egy szobat vagy a kornyezetet ugy altalaban (inkabb ez ma a norma mint kivetel) akkor sem kell uj setup az egesz scenere ha raytracinget hasznalsz? Mert szerintem kell. Es akkor lehalt az FPS-ed is es a teoriad is a raytracing tutisagarol. De meggyozhetsz az ellenkezojerol."
Majd máskor.
-
ddekany
veterán
válasz
#06658560
#117
üzenetére
A szokványos raytracingnál az alapcsel az, hogy nem a fényforrásból kiinduló fotonok útját nézed, hanem mintegy visszafelé haladva az időben, a szemtől indulsz ki, méghozzá csak annyi sugarat indítasz a szemből (ha nincs antialiasing), ahány pixeled a képernyőn van. Mintha előtted lenne egy négyzethálós lap, ahol minden négyzet egy pixel a képernyőn, és a szemedből minden négyzet közepén átlőnél egyetlen lézersugarat, ami letapogtja amit eltalál a papír mögött, meg amire onnan továbbpattan, stb. Persze lesz még több sugár árnyékok miatt, ja meg egyéb tápolások miatt, de a lényeg talán már ennyiből is érződik: a sugarak száma és a geometria komplexitása (viszonylag) függetlenek egymástól. (OK, ha percízek akarunk lenni, akkor nem, mert nem mindegy mennyi a verődés, stb, stb, de a lényeget akartam érthetően mondani).
-
#06658560
törölt tag
ott egy példám: nyeregfelület, felületi mikro és makroérdeséggel. Folytonos legyen. Erre minden pontban számolsz? Mert ha végiggondolod végtelen sok pontban fogja eltalálni egy fényforrásból érkező sugár. Vagy ha a szem megfelelő területét nézzük akkor végtelen sok olyan sugár van, ami az adott teljes felüeltről visszaverődve eljut a szemig, azaz kénytelen lennél végtelen sok pontban kiszámolni...
-
ddekany
veterán
válasz
#06658560
#111
üzenetére
"A folytonos függvényre minden pontban ki akarod számolni az értékeket? Vagy valahol diszkretizálsz?"
Nyilván csak ott számolod ki a függvény értékét, ahol eltalálja a felületet egy sugár... Így kevesebb elemből állhat össze egy scene, mert mondjuk 200 háromszög helyett beteszel egy gömböt, ami ráadásul a sziluettje sem olyan mint amit baltával faragtak. Na most azt nem állítom, hogy ez megéri, mert egyrészt lehet hogy nehéz valós modellekben ilyen felületeket találni, másrészt lehet hogy jó számítás igényes kiszámolni velük a metszést, de ez az alapötlet.
-
#06658560
törölt tag
Azért a modell marha messze van a teljeshez, ha megnézed. Egy komplett repülőgépmodell kicsit több alkatrészt tartalmaz, mint amit ott látsz. És spec ilyen termékeknél az igazi parasztvakítás a midnenféle fotorealisztikus és egyéb megjelenítés ér rendering. Egy mérnök nagy ívben xarik rá hogy néz ki, hogy jelenítik meg, milyen élethű a színe, a funkciót, formát minél pontosabban jelenítse meg a rendszer, más nem fontos.
-
ddekany
veterán
válasz
#06658560
#99
üzenetére
"Ahhoz képest semmi újat nem látok ebben a cucban, max a méretet, hogy több alkatrészt kellett bepakolni."
De hát pontosan arról szólt az egész, hogy mekkora hatalmas modell, és mégis valós időben mászkálnak benne.
"Egyébként remélem nem hiszed el, hogy raytrace módon modellezték le az alkatrészeket. Max a végén, a megjelenítésnél."
A raytrace az a megjelenítéshez van, úgyhogy persze hogy a végén és megjelenítésnél... mikor máskor kéne még? Aztán hogy fake-e, pontosabban hogy mit felejtettek el megemlíteni, azt persze én sem tudom...
-
Raymond
titán
Az autos videokhoz meg ennyit: [link]
Ket problema van a videoval. Az egyik a tomorites, dehat ez van ezt kell szeretni. A masik az AA hianya, az viszont a PS3/RSX gondja. Igaz a full jatek megjelenesig meg dolgozhatnak rajta kicsit. A GT4P es a vegso valtozat kozott is eleg nagy a kulonbseg.
-
#06658560
törölt tag
Noh, végignyálaztam ezt a halom linket. Spec a Boeinget nem értem miért tetted be ismét, egyszer is elolvastuk. És még mindig baromság amit azzal kapcsolatban hangsúlyoznak, hogy így tervezték.
Lambo movie: erre inkább nem mondok semmit élethűséggel kapcsolatosan Rengeteg sebből vérzik. és azt még nem is vettem hozzá, hogy csak a talapzat és a járműmodell renderelt, a környzet csak kép, nagyon gyenge minőségű. És megitn nem életszerű a végeredmény sok helyen, kicsit jobban kifejte gyakorlatilag az egész modellen.
Az a deformálódó gömbös izé. A gombbeli fénytörés nem fedi a valóságot- legalábbis ahhoz hasonlítva, amit láttam anno meteorológiai napsütéses órák méréséhez használt gömb fénytörését.
Egyébként meg: ha olyan jól skálázódik a raytracing egy bizonyos bonyolultság fölött, és jobban megéri függvényként számolni vele, akkor vajh miért diszkretizálnak midnen modellt végeselemhez, ha meg akarnak kapni valamit, akár áramlást, akár rezgést, akár bármit, CFD, FEA területen?
Te tényleg azt akarod bemesélni, hogy egy felületi mikro és makroegyenetlenséggel megáldott nyeregfelület fényvisszaverési viselkedését gyorsabb, könyebb lemodellezni egy pontos függvénnyel, mint közelíteni egy síklapokból áló elemmel? A folytonos függvényre minden pontban ki akarod számolni az értékeket? Vagy valahol diszkretizálsz? Ha utóbbi, akkor mégis mi az a nagy jobb skálázódás?
Az a bizonyos logaritmikus teljesítmény: kéne valami link róla, vagy bármi. Így eléggé messziről jött ember jellege van.
-
Raymond
titán
Mivel a 7800-al a dynamic branching fogta vissza igy a shader teljesitmeny novekedese es a dynamic branching javulasat figyelembe veve megkockaztatom hogy egy RV670 vagy egy G92-es beerne azt az emlitett CELL teljesitmenyt. Sacc, mert sajna az 1950XTX-emen nem indul el a Cg es a GLUT telepitese utan sem hogy legalabb azon megnezzem mit tud. Ha tudod hogy kell ezen elinditani akkor megoszthatnad hogy kiprobaljam. A 6800Go-m teljesitmenye nem erdekel kulonosbben
"the rendering time of traditional polygon rasterization techniques scales linearly with scene complexity, ray-tracing scales logarithmically."
Ezt nem vitatja senki, a problema az hogy nincs megadva milyen implementacio pontosan es milyen kornyezetben (scene komplexitas, interaktivitas stb.) a masik pedig hogy konkret szamokkal nem szolgaltal. Tehat az hogy linear vs. log nem jelent semmit, mert ahogy irva vala mar itt a topicban a raytrace most ott tart hogy nevetseges mennyisegu poligon 50-100e per frame (vagy per scene? nem si nztem az utolso Pohl adatoknak utana) nevetseges minosegben az otthoni megoldasonal a rasztarizacio meg ott hogy 2+ millio poligon per frame messze jobb minosegben.
Ez is nemegyszer el lett mar mondva hogy a Boeing demot felhozni felesleges. Semmi koze a lehetseges otthoni felhasznalashoz. 28 CELL szamolja azt a 350 millio poligonos modellt! Texturak nelkul csak alap szinekkel. Es nincs is az egesz modellen egyszerre dolgozva, tehat a 350 milliot nem hasznalhatod ervkent
A Lambo-s PDF-ben lathatod mennyire hasznalhatatlan meg most is: [link]
Az 1.6M poligonos auto modell raytracing-el 10 FPS-t produkal 2 CELL-en (16 SPE). A normalisabb minosegu pedig csak (majdnem) 4-et.
-
Raymond
titán
Azoknal ott nem a megjelenites szamolasa a nehez hanem a szimulacio szamolasa. Es ha ez a GPU shadereken tortenik akkor mar perszehogy nem mindegy a megjelenitest hogy oldod meg. Szegeny shader egysegek pusztulnak a szimulacio szamolgatasaval te meg meg radobnal par lapattal a dologra. Szerinted milyen gyorsan menne a fustos demoban a fluid szim ha a shaderek meg azzal is foglalkoznanak hogy a tartaly csilli villi keretet vagy a padlo tukrozodeset raytracinel szamolgassak a mostani megoldas helyett azert hogy a kepernyo nem egesz 5%-at (a keret es ez meg talan tulzas) fizikailag korrekt kep foglalja el amikor a kulobseget nem latja senki annyira jelentektelen a lefedes. Vagy hogy a sik padlon a tukrozodes raytracinges legyen ahol meg egyaltalan nem mondod meg hogy van csinalva ha nem tudod.
-
-
dezz
nagyúr
"Nem hulyeskedek de sokadszorra sem akarod felfogni. Az a demo nem a kepgeneralasrol szolt hanem arrol hogy a fluid szamolast el lehet vegezni a GPU-n. Semmi koze a raytracing alapu kepgenerelashoz. Remelem most mar eleg lesz."
TUDOM, BAZDMEG, TUDOM. HÁNYSZOR KELL MÉG LEÍRNI, HOGY NEM EZ A PÁRHUZAMVONÁS LÉNYEGE????
A többit mindjárt, de ez már nagyon felbaszta az agyamat.
-
dezz
nagyúr
Na, itt van nektek egy kis GPU-s ray-tracing: [link]
(Ugyanez Cellen 5-6x gyorsabb, mint egy 7800-ason (pedig az eredeti kóder szerint nagyon is passzolt a 7800-ashoz): [link])
Kicsit továbbfejlesztve: [link]
movie
Ezt így hány fps-sel tudná egy GPU, raszterezéssel? 7 SPE-vel (PS3, RSX nélkül) 1024x1024-ben 15 fps.Még 1-2 írás:
"Ray-tracing has always been the algorithm of choice for photorealistic rendering. Simple and mathematically elegant, ray-tracing has always generated lots of interest in the software community but its computationally intensive nature has limited its success in the interactive/real-time gaming world. However while the rendering time of traditional polygon rasterization techniques scales linearly with scene complexity, ray-tracing scales logarithmically. This is becoming increasing important as gamers demand larger more complex virtual worlds. Ray-tracing also scales very well on today’s multi-core “scale-out” processors like Cell. It falls into the category of “embarrassingly parallel” and therefore scales linearly with the number of compute elements. The graphics community has taken notice of these facts and is pulling together a conference to share ideas.The 2006 IEEE Symposium on Interactive Ray-tracing
We plan to participate as we feel this topic is very important to the future of gaming and graphics in general." [link]
Ja, a Boeinget egyelőre még csak megjelenítették demonstrációs célból, de az IBM új szuperszámítógépe, a Roadrunner is ilyen felépítésű lesz, csak több egységből (persze azt elsősorban nem ray-tracingre fogják használni, de a megjelenítés mehet így). [link], [link] (itt van egy másik autós anim is).
"IBM’s software ray-traced solution (iRT) has several key advantages:
1) Completely scalable renderer (Frame rate scales linearly with number of blades)
2) Much higher image quality using ambient occlusion
3) Ability to scale to very larger scenes while maintaining interactive frame rates
4) High compute density (no power hungry GPUs in the server racks)"
sargafolt) A ketto egymastol mert tavolsagat is ismered. A kostellaciobol ket dolgot tudsz valtoztani: a lencse formajat, es tavolsagat. Ezen felallasban egy adott lencsetavolsaghoz es lencseformahoz csak egy tartomany tartozik, amibol a kep eles lehet sajna. A tobbibol mar annyira meredek szogekben erkezik a feny, hogy ott torzul a toreskor az irany az elmelethez, vagyis nem eleg nagy a lencse. Vegtelen kiterjedesu lencsevel vegtelen messzesegig lehetne rendesen fokuszalni a kepet. De azzal meg kozelre nem lehetne semmit elerni. A melysegelesseg egyebkent szerintem kifejezetten hasznos a tavolsag felmeresehez pl.,valamint rengeteg folosleges- adott tevekenyseghez nem szukseges informacio kiszuresehez.
Gondolkodj mar el ezen meg azon hogy minket hordtal itt ossze-vissza. Odaig sulyedtel hogy azokra a Q4 kepekre es a Ferrari-s demora allitottad sokszor hogy neked inkabb az tetszik mint a mostani raszteres megoldasok mu vilaga mert hogy azok milyen realisan neznek ki.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Azonnali fotós kérdések órája
- LG LCD és LED TV-k
- Először égett le egy újságnál a GeForce RTX 5090
- Philips Hue – az okos lámpák királya
- Milyen légkondit a lakásba?
- Borotva, szakállnyíró, szakállvágó topic
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- ASUS notebook topic
- Elemlámpa, zseblámpa
- További aktív témák...
- Bomba ár! Dell Latitude 5410 - i7-10GEN I 16GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Garancia!
- HP 200W (19.5V 10.3A) kis kék, kerek, 4.5x3.0mm töltők + tápkábel, 928429-002
- Samsung Galaxy Tab S6 Lite / 4GB RAM 64GB / Független / 12 Hó Garancia
- Bomba ár! Dell Latitude E7250 - i5-5GEN I 8GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- BLUESUMMERS NVMe SSD adapter
Állásajánlatok
Cég: FOTC
Város: Budapest