üzenetek

hozzászólások


gbors
(nagyúr)
Blog

Olyan véleményt tudok mondani, ami elsősorban a jelenségekre és a "dolgok logikájának" ismeretére alapoz, nem pedig mély műszaki ismeretekre a GCN felépítése kapcsán. Korrekció / vita welcome :)

Az biztos, hogy a GCN tervezésében faktor volt a konzol-igények kiszolgálásának lehetősége, de azt nehéz megállapítani, mennyire, mert a GCN "gründolása" még azelőtt történt, hogy az AMD megnyerte volna a dealeket. Az ezzel járó extra tranzisztorigényt két dolog árnyalja:
- Ezen funkciók egy (talán jelentős?) része kell a DX12-höz is, amiben az AMD "jó" szokása szerint már a DX11 megjelenésekor is gondolkodott, így ha az első GCN-eknek fájtak is, a mostaniaknak már nem vagy sokkal kevésbé kellene
- A fogyasztást ismereteim szerint leginkább drive-oló két terület az ALU-k és a memóriavezérlő - ezeket tudtommal kevéssé érintik a konzolos funkciók

A GCN kapcsán az elszaladni hajlamos fogyasztásért (vagy az alacsonyabb hatékonyan üzemeltethető órajelért, ahogy tetszik) én az ALU-kat hibáztatom. A multiprecíziós lehetőség technikailag egy gyönyörű megoldás, de a gyakorlat a mai napig nem igazolja a szükségességét játékokban, ezért csak eszi az extra tranzisztorokat, és ebből következően viszi felfelé a fogyasztást, míg értéket nem termel. Lesz 1-2 játékban rapid packed math - lássuk meg az eredményét, szerintem minimális lesz.
A memóriavezérlő közvetetten probléma: láthatóan a HUB kevésbé hatékony, mint az nVidia crossbarja, és ezért azonos effektív sávszélességhez szélesebb busz és / vagy magasabb órajel kell, ami megintcsak felviszi a tranzisztorok számát és / vagy a fogyasztást.

Végül, a továbbfejlesztéses érvet nem eszem meg :)

[ Szerkesztve ]


lezso6
(HÁZIGAZDA)
Blog

A Pascaltól is multiprecision az FP32 ALU, azaz két FP16 operációt képes végezni, ebben a tudás ugyanaz, mint a Vegánál. Szóval pont hogy inkább a Vega zárkózott fel ebben. Az NV-nél csak annyi a csavar, hogy a konzumer kártyáknál tiltják az FP16-ot. Ha elterjed a Rapid Pack Math, akkor az NV-nek érdeke lesz engedni az FP16-ot teljes sebességgel, ez lenne az ő csodadriverük.

Az AMD problémáját én nem magában a GCN-ben látom. Hanem a körítésben. Ami nem compute, abban elvérzik. Persze ha Abu vagyok, akkor csak annyit mondok, hogy GRAMPS és minden a legnagyobb rendben van. :D

[ Szerkesztve ]


b.
(félisten)
Blog

:DDD :DDD Az utlosó mondaton hangosan felröhögtem .

[ Szerkesztve ]


lezso6
(HÁZIGAZDA)
Blog

Abura visszatérve egyébként azért érdekes dolgok vannak. Ugye amikor DX11 volt, akkor GCN indulásának táján azt mondta, hogy nem lesz DX12, hanem "szoftver render" lesz. Utóbbi alatt nem az értendő, hogy visszamegyünk a kőkorba, hanem hogy a grafikai futószalag nem lesz fix.

Ugye 2009-ben jött a DX11 illetve a GRAMPS paper. Utóbbi a jövőt vázolta (esetleges DX12, új API-k), s teljesen logikus lépésnek is tűnik, hiszen a jelenlegi DX grafikai futószalag alkalmatlan például ray-tracingre. A compute shader jött még mint félig megváltó valami, mert azzal megkerülöd a grafikai futószalagot és ezzel együtt a limitációit is. Ez teszi lehetővé Asyncronous Compute-ot is.

