Keresés: - [Re:] Inkább program oldalról támogatná a primitive shadert az AMD

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

Új hozzászólás Aktív témák

#67 con_di_B tag namaste #66

Új Válasz 2018-01-26 11:49:40 #67
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

con_di_B

tag

válasz namaste #66 üzenetére

"Nem a skalár egység miatt van a magas fogyasztás."
https://en.wikipedia.org/wiki/Graphics_Core_Next
Amennyire en ertem egy wavefront 64 szeles, amit ugy szolgal ki a rendszer, hogy egy valojaban 16 szeles SIMD mag 4 egymast koveto utasitasa lesz garantaltan ugyanaz. Ez egy eleg tipikus design, a szelessegben van elteres. Aztan egy CU-n belul van 4x ezekbol a SIMD magokbol, tehat osszesen 4x16 szeles feldolgozorol beszelunk (fizikailag), szoval osszesen 64 VALU CU-nknent.
Ehhez jon pluszba egy azaz egy darab SALU. 1/(64+1) logikusan nem kene, hogy annyira durva fogyasztast adjon ki, maximum akkor, ha vannak olyan extra funkcioi, amit a VALU-k nem tudnak, de a "bekotes" maga az nem egy ilyen komplikalt feature. Ha egy SFU (double-precision trigonometriaia fuggvenyek es hasonlo alig hasznalt dolgok) lenne fizikailag a SALU-ba epitve, az lehetne ilyen, de akkor az nem fair osszevetes, mert olyan meg van a tobbi hardverben is.
Es akkor ez egy szandekosan sarkitott, konzervativ becsles volt, mert ott vannak meg a TMU-k is stb. a CU-ban, amik szinten nem a SALU extra fogyasztasa fele billentik a merleg nyelvet.
Azt nem ketlem, hogy az AMD-sek tenyleg ezt mondtak Abu-nak, hogy azert magas a fogyasztas. De mondanak azok sokmindent, es sajnos nem mindig stimmel.
"Persze ha csökkentik a feszültséget, akkor először a skalár egységet kapcsolják le, ugye?"
A SALU esszencialis resze egy CU-nak, egyaltalan nem tud nelkule mukodni, szoval azt se lekapcsolni nem fogjak, se kulon nem lehet az orajelet, feszultseget allitani, semmi ilyesmi. Ez a narrativa, hogy a SALU az egy "bindless mode" gyorsito ennyiben kicsit santit, foleg, hogy mint mondtam, jo az masra is.
Visszaterve a fogyasztas reszere, bizonyos programoknal viszont a fordito nem fog semmilyen ertelmes modot talalni a SALU hasznalatara a bekotesen kivul, ebben az esetben viszont a SALU az ido 99%-ban konkretan idle. Na, ha ertelmesen implementaltak, akkor ilyenkor sem kene sokat fogyasztania...
"A bekötésnél pontosan hogyan segít a CPU? Mert renderelés közben (pl. texturázás) nincs idő a CPU-hoz fordulni."
Az igazi hardcore kobunkos GPU-knal ez annyira durva, hogy meg utemezo sincsen normalisan, hanem a driver a command buffer-be beforditja elore, hogy melyik reszegyseg mit fog csinalni, es igy, mar elore behuzalozva erkeznek a parancsok, nincs min gondolkodni ugymond. Bizonyos mertekig meg a Kepler is ilyen volt.
Nagy vonalakban abban van elteres, hogy mekkora merteku az utemezes szabadsaga a GPU-n, mert ahol keves, ott tobb parhuzamos task mellett rossz lesz a hatekonysag. (Ezert lovagol az AMD annyira az async compute-on, mert az o rendszeruk rugalmas, ebben jo.)
Es igen, amit mondtal, hogy nincs ido a CPU-hoz szaladgalni menet kozben, ez igy igaz, ezert praktikus okokbol kell elore eldonteni az utemezest. Amit Abu mond az Intelrol, azt nem tudom, siman lehet, hogy nekik belefer.
Ez az utemezes kozpontu nezet amit az elobb irtam ez persze inkabb a compute nezet, mert minket tobbnyire a maximalis savszelesseg erdekel, nem annyira az alacsony kesleltetes. Grafikaban ugyanezt onnan szoktak nezni, hogy ha minden vackot bele kell gyogyitani a command buffer-be, akkor gyakorlatilag semmit sem lehet skalazodni tobbszalu vegrehajtas mellett sem, mert a normalis driver oldali utemezeshez kb. elore kene latnod a jovobe, hogy a tobbi szal mit csinal majd, ez pedig nem valami eselyes. A masik baj, hogy ha tul sok globalis allapotod van, akkor meg felpercenkent le kell allni szinkronizalni, es emiatt erosen limitalt lesz, hogy hany rajzolasi parancsot tudsz kipreselni a rendszerbol egysegnyi ido alatt.
Az AMD rendszere elmeletben ez utobbiban is jo lehetne, csak a gyakorlatban inkabb savszelesseg orientalt a rendszer, szoval csak azert mert nem dobja fel a talpat a rendszer egy pillanat alatt, ha razuditasz par tizezert draw call-t, attol meg nem feltetlenul lesz nagyon bajnok a kesleltetese.
Ja es a vegere: ez a rendszer viszont utemezovel es mindennel egyutt viszont mar nyilvan fogyaszt. Lehet, hogy igy ertettek a SALU koltseget, hogy SALU + ACE + HWS + franctudja meg mik kellenek ehhez.
#63 con_di_B tag Petykemano #61

