Nem, mert különben nem lehetne egyszerre futtatni a különböző típusokon dolgozó műveleteket. Legalábbis Volta FP32 és INT32 operációkat egyszerre tudja futtatni. Az FP64 is így kell hogy legyen, különben már rég lebuktak volna, elég egyszerű erre tesztprogramot írni. És ugye FP64-ből szimplán csak kevesebbet tesznek bele, mert jóval nagyobb a mérete, kisebb a piac, nem éri meg egy über FP64 chipet összedobni csak úgy, főleg ha DL irányba mennek.

Az 16 bitet ne színként képzeld el, úgy csak rossz lehet, 65k szín. Illetve azzal a logikával, hogy a 65k kevés, az FP32 is az, hisz az FP64 9 trillió értéket tud, míg a FP32 "csak" 4 milliárdot. Sok helyen elég a 65k érték is, sőt valahol a 256 is, az átlátszóságnak például pont ennyi fokozata van, ezért tud profitálni a TressFX az FP16-ból.

Igen, pont az lett volna a következő kérdés, hogy lehet-e párhuzamosan peak performance körül futtatni a többféle típust. Ha igen, akkor bukott a konteo

A hangsúly a nagy tömegen van - színről pedig nem is beszéltem

[ Szerkesztve ]

Értelemszerűen nem mindenhol lesz elég a FP16, nem csodafegyver. De sok esetben alkalmazható ez is, azért elég sok helyen overkill a 4 milliárd érték, elég 65k is. Persze ha elterjed a Rapid Packed Math, akkor majd abban kell reménykedni, hogy nem fogják ott használni, ahol jól látható minőségvesztést kapsz, azaz hogy nem fognak vele trükközni. Erre ugye sajnos láttunk már nem egy példát.

Hatalmas lett, szép összefoglaló! Azt is érdemes lenne megvizsgálni, mikor milyen vezetőváltások voltak a cégeknél... Hátha az egyes húzásokkal korrelálna.

A "nagy tömeg" alatt nem a sokféle alkalmazást értem, hanem az adott alkalmazáson belüli rengeteg műveletet. Én nehezen tudok elképzelni olyan alkalmazást, ahol elég a 65k variáció és rengeteget kell számolni - mondj pár példát pls.