Tehát lényegében van nekünk egy legacy, fix valamink, a grafikus futószalag. Ehhez képest mi történt? Semmi nem valósult meg a GRAMPS-ból, vagy legalább alig, inkább más limitációkat kellett megszüntetni.
2013-ban jött a Mantle, melynél a lényeg tömören az, hogy a driver feladatait minimalizálja, s a fejlesztőnek ad rengeteg kontrollt. 2015-ben ennek köszönhetően megszületett a DX12. A többit tudjuk. :D

De WTF is GRAMPS? :F Ugye egy programozható futószalag modell lenne. De ennek megértésehez érdemes visszamenni az időben.

Elsőnek vegyük a régi fix futószalagot, ahonnan indultunk, hardveres transzformációval és megvilágítással (HW T&L), amit először hardveresen a Geforce 256, szoftveresen pedig a DirectX 7.0 hozott el. Valahol itt végződött el az a folyamat, hogy a CPU-t tehermentesítsük a GPU-val. Viszont problémát okozott a grafika programozhatóságának teljes hiánya, csak fixfunciós egységek voltak a GPU-kban.

Itt jöttek a shaderek, a programozhatóság, DX 8.0-tól. Az elmúlt idő alatt a futószalagot gyakorlatilag agyonfoltozták egy halom shaderlépcsővel, mindegyik egy bizonyos fázisokban, bizonyos feladatokra alkalmazható. Persze kombinálhatók is. Ezeken kívül volt persze sok más módosítás is a futószalagon, de a shaderek a leglátványosabbak, s ezek használják a teraflops-ok erejét. Tehát:

1. Pixel vagy fragment shader (DX 8.0): egy adott terület (jelen esetben pixel) színét tudod vele programozni, hogy hogyan nézzen ki. Legegyszerűbb alkalmazása pl valamilyen post-process effekt, de lehet vele egy adott felület árnyalni is.

2. Vertex shader (DX 8.0): egy pontot a térben (poligon csúcspontját) tudsz vele átpozicionálni.. Például víz hullámzása ezzel oldható meg, miközben pixel shadert használva megárnyalod a víz felületét. De pl ugyanígy lehetséges az árnyékolás is.

3. Geometry shader (DX 10): ez létre tudsz hozni új primitíveket, azaz pontokat, egyeneseket vagy teljes háromszögeteket is. Ez elég sok lehetőséget ad komplex effektek segítésére. Pl jóval pontosabban árnyékolás lehetséges vele, de ez csak a jéghegy csúcsa.

4. Hull és domain shader (DX 11): ezzel tudsz durvább geometriai vázakat felbontani sokkal finomabbra egy általad definiált algoritmussal. Ez nem más, mint a tesszeláció.

5. Primitive shader (Vega only): ez eléggé csodabogár. Ezzel meg tudod oldani GPU-gyorsítva az ún. cullingot, azaz a szükségtelen, nem látszó primitívek eldobását. De ezen felül a vertex, geometry és domain shader is kiváltható lenne vele, tehát egyfajta utódként is tekinthetünk rá, vagy foltozás foltozásaként. :D DX support jelenleg nincs.

6. Compute shader: ezt nem igazán kell magyarázni, a grafikai futószalagon kívül van. Sok minden már gyorsabb ezzel megvalósítva, mivel nem követel meg bizonyos hardverállapotot, mint az előző shaderek. Szóval egyre népszerűbb ezt használni.

A GRAMPS úgy jön ide, hogy már a futószalag is programozható, tehát nem fix. A jelenlegi formájukban a fixfunkciós egységek kukák, és programozhatónak kell lenniük. A primitive shader pont ebbe az irányba mozdult el (programozható geometriai motor), szóval ezért van körülötte akkora buli.