Új Válasz 2018-01-25 18:47:36 #63
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

con_di_B

tag

válasz Petykemano #61 üzenetére

Megfeszulni es meg mindig alul maradni meg marketing szempontbol is sokkal kevesbe ertelmes, mint legalabb egy valamiben optimalisnak lenni.
Igy arrol beszelgetunk, hogy az NVIDIA technologiaja sokkal jobb. Ugy meg arrol beszelgetnenk, hogy masban jok.
Persze most is sokan szeretnenek utobbirol beszelgetni, csak nem nagyon all meg a laban. MAR nem jobb a GCN compute-ban sem.
#57 con_di_B tag Petykemano #53

Új Válasz 2018-01-25 17:00:54 #57
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

con_di_B

tag

válasz Petykemano #53 üzenetére

A nagy vonalakban lehet sejteni, hogy hol kiegyensulyozatlan a rendszer:
https://www.techpowerup.com/gpudb/2839/geforce-gtx-1080
https://www.techpowerup.com/gpudb/2871/radeon-rx-vega-64
https://www.techpowerup.com/gpudb/2877/geforce-gtx-1080-ti
a Vega ALU fronton meg az 1080 TI-nel is erosebb, raadasul ezek az ALU-k mint altalanos szamitasi egyszegek eleg popecul optimalizalva is vannak (nem veletlenul szeretnek veluk banyaszni), raadasul mostanra a texture mintavetelezesi teljesitmeny is korrekt, viszont a ROP backend teljesitmenye meg a sima 1080-et sem eri el. Gondolom ezt akarna jelenteni a pixel throughput.
Es akkor ez meg csak egy nagyon high-level nezopont volt, es nem mentunk bele, hogy ha a tranzisztorszama ekkora a Vega 64-nek es meg HBM2-vel is van sulyosbitva, akkor dragabb lehet gyartani, mint az 1080 Ti-t, az meg nem annyira effektiv, ha cserebe nem tudod ugyanannyiert vagy dragabban adni.
Low-level meg az van, hogy ha normalisan megirsz egy compute programot (na erre nem fogok tudni public benchmarkot mutatni most gyorsan) OpenCL-ben akkor ugyanezek a kartyak inkabb ALU alapjan skalazodnak, es az NVIDIA-nak nincsen semmifele varazslatos elonye, szoval a kulonbsegnek teljes mertekben a rendereleshez kotodo reszekbol kell eloallnia - vagy a TMU a ROP es a CU-k nem tul hatekony egyuttmukodesebol, de valahol mindenesetre el van asva a kutya.
Egyebkent ha mar valamiert muszaj lenne ragaszkodnia az AMD-nek ezekhez a high-level aranyokhoz, akkor meg kiserletezhetnenek olyasmivel mint amit anno a Kepler csinalt, csak ellentetes elojellel, hogy a CU-k jarhatnanak kulon orajelen, ami lehetne LASSABB mint a rendszer tobbi resze. Ez azert se volna rossz, mert akkor az ALU-kat nem volna muszaj speed racerre tervezni, "csak" a specialisan grafikai celu reszegysegeket. Ebbol aztan lehetne egy olyan rendszer, ami compute terheles alatt kellemes teljesitmenyt nyujt eros fogyasztas mellett, grafika alatt meg relative tobbet zabal, de legalabb nem bottleneck-eli az ALU-kat.
#56 con_di_B tag Abu85 #49