(#103) átlagJózsi: a teljesítmény / tranzisztor értéket jellemzően rontja, mert inkább az szokott lenni, hogy túltolják a feszültséget a kicsit nagyobb teljesítmény érdekében, de ettől a tranyók száma ugyanaz marad. Ugyanebből következően a teljesítmény / fogyasztást jelentősen javíthatja. A gond ezzel amúgy az, hogy egy optimalizált beállítást nagyon sok kártyán le kellene tesztelni ahhoz, hogy hitelesnek lehessen tekinteni.

(#105) hcl: jó gondolat Az nVidiát realtime megvizsgálom: 0 vezetőváltás
Az AMD kicsit komplikáltabb, ugyanis az architektúrák teljes életciklusát kellene felrajzolni a vezetői változások tükrében (és itt nem csak CEO, hanem a technológiai és akár a pénzügyi főnök is számít) . Ha egyszer sok időm lesz, elgondolkodom rajta.

Ezt értettem, a rengeteg egymás utáni számolással egyre pontatlanabb eredményeket kapsz. Ez világos. Csak a grafikára ez nem jellemző, persze van ilyen, de inkább sok szálon kevés műveletet végeznek, ezért elegendő lehet a kisebb pontosság is.

Példának ott van a Wolfenstein, Far Cry 5 meg magának a 3DMark-nak is lesz erre egy benchmarkja.

Gbors: Ha az rx 480-ban 32 helyett 48 rop lenne, az szerinted mennyivel dobná meg a teljesítményt?

Dehogyis, mi van a több 100 soros shaderekkel, amik pixelenként futnak?
A Wolf II-ben és a FC5-ben is úgy tudom, hogy pár izolált dolgot számolnak FP16-tal. Pont az érdekelne, hogy mik ezek.

(#108) szmörlock007: a +50% ROP átlagosan 10% extra teljesítményt jelent kiegyensúlyozott esetben. Mivel a Polaris közepesen-erősen ki van éheztetve ROP terén, ezért további 5-15%-ot saccolnék a ROP-ok hatására, abban az esetben, ha a memóriabusz is megnőne 384-bitesre. Ha marad a 256-bites busz, akkor nehéz behatárolni az eredményt - az AMD architektúrája elég pazarló ezen a téren, elvileg nem kellene nagyon visszafognia a 256 GB/sec sávszélességnek a 48 ROP-ot (a GTX 980 64-et etetett kevesebből), de gyakorlatban fene tudja. Szóval valahol 15-25% között, időnként meglepetésekkel a sávszél miatt.

Igaz, azt pl. kevésbé tudni, ki felelt cégen belül azért, hogy mikor merre menjenek az újítások, de biztos érdekes lenne, mikor ki jelölte ki a (rossz) utat.

Szerintem elbeszélünk egymás mellett. Nem komplett shaderprogramok bruteforce átírására gondolok, mert az minőségvesztést is okoz. Optimalizációról van szó, azaz pl egyes változókat, melyek pontossága nem kritikus, át lehet vinni félpontossságúra. Ahogy mondod. Illetve ne csak pixel shaderre gondolj, van egy halom más shader is, melyek vertex pozíciókat számolnak a térben vagy compute, ott nem feltétlen szükséges a FP32 vagy INT32 pontossága.

Tessék, egy marketingslide, de látszik legalább, hogy mire használják:

[ Szerkesztve ]

A vertex-nél (meg minden geometriánál) szerintem nagyon kell a pontosság, mert ha kicsit bizonytalan valaminek a pozíciója, abból shimmer lesz. A compute-nál nyilván attól függ, mire használod.
Köszi a példákat - pont az érdekel, hogy ezek milyen fajsúlyú dolgok. A két noise generationt én marginálisnak gondolom, a bloomhoz az FFT-k már komolyabbnak tűnnek. Persze ajándék FPS-nek nem nézzük a fogát, de engem konkrétan az érdekel, hogy mit veszítünk az egész kép tekintetében, ha nincs duplasebességű FP16. Remélem, ebben a 3DMarkban lesz opció, amivel ki lehet kapcsolni a packed üzemmódot.

A shimmeringet inkább az okozza, hogy pl nincs AA, vagy gagyi temporális AA van, esetleg az eljárás glitches, stb.

Ha az elmozdítás mértéke kicsi, akkor nem feltétlenül kell nagy pontosság. Pl tesszeláció. Pixelszintű dolgoknál mindenképp kell, hisz 65536 szín kevés, kivéve ha csak átlátszóságról van szó, pl fényeffektek, feltéve hogy a fény nem színes.

Engem is érdekelne a gyakorlati megvalósítás, hogy miket fognak erre építeni. Remélem lesz róla infó. Illetve az a probléma, hogy ezek AMD címek, tehát a packed math valós plusz teljesítményének mértékéről nem biztos, hogy lesz infónk.

[ Szerkesztve ]

Hát ez szuper lett! Nagyon szépen köszönöm.

A shimmer (egyik) oka a bizonytalan screen space pozíció, amin a gyengébb pontosság ront - ebből következően pont a kis elmozdulásoknál fontos, hogy ne hanyagoljunk nagyokat. Mindenféle AA eljárásokkal persze javítható / kiküszöbölhető, de ezeknek is van limitje, nyilván jobb, ha az inputjuk már eleve nem durva.

A mérésre igazán akkor van lehetőség, ha ki / bekapcsolható a rapid packed math használata. Ez gondolom egy játéknál nem lesz jellemző, de talán a 3DM-nél...

Amúgy örömmel látom, hogy mennyien elolvasták a cikket - őszintén szólva sokkal kisebb érdeklődésre számítottam, nem lett egy könnyed uzsonna melletti olvasmány Respect!

Pont kaja közben olvastam a nagy részét

Ha érdekel, és nem nagyon jön rá válasz, szerintem írj rá egy proof of concept-et, a szokásos open source objektumokkal és tesztképekkel. Ez pont egy olyan dolog aminek a kipróbálásához nincs szükség semmi extrára, simán kikísérletezhető otthon. Nyilván nem a számítógépes grafika történetének összes módszerét és trükkjét kéne implementálni, csak azokat amik érdekelnek, illetve érdekességi sorrendben, aztán ahol megunod, ott abbahagyod. És össze lehetne hasonlítani a különböző pontosságok különböző módszerekre gyakorolt hatását, ha eddig ezt más nem tette volna meg. Pl a screenshot-okat alávetni objektív képminőség-vizsgálati módszereknek. Nem vagyok képben az új API-kkal, de biztos azok is tudnak segítséget nyújtani a dologban.

Az iromány tetszett. Alapos, szép munka. Köszi!

Juj, nemá. Shimmering az mintavételezési probléma, s csak mozgásnál látható. Erre egyetlen ellenszer az élsimítás. Illetve textúráknál a túlélesítés okozza, ilyenkor vissza kell venni belőle vagy jobb szűrés kell. Nincs itt szó semmilyen bizonytalanságról, a kisebb pontosság következménye nem a bizonytalanság, hanem a pontatlanság, azaz nem remegni fognak, hanem nem pontosan ott lesznek a vertexek ahol kéne lenniük, feltéve, hogy ott használják az 16 bitet, ahol 32 bitet kellett volna.

[ Szerkesztve ]

Persze, hogy mozgásnál látható, állóképen max. kicsit deform lesz az objektum a rosszul számolt koordinátákat. A mintavételezési probléma nagyon tág fogalom, akár bele lehet érteni a world space -> screen space konverziót is. De szerintem ezt a szálat papír és ceruza nélkül túl sok értelme nincs folytatni