A GCN egy svájci bicska, jelenleg nagyon kevés választja el attól, hogy megfeleljen a GRAMPS-nak, mint hardver. Lehetséges, hogy arra apelláltak az elején, hogy ez progresszív irány lesz a jövő, csak aztán alaposan felsültek vele, sehol nem vagyunk. Még mindig eléggé messze van ez GRAMPS nevű csoda, erre még várni kell, egyelőre csak kutatások vannak ezirányban. Addig marad a foltozás, azaz a Compute Shader trükközés meg a Rapid Pack Math.

[ Szerkesztve ]


b.
(félisten)
Blog

Ha megnézed azért a CPU tehermentesítés elég jól működik radeonoknál. Sokszor azonos CPU val 20 % erőforrás magtakarítás van az oldalukon Nv kártyával összevetve.
2015 ben úgy behozni egy Dx verziót , amihez semelyik oldalon nem volt 100% os hardver, eléggé érdekes lépés volt. Ebből is tisztán az jön le számomra, hogy ez a Dx verzió nem a felhasználók céljait szolgálja elsősorban, hanem a készítőkét, azon belül is Microsoftét. A készítők könnyebb- gyorsabb szoftver átportolást és nagyobb átjárhatóságot kaptak .( kevesebb munka és több pénz) ráadásul egy bizonyos Operációs rendszerhez kötött. Igazából nem is értem, hogy kajáltuk be, illetve hogyan nem lett más megoldás erre, mikor Mantle- Vulkan sokkal többet tudna nyújtani Dx 11 után és valóban előrelépést jelentene, de mivel ehhez nulláról megírt motorokra lenne szükség , meg jó sok pénzre, gondolom ez miatt várunk már 3 éve.
Én úgy gondolom, hogy jelenleg ott tartunk, hogy két szék között a földre ültünk Dx 12 és Vulkan sincs a beígér formában és nem valósított meg sok olyan dolgot, amit anno reméltünk ( real multi GPU, drivermentesség stb). jelenleg alig van grafikai motor ami nulláról lett megírva és megfelelhetne egyáltalán a GRAMPS követelményeinek és abból hasznot tudna hozni sebesség terén..Ennek a csoda dolognak majd az lesz a kapuja, hogy Dx 13.. :DDD

[ Szerkesztve ]


gbors
(nagyúr)
Blog

Ezt tudod biztosan, hogy van ilyen üzemmódja? Ui. lehet ezt szimulálni, ha a parancsprocesszor egy kicsit besegít.