Új Válasz 2018-01-25 16:45:51 #56
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

con_di_B

tag

válasz Abu85 #49 üzenetére

Ez tok jol hangzik, de onalloan csak azert mert globalisan (osszessegeben) ennyivel kevesebb adatot kell mozgatni, nem feltetlenul jelenti, hogy a rendszer egesze a leheto legjobban fog belole profitalni, es a fogyasztas is ennek megfeleloen esik.
Elmeleti pelda: lehet h a VRAM savszel igeny 30%-al csokken, ami tok jo, de ha melle orrba szajba cache miss van, akkor meg mindig nem biztos, hogy annyira jo lesz a tortenet vege, mint egy olyan rendszeren, ami magasabb cache hit-et tudna produkalni. Aztan a mozaikos torteneteknek meg az lenne lenyege alapvetoen, hogy mindig minden eppen keznel legyen, minel alacsonyabb szintu cache-ben.
De ez csak tippelgetes, a konkret esetre nem lattam profilt soha.
A masik, szinten elmeleti fejtegetes, hogy mivel a HBM2 eleve viszonylag keveset fogyaszt mondjuk a GDDR5-hoz kepest, ezert lehet, hogy ezert sem latunk hatalmas kulonbsegeket a Vega-nal. Ennek nemileg ellentmond, hogy a Vega vs Pascal versenyben az ollo nagyobb mint amennyit a GDDR5 modulok osszesen fogyasztanak, szoval lesz ott meg mas baj is, lasd fentebb.
#54 con_di_B tag Petykemano #50

Új Válasz 2018-01-25 16:01:27 #54
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

con_di_B

tag

válasz Petykemano #50 üzenetére

