@Gpety
Kedves Dandris,
Elolvastam, és számos probléma van a linken. Például egy GPU-val is lesznek ilyen eredmények. Ez abból következik, hogy az egyes framek számítása nem azonos ideig tart. Két GPU-val csak szinkronizáció kell, ezt leírtam, hogy évek óta létezik, és megfelelően működik. Volt CF rendszerem, láttam, hogy nincs gond. Gbors is leírta, hogy nem éérzett problémát CF esetén. A PH tesztekben is említettük volna ha gond lenne. De, ha nem értesz velünk egyet, akkor terjeszd tovább a rég kijavított micro stuttering urban legendjét. Engem nem zavar. Egyébként senki sem tagadja, hogy létezett. De azt világosan leírták, hogy az órajelek folyamatos, nem szinkronos változása okozta. Ilyenkor annyira elcsúszott a két frame, hogy akár 70-80 ms is volt közöttük, ami észrevehető volt. Azóta bőven jó tartományon belül mozognak az értékek, ahogy ezt Thrawn által linkelt tesztek is alátámasztják. Nincs ilyen magas eltérés. Persze a legenda tovább él.
Linkeld azt a játékot, ami olyan szintű tesszellációt használ, mint az Unigine Heaven benchmark. Látod, nem én döntöm el, hogy mi lesz, hanem a fejlesztők. Én csak annyit tehetek, hogy leírom a véleményem, és hozzá a fejlesztők véleményét. Előbbire: Szerintem a tesszelláció fontos, és innovatív. Hasonlóan gondolkodom, mint a geometry shader idején sok dologra jó, és használni kellene. A fejlesztők ezzel szemben nem igazán alkalmazzák. Egyrészt a tesszellált felület logikai szinten nem létezik, így okosan kell vele bánni, hogy ne legyen hatással a játékmenetre. Értsd tesszellálva falat marhára nem jó öltél felhúzni, mert jelenetszámítás szintjén simán átlősz rajta, hiszen a fal csak a frame számításnál jön létre. További probléma, hogy az ütközésdetektálás is csak az eredeti modellre vonatkozik, a tesszellált esetén érdekes eredmények születhetnek. Itt is figyelni kell, az előbb említett okból kifolyólag. Jelenleg ezért korlátozódik az egész rendszer a karakterekre, mert egyelőre sok a nyitott kérdés, amit még nem volt idő alaposan átrágni.
Ja a teljesítmény is probléma. Az a sok kicsi háromszög nemcsak a setupot, hanem a geometry shadertől kezdve, minden más logikai futószalagot terhel. Ez főleg nagyon fáj az árnyalás és a textúrázás folyamán. Ez annyit jelent, hogy a fejlesztők kitörölhetik a seggüket egy erős setup motorral, ha nincs elég kraft a GPU-ban a háromszögek feldolgozására. Egyelőre egyik GPU-ban sincs. Várhatóan még legalább egy generációig nem lesz, de ez annyira nem lényeg, mert még legalább egy generáció, amíg megtanulják használni a rendszert. Addig effektekre és karakterekre, jó lesz. Esetleg pár felület még mehet. Az AVP-ben nem okozott gondot, legalábbis nem tűnt fel.
Gondolom stratégiailag tudod, hogy miben különbözik az NV és az AMD fejlesztési elgondolása. A Fermi az NV tervezett csúcsmegoldása, míg az AMD-é a Hemlock. Az Unigine Heaven-ben is nehéz lesz a legerősebb Radeont befogni. Ebből nyilván látható, hogy a setup motor, harmad akkora textúrázó és számítókapacitás nélkül nem sokat ér. Nyilván a tranzisztorszám jól szemlélteti a dolgot, lehetett volna feleolyan erős setup motort csinálni, és jobban gyúrni a textúrázásra, vagy más helyen keresni egy kis plusz erőt, ami nem csak egy benchmark alatt jön ki. Itt hibázott anno az AMD az R600-nál. Olyan helyre fektetett elképesztő tranzisztormennyiséget, ami nem éreztette hatását. Akkor persze nem voltál ilyen lelkes a geometry shader kapcsán. A benchmark és tesztprogramokban be lett alázva minden NV-s megoldás. Volt valami érdemi hatása? A fejlesztők hozzányúltak olyan mértékben, hogy az káros legyen a GeForce-ra?
Ne essél ugyanabba a hibába, amibe én. Egy technika csak akkor ér valamit, ha kihasználják. Ettől lehet innovatívnak tekinteni az R600-at és a GF100-at, mert mindkét lapka olyat mutatott, amit eddig egyetlen elődje sem. Megmutatta az utat, hogy mi a jó egy új eljáráshoz. Lelkesedni is lehet a geometry shaderért és a tesszellátorért, de érdemes fél szemmel figyelni a fejlesztők véleményét ezekről, mert ez lesz a döntő, nem a lelkesedés.
Ha az NV-nek olyan erős a dev support-ja, miért rohant a fejlesztők többsége az AMD-hez a DX11 okán? Kicsit ellentmondásos. Arról is megfelejtkezünk, hogy az AMD eddig több DX11-es címet hozott, mint az NV. Kezd a buli kiegyenlítődni ... nem? Apropó hallottad, hogy az AMD a Modern Warfare 2 kapcsán csinált egy marketingszerződést. Mostantól lehet csomagolni a Radeonokhoz.
Pár dolgot megint elfelejtesz a trenzisztorszám kapcsán. Ugye, mint informálódtam az AMD egy 20 millió tranyós egységet használ, míg az NV összesítve 80 milliósat, ami ugye 16 egységre leosztva 5 millió/egység. Nyilván az egyes SM-eknek nem kell olyan erős rendszer, mint egy egész GPU-nak. Na most itt jön még a setup motor, ami az AMD-nél egy van. Ez egészíti ki a tesszellátort, egyébként ez elég sok tranyó. Az NV-nek ebből van 4 raszter motor, és 16 geometriai motor, ergó rengeteg egység sokkal többször van. Ez összességében sokkal több tranzisztor 100 milliós nagyságrendekkel. Ebbe is érdemes belegondolni. A setup szétlövése hatalmas ár a tranzisztormennyiségben. Nem véletlen csökkent a textúrázókapacitás. Nem volt több hely.
A 3Dmarkban mikor lett bealázva az NV. Kb. Soha. Nem is épült pipe GS-re a Vantage. Ahol megpusztult az NV az Emil Person GI demója. Szép volt, de mégsem játék.
Khm. Ez nem teljesen van így a fejlesztőknél. A STALKER-es srácok írták, hogy a Clear Sky-ban azért nem alkalmaztak GS-t, mert sok volt a GeForce felhasználó. Mindig a célközönség számít. Sok GeForce volt a piacon és nem lehetett őket kifektetni.
A tesszellátornál más a helyzet, mint a GS-nél. A GS-be a GeForce belehal, míg a tesszellálásba a Radeonok nem. Persze nem ez a fő probléma, hanem a keletkező háromszögek árnyalása és textúrázása. Odaállíthatsz pénzzel, de miért jó egy fejlesztőnek, ha olyan játékot gyárt, ami semmin sem fut max. grafikán. Még a Fermin sem. Mondtam, hogy a setup erőssége nem elég. Amit ott megnyer, azt elveszti a sok millió háromszög feldolgozásán.
Nem teheti meg az AMD. Nem szarhatnak rá arra a piacra, amiből meg akarnak a jövőben élni. Régebben az NV sosem akciózott ilyen erős lefizetésekkel, meg kizárásokkal, effektek úgymond megvásárlásával. A durvább akciók nemrég kezdődtek. egy éve kb. Tudják, hogy ez árt a PC-s játékiparnak. Most azért csinálják, mert látják, hogy itt nincs hosszútávú jövőjük, így nem baj ártalmas a piacra, amíg szükségük van rá, addig el lesznek adva a termékek. Azután meg marhára mindegy lesz, hogy mit hagynak ott az AMD-nek és az Intelnek.
Inkább azt mondtam, hogy a geometrikus transzformációkból nem lehet kihozni többet, mert a mikropoligon render az utolsó lépcső. A DX-ek fejlődnek tovább, mert kell egy API a gyártóknak. Meg is van az irányvonal a DirectCompute-on belül. Ez még nem olyan fejlett, mint mondjuk az OpenCL (a fejlettséget a benne rejlő lehetőségekre értem), de némi megkötéssel lehet egy szoftveres futószalagot írni benne. A kötött futószalag megmarad mindig, mert a szoftver renderingnek is meg van a hátránya. Nem mindegy, hogy minden architektúrához tervezel egy kódot, vagy használod a DX futószalagját, amihez tervezik az architektúrát. Előbbi esett mellett azért van Tim Sweeney, mert pontosan tudja, hogy mennyire költséges, és komoly meló, megírni egy szoftver rendert több különböző architektúrához pedig pláne szívás. Már most is elgondolkodtató, egy komplett motor licenszelésének lehetősége, mert anyagilag lehet, hogy többe van, mint egy saját fejlesztés, de az idő szempontjából összehasonlíthatatlan előny. Mivel a szoftver render több pénzt és időt igényel, gyakorlatilag borítékolható, hogy nem sok motor marad a piacon, és azt fogják vásárolgatni/licenszelni a kiadók.
Például Sweeney mellett van ellenvélemény is. Andrew Richards például továbbra is amellett áll ki, hogy a kötött futószalag jobb dolog, mert generációnként továbbfejleszthető és könnyebb vele bánni, gyakorlatilag minden szempontból. Nyilván a kipukkadt Larrabee-lufi eléggé komoly problémákat is felvet ezzel a szoftver renderrel kapcsolatban, mert az nyilvánvaló, hogy a HPC-piacon baromira felesleges számos olyan rész, ami egy GPU-nak kell, de ezek nélkül jelenleg nem GPU a GPU a PC tekintetében. A DX12 valószínűleg megoldja a DX11 tesszellálással kapcsolatos problémáit, mert van bőven ilyen. Persze ha ez meg lesz oldva, akkor ott lesz a millió dolláros kérdés: elértük, hogy a triangle kisebb, mint a pixel (mikropoligon rendering), innen hova tovább? A DX12-ben talán olyan szempontból is érdemes gondolkodni a problémán, hogy a DirectCompute képességeit kiterjesszük. Egyelőre a kötött futószalagon belül a pixel shaderhez van hozzárendelve a rendszer egyfajta kiegészítésként. Lehet használni még a renderelés előtt is, de logikailag csak az inputba lehet bekötni az eredményt. Talán érdemes lenne egy olyat megoldani, hogy a DirectCompute felületen végzett munka bárhova beköthető legyen, ez azt a szabadságot adná meg a fejlesztőknek, hogy igény esetén lecseréljék a futószalag egy részét. Persze lehet, hogy ebből csak a DX13-ban lesz valami.
A DX9 SM3.0 alatt bármit meg lehet oldani, ami ma a modern grafikához kell. Az egyetlen probléma a flexibilitás, és a szükséges teljesítmény. Ezt javítja a DX10 és a DX11, majd a DX...
Csak egy egyszerű példával élve ott az AMD-nek a HDAO algoritmusa. Ez letölthető a DX SDK-ban. Az a jó ebben az algoritmusban, hogy szépen skálázható, így nagyon jó összehasonlítást ad a DX verziókra. DX9-ben is lefut, csak borzalmasan lassú, mivel semmi olyan dolgot nem használhat, ami növelné a sebességet. DX10.1-ben már négyszeres sebesség érhető el a Gather4 által, míg DX11-ben a LDS ezt a tempót is a háromszorosára emeli. Persze ez az effektre levetített gyorsulás, mert egy játékban más is renderelésre kerül, de a BattleForge alatt látható, hogy mennyit gyorsul a rendszer a DX10-től a DX11-ig +45-55%-ot lehet mérni. A többi játéknál (nem mindben) ez nincs meg, mert a fejlesztők úgy döntöttek, hogy DX11 alatt eleve lassú lenne az effekt, így nem is engedélyezték. Lényegében maradhatott volna a DX9 SM3 is, mert közel ugyanarra a látványvilágra képes, de mindezt feleakkora sebesség mellett. És még akkor ott van a DX11 egyik legjobb fícsőre, amit még nem is implementáltak teljesen a gyártók a driverbe. Ugye ez a rajzolási parancsok többszálú feldolgozása. Mondjuk eddig csak a Civ 5 támogatja ezt a funkciót.