(#85) b.: a Vulkan és a DX12 problémája az, amit az első pillanatban lehetett tudni, és mondtuk is többen - az erőforrás. Nem a technikai, hanem az emberi. A csúnyarossz DX11 rengeteg dolgot a fejlesztők segge alá tesz, és láthatóan még a jobbak is küzdenek vele, hogy jobb hatékonyságot hozzanak ki a DX12-ből, több munkával (amit talán a konzol-közelség miatt vissza tudnak nyerni, talán nem).


gbors
(nagyúr)
Blog

Igen, és azt írják, hogy ez a GP100-ban megvan, a GP104-ből hiányzik.


lezso6
(HÁZIGAZDA)
Blog

Kicsit utánanéztem. Valóban kérdéses, hogy akkor most driverből fogják vissza az FP16-ot (vegyél GP100-at paraszt!) és / vagy ténylegesen nincs benne. Eleve még 1x sebesség sincs meg, pedig az eddig ment a Maxwelllel. :F


szmörlock007
(aktív tag)

Köszi a sok infót :R
Legkorábban a dx 13-nál lehet a grampsból valami. Bár sztem az még jóval messzebb van. Csak most jött ki a shader modell 6 ami megint csak rengeteg új dolgot/lehetséget hozott be. Sok idő míg ezt rendesen kihasználják.
A gramps pedig bár roppant igéretes, lehet arra a sorsra jut mint a ray-tracing: majd 10 év múlva :DDD


lezso6
(HÁZIGAZDA)
Blog

Azt azért ne feleljtsük el, hogy GRAMPS gyakorlatilag az API "butítása" tovább, szóval a fejlesztőkre egyre több munka hárul. :D Persze a renderelés feletti kontrolljuk nagyobb lesz.

Ugye a DX12 is erről a "butításról" szól. De ezt nem nagyon használják ki, csak a nagy fejlesztőstúdiók. S ez a helyzet szerintem nem fog egykönnyen javulni. :(


gbors
(nagyúr)
Blog

Hihető, amit az AnandTech ír - a GP102-be / GP104-be rakott extra FP16x2 mag kompatibilitási okok miatt van ott, feltételezem, meg lehet kerülni és lehet futtani az FP32-es magokon a 16-bites utasításokat, csak nem ugyanaz a packed megoldás lesz, hanem üresen hagyod a felső 16 bitet.


lezso6
(HÁZIGAZDA)
Blog

Az azonos sebességű FP16-nak is lehet előnye, ha natív. Ilyenkor a GPU tudja, hogy FP16, tehát nem foglal dupla helyet a gyorsítótárakban, stb.

Az viszont nem érthető, hogy miért nem FP16x2 a többi FP32 mag NV-nél. Mégsem éri meg? Vagy tényleg csak arról van szó, hogy vedd meg a legnagyobbat, ha FP16-ot akarsz? De a Tesláknál a GP102 és GP104-nél az INT8 megy izomból, arra van support. Tehát DL az mehet olcsóbban is, de FP16 nem? Mégis miért? :F Lehet azért, mert a sima FP32 mag tud 4x INT8-at, de az FP16x2 már nem? :)

szerk:

IGEN! https://devblogs.nvidia.com/mixed-precision-programming-cuda-8/

Na itt a kutya elásva. Többféle CUDA mag is van Pascaloknál. Inkább, így hívom, mint FP32-nek, mivel ugye kombinált magokról van szó. Ha megpróbálom összefoglalni, akkor kb így néz ki:

"Fermi" CUDA mag: FP32, INT32

"Maxwell" CUDA mag: FP32, INT32, FP16x2

"Pascal" CUDA mag: FP32, INT32, INT16x2, INT8x4

Na most az alap a Fermi-ben lévő mag. A Keplerben ugyanez van, sőt, szinte minden Maxwell-ben is, mert csak a Tegrák kaptak duplázott FP16-ot. Ultramobil felett ezt a tudást végül a P100 kapta meg, míg a kisebb Pascalok új magokat, mert a DL a fő fókusz.

A V100 esetén meg all-in van, itt már nem igazán beszélhetünk CUDA magokról, mivel szétválasztották külön FP és INT ALU-ra. Az FP ugye a Maxwell-féle CUDA mag lehet INT nélkül. Az INT-ről pedig elég nagy a kuss, hogy van-e INT16x2, de valszeg nincs, mivel az INT8x4 az nincs, mert DL-re ehelyett a Tensor FP16-tal operál, mint fixfunkciós mátrixszorzógép.

Itt kérdés, hogy kis Volták milyen magokat fognak kapni. Kétféle verziót látok:

1. Csak a Tensor magokat kukázzák, így játékoknál a Packed Math-ból ők is profitálhatnak, de pápá Mixed Precision Integer.

2. Marad a Pascal mag, és beintenek a Packed Math-nak, inkább tolják tovább a Mixed Precision Integer szekerét.

Játékos szemszögből értelemszerűen az első lenne jó. :)

[ Szerkesztve ]


b.
(félisten)
Blog

Ha lesz egyáltalán kis Volta :)


DeathAdder
(veterán)

Nagyon alapos, le a kalappal :R

Mennyire durva, mintha most lett volna a GTX 680 és 7970 pedig 2011..atyaég.

Annyi szakmai hozzáfűznivalóm van, hogy az én perverzióm matt imádtam a GTX 480-at, imádtam ahogy ordít, ahogy felfűti a szobát, ezek a maiak még csak nem is fújnak :D
Kicsit régi autó vs. új autó szindróma :D


belaur
(tag)