Grafikaban DX11-ben semekkora elonyt nem is tud jelenteni, DX12-ben meg akkor tudna, hogy ugy lenne megtervezve az engine, de ez techdemokon kivul nem hiszem, hogy akar meg manapsag is elfordul. De azokban a techdemokban tenyleg tok jol muzsikal!
Compute-ban tud ertelme lenne, mert ha eppen raerez a fordito akkor ki tud szervezni olyan muveleteket is amik az osszes lane-en ugyanazt adnak, pl. index kalkulaciok egy resze (van egy bazis ami ugyanaz, es az offset ter el) stb. Ezeken elmeletben lehet fogni nehany Joule-et, ami aztan a gyakorlatban abban mutatkozik meg, hogy tovabb birja a turbo-t, mert egyebkent kb. gyarilag tulhajtott parameterekkel jon minden GCN-es kartya. Ezert talalsz annyi hirt arrol, amikor alulfeszelve (nem feltetlenul underclockolva!) meg gyorsul is a kartya.
Amit meg leirtal tortenetnek, igen, pontosan ugyanigy kepzelem en is.
Ez a tortenet elegge tipikus egyebkent, torvenyszeruen ilyesmik tortennek minden cegnel ahol eroltetik az agile-t az R&D-re is. A jelentos ugrasok, amikre szukseg lenne, messze vannak, ezt a mernokok tudjak, de ha azzal allnak elo, hogy "ki kene vagni a mostani architekturat a kukaba", akkor az megkapja, hogy ez nagyon draganak es kockazatosnak hangzik, es visszazavarjak oket a tervezoasztalhoz, hogy inkabb csiszolgassak a mostani architekturat, hiszen "amikor kijott a GCN azt azert finansziroztuk, mert azt mondtatok, h ez annyira modern, h 10 evig megelunk belole, szoval hajra, csinaljatok tovabb".
Aztan amikor egy ideje ez lesz, akkor a mernokok elkezdenek alkalmazkodni, es rajonnek, h lehet ezt ugyis csinalni, h csak azert is megcsinaljuk amit akartunk, de lepesenkent, es akkor az egyes iteraciok kozott lehet amortizalni a koltseget, es akkor maris nem lesz olyan ijeszto, ezt meg a managerek is kepesek lesznek felfogni agyilag (akik persze nem eleg kepzettek, h egynel tobb fejlesztesi modszertant ismerjenek).
Aztan ebbol lesznek az ilyen semmire se jo oszvermegoldasok, mint a Vega. Ennek a fajta alkalmazkodasnak viszont az a nagy problemaja, h mivel a nagy terv valojaban nem feltetlenul volt soha kimondva meg cegen belul sem, eleg elmennie par kulcsembernek, akik ertettek, hogy mi miert van, es akkor csak az oszver marad a nyakukon, de a perspektiva eltunik.
Es akkor most imadkozzunk egyutt az AMD reszvenyeseiert, hogy ez az ember ne Raja Koduri legyen.
#48 con_di_B tag

Új Válasz 2018-01-25 14:37:02 #48
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

con_di_B

tag

https://www.gamersnexus.net/guides/2977-vega-fe-vs-fury-x-at-same-clocks-ipc
Oke, ez a Frontier edition, de a lenyeg akkor is atjon: leginkabb csak a magasabb orajelbol van elony.
Ami pedig a programozhato skalar ALU-t illeti: ez csak az egyik tenyezo, de a GCN torteneteben ez nagyjabol addig all meg amig a Kepler volt az ellenfel, akkoriban pedig meg nem is volt ennyire szetnyilva az ollo.
Ami grafikaban a nagy kulonbseget jelenti, hogy a Maxwell ota az NVIDIA az egesz chipet egyfajta Tile Based iranyra kezdte el optimalizalni, ennek megfeleloen alakultak at/ki az SMX modulokban a gyorsitotarak illetve a regiszterterulet es a cache aranyai, valamint az, hogy lett normalis LDS. Es ez az uj felallas ennyivel hatekonyabb.
Erre ugrana a DSBR-rel az AMD is, de attol, hogy beteszik a feature-t, de semmi mast nem valtoztatnak, a jelek szerint nem fognak messzire jutni onmagaban. (Lehet, hogy a Navi-nal ezt jelento az uj memoriaarchitektura, h ezt javitjak?)
Aztan mindez nem lenne akkora baj az AMD-re nezvest, ha egyuttal nem sikerult volna a compute ollot is teljesen jol zarnia az NVIDIA-nak.
Szoval osszessegeben ez sokkal inkabb a "tobb R&D" penz kozeptavon leverte a "kevesebb R&D" penzt tortenet, es ebben konzisztens munka es sok optimalizacio van, nem szimplan annyi, hogy az AMD compute orientalt, az NVIDIA meg grafika.
Piaci eretelemben eleve az NVIDIA a sokkal sikeresebb compute vonalon is.
En amugy nagy 7970 hivo voltam amikor kijott, de az nem tegnap volt!
A Vega-ra nezve pedig, ranezesre ez sokkal inkabb ugy nez ki, mint ket rendes generacio kozott valamifele oszver, mint egy kerek egesz. Valoszinuleg a primitive shader meg a DSBR is azert kerultek be, hogy addig is lehessen tesztelgetni valamit, amig laba nem no. Es nem, ez nem mernoki elorelatas, hanem sporolas ezerrel.