Tartalmas cikk, köszönjük.


gbors
(nagyúr)
Blog

Hmmmm, nice catch. Mondjuk ha ezt tudják csinálni, akkor a lego skilljeik meglehetősen magasak.
Őszintén szólva nem nagyon hiszek az FP16-ban, egyrészt manapság a kártyák nem ALU-limitesek, másrészt a reális alkalmazási területet sem látom nagynak (reális = nem lesz belőle komolyabb minőségvesztés). Cserébe nem tudom, mit veszítenénk a mixed precision integerrel. Lehet, hogy nem nyilvánítok véleményt a két opciód kapcsán :DDD


lezso6
(HÁZIGAZDA)
Blog

És ugye van az FP64, ami teljesen külön ALU NV-nél. AMD-nél ez nagyon másképp megy, ugyanúgy INT32-t is tudnak az FP32 ALU-k, de FP64-ben kicsit vegyes a kép:

GCN1: 1/4 FP64
GCN2: 1/2 FP64
GCN3: 1/16 FP64, natív FP16 és INT16 de utóbbiak csak azonos sebességgel
GCN5: 1/16 FP64, FP16x2, INT16x2, INT8x4

GCN4-et kihagytam, mert nincs változás, ISA-ban ugyanaz, mint a GCN3.

Az AMD ugyanazt az utat járja, csak FP64-ben kompromisszumos, a GCN architektúra miatt nincs más választása, mint hogy az FP32 ALU-kat (pontosabban 16 utas SIMD tömböket) fogja be FP64-re. De 1/2 FP64-et csak egyszer láttunk, azóta meg vicc a teljesítmény ebből a szempontból, inkább kisebb pontosságra gyúrtak a FP64 hátrányára. De ott nagyon.

Persze ezek csak az adattípus támogatások, a műveletekről egy szó sem esett, ebben az AMD sokkal jobb. Lásd mining. :D

A Rapid Pack Math pedig jó, persze ez Compute Shader-en kersztül használhatos, szóval szokás szerint csak top motorok fogják nyomni, ahogy minden új feature-t. :D Sok esetben simán jó a kisebb pontosság is, továbbá a Rapid Packed Math nem csak FP16-ról szól, hanem INT16-ról is. Utóbbit pedig lehet használni a mostani GeForce-okon is. Így viszont az a kérdés a kis Voltáknál, hogy az NV melyik kezébe harapjon, ha Rapid Packed Math-ról van szó. :D INT16x2 vagy FP16x2. Persze lehet a Volta INT ALU-i tudnak INT16x2-ot, így elég a Tensort kidobni és kész.

[ Szerkesztve ]


menyus4661
(tag)

Hihetetlenül érdekes cikk.Gratulálok,egyik legjobb írás amit olvastam. :R


gbors
(nagyúr)
Blog

Egyre gyanúsabb nekem ez az nVidia... Ha ennyire ügyesen legóznak, akkor nem lehet, hogy nekik is egy szett ALU-juk van, és különféle pontosságokat (FP64 = 1/2 FP32, FP16 = 2xFP32, stb.) valamiféle okos wrapperekkel oldják meg? Amiket aztán vidáman kihajigálnak azokból a chipekből, ahol nincs rá (szerintük) szükség. Csak mer' állítólag az FP64-es unitok fizikailag elkülönülnek, akkor miért pont a felét hozzák az FP32 teljesítménynek? Stb.

Őszintén szólva, nem tudom, hogy melyik adattípus mennyire hasznos. Az FP10-es színformátumról (3x10+2-bit) tudom, hogy elterjedt, de pl. nem tudom, az FP16 (4x16-bit) mennyire gyakran használt, és ugyanígy az INT8-at (4x8-bit) sem tudom.
Azért a 16-bit csak max. 65000 variáció, nehezen tudok olyan nagy tömegű műveletet elképzelni, ahol ez elég - már csak azért is, mert ha sok a művelet, akkor a kerekítési hibák akkumulálódnak.

üzenetek