Új hozzászólás Aktív témák
-
válasz
namaste
#8410
üzenetére
Anno a 970-es műsor kirobbanásakor volt róla szó, hogy minden SM-hez rendelve van egy kiemelt ROP blokk / MC, amihez 128-bites busszal van bekötve. A többi esetében 64-bites a busz.
(#8411) HSM: A kártyák versenyképességét hasonlítottuk össze - itt a lelkes hobbista szempont talán 0.01%-os súllyal fér be.
Async: igen, téves ez a feltevésed. Nem ok nélkül hívják a grafikai munkát futószalagnak vagy pipeline-nak - a tesszelátor kiköp egy adag háromszöget, a következő lépcső (mondjuk a scanline konverzió) elkezd rajtuk dolgozni, de közben a tesszelátor már a következő adag háromszöget rágcsálja. Mint minden kiszámíthatatlan inputú futószalagon, itt is folyamatosan előfordulnak kisebb-nagyobb megállások - az aszinkron compute egyrészt arra való, hogy ezeket az ALU oldalon csökkentse, másrészt új, eddig nem a GPU-n végzett számítási feladatokat is be lehet hozni ingyen vagy alacsony ALU-költséggel. A PhysX pl. kitűnően elfuthatna egy aszinkron compute pipeline-ban, GPU oldalon igen kevés sebességveszteséggel. Valószínűleg az nVidia már vadul dolgozik ennek a megvalósításán
![;]](//cdn.rios.hu/dl/s/v1.gif)
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
Abu85
HÁZIGAZDA
válasz
namaste
#15305
üzenetére
Régebben mondta az NVIDIA, hogy így érdemes csinálni. De ugyanezt mondta az AMD is, csak ők azért tértek váltottak át memóriakímélésre, mert már nem crossbart használnak, de ha azt használnák, akkor valószínűleg ők is így csinálnák, mert előny teljes sávszélességgel elérni az adatot, mintsem felezettel. Azt kell figyelembe venni, hogy a memória olcsó lett. Régen nyilván nem volt célszerű duplikálni az adatot, de ma már az, mert annyira olcsó a GDDR5-ös és a DDR3-as memória, hogy megéri 3+ GB-os kártyákat tervezni. Gyakorlatilag belépőszinten sem találsz 2 GB-nál kevesebb VRAM-ot, tehát az NVIDIA számára célszerű hasznosítani a memóriát, ha már így alakult. Valószínűleg, ha az NV is vált a crossbarról, mert HBM mellett már nem ártana, és az explicit API-k sem a crossbarnak kedveznek, akkor átgondolják a menedzsmentet is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#15307
üzenetére
Gondolhatod, hogy az NV nem fog azzal kiállni, hogy ezt meg azt butítottuk a Keplerhez képest a Maxwellben.
Pont azért nincs anomália, mert a driver menedzseli a memóriát. Egyszerűen a programnak nincs kontrollja. Ha nem így működne, akkor beleütköznél ezekbe az anomáliákba.
Jaj azt ne úgy képzeld el, hogy minden négyszer van benne. Ha a bracnhing úgyis elfedi a feltöltést, akkor felesleges többször belerakni a memóriába az adatot. Ha nem fedi el, akkor mehet.
Szép lenne, ha az NV-re vérmókusokat küldenének, csak mert az ilyen trükkökkel nagyobb tempót ad.HUB!
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
-
válasz
namaste
#15310
üzenetére
Beszélünk valamiról, de nem tudjuk honnan indultunk és azt sem tudjuk igaz-e.
Ez egy nagyon hangzatos semmitmondás
Azt tudjuk, hogy honnan indultunk, ezek az információk a 970-gate kapcsán keringtek, de nagyon gyorsan helyettesítésre kerültek ezzel. Azt valóban nem tudjuk, hogy igaz-e a felvetés, meg azt sem, hogy a helyettesítő hivatalos verzió igaz-e. De miután most írom le harmadszor, hogy nem látom sok jelentőségét, hogy igaz-e, kissé feleslegesnek érzem ezen lovagolni.Keresztirányról és egyenes irányról én nem beszéltem. Nekem az van az emlékeimben, hogy mindegyik GPC-hez van kijelölve egy preferred memory controller, amihez 128-bites kapcsolat van, a többihez meg 64-bites. Ez a GM204-ben 1 "széles" és 3 "keskeny" kapcsolatról szólt, míg a többi GPU-ról nem volt szó - a GM107 és GM206 két MC-vel bír, ezért ott sok variációs lehetőség nincs, míg a GM200-ban a 6 MC miatt lehet 1-5 és 2-4 is a felállás. Persze, csak ha az egész igaz...
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
Abu85
HÁZIGAZDA
válasz
namaste
#15312
üzenetére
De most emlékeztetőül arról beszélünk, hogy az NV a DX11-hez tartozó kernel driverben alkalmaz egy speciális memóriavezérlést, amivel sebességet nyernek annak az árán, hogy több VRAM-ot használnak. Ez alapvetően egy jó dolog, mert több lesz tőle az fps. Még ha marginálisan is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
válasz
namaste
#15315
üzenetére
Abból az ábrából még az sem derül ki, hogy ténylegesen crossbarról van szó, ennyi erővel akár switching hub is lehetne. ... ja nem, biztos crossbar, hiszen rá is van írva
Az nyilván jogos, hogy mindenfajta írásos nyom híján kételkedsz. Én azért vagyok hajlamos elhinni a felezős sztorit, mert látok benne logikát.
Amúgy az a gyanúm (de ez tényleg puszta spekuláció), hogy amikor kibukott a memória-sebesség anomália, akkor volt egy kis pánik nVidiáéknál, és mielőtt a hivatalos magyarázat elkészült, azelőtt próbálkoztak olyan verziókkal, amiben nem kellett beismerni, hogy hazudtak a ROP-ok mennyiségével kapcsolatban. Aztán amikor vettek egy nagy levegőt, és megírták, hogy "tévedés" történt, akkor minden egyéb verziót kivontak a forgalomból.Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
válasz
namaste
#19061
üzenetére
A GP100 az más tészta, HPC, ott az SMP-k 128 kB regiszterterülettel dolgoznak, nem 64-gyel, mint az 10xx szériánál.
A Keplernél az ütemezés egy jó részét átvitték driverbe, ez a butítás. Persze ez a fogyasztásnak kedvező. Maxwellnél is úgy emlékszem, mintha lett volna ilyen, de csak kis mértékben, a Keplerhez képest.
Számokat nézve jobb a REG:ALU a Maxwellnél, de azt ne felejtsük el hogy az alacsony fogyasztás miatt kellett egy trükk. Az SMM-en belül az ALU-k négy blokkra vannak bontva, amivel rengeteg tranzisztort (fogyasztást) lehetett spórolni, s ez a mostani játékoknak fekszik is, de ennek megvannak a hátrányai is. Pl az 96 kB LDS miatt egyszerre csak 3 blokk használható ki.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
válasz
namaste
#19082
üzenetére
Nem. Effektíve visszafejlődött, a statikus ütemezés felé, pl a shaderfordítást a driver végzi. A Maxwellnél a trükközés nem pejoratív jelző, hisz igen jó eredményeket értek el vele, de ebben a kategóriában GPU-knál az ultramobil jellegű felépítés nem túl szerencsés. Beáldozták a tudást a teljesítmény / fogyasztásért cserébe. Ez nem optimalizáció, hanem kompromisszum.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
válasz
namaste
#19116
üzenetére
Mert régebben működtek így az architektúrák. Azt meg nem mondtam, hogy full statikus ütemezése lenne.
Nem az alacsony fogyasztásból következik, hogy ultramobil, ne adj a számba olyat, amit nem mondtam. Csak hasonló módon van tervezve, s persze nem vétlenül, hisz az NV ide is fejleszt, egy architektúrával fednek le több piacot. Nemrég jött a Pascal, az ütemező végre fejlődött, a P100-on pedig már feleannyi ALU jut ugyanannyi regiszterre egy SM-ben, pontosan azért, hogy javítsanak a compute hatékonyságon. Az NV jól láthatóan reagál a problémákra.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
válasz
namaste
#19132
üzenetére
Persze, effektíve jobb, csak fura megoldás, főleg, hogy a Pascalban újra felokosították.
Nem ultramobil, csak azt mondom, hogy abba irányba ment el. A szerver a Maxwellnél nem mindenben nyerő, lásd DP, amire valamiért inkább a Keplert használták.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
-
Abu85
HÁZIGAZDA
válasz
namaste
#21240
üzenetére
Csak úgy tudják kicserélni a shadereket, ha ki tudják ütni azt a DRM-et, amin keresztül működik. Ezáltal a rendszer képes ebbe az izolált környezetbe betölteni egy külső shadert. Más formában a GameWorks runtime nem tölt be D3BC-t.
A GameWorks működése egyszerű. Maga a fejlesztő nem szállít direkten GameWorks shadert, azt egy zárt rendszer hordozza, amit az NV odaad. Azt kell beépíteni a programba. Ilyen formában lehet biztosítani azt, hogy a fejlesztő ne módosíthassa a forráskódot, és ne töltsön be egy alternatív D3BC-t a szállított helyett. Volt már ilyenre példa az AC Unity esetén. Ott az Ubisoft írt egy alternatív D3BC-t a Geometry FX-re, de annak a működését a végső GameWorks DRM megakadályozta. Ezért Geometry FX nélkül jelent meg a játék, annak ellenére, hogy agyon volt reklámozva tesszellált felületekkel, amiből végül egy deka tesszellálás nem lett. Pedig a shader az első verzióban ott volt a játékban, csak a GameWorks DRM miatt nem töltődött be. Aztán a későbbi patch-ekkel eltávolították, mert nem jutott megegyezésre az NV és az Ubisoft.
Az AMD számára a DRM feltörése azért fontos, hogy be tudjanak juttatni ebbe a zárt környezetbe egy kicserélt D3BC shadert. Ugyanezt csinálja egyébként az NV is, csak nekik egyszerűbb a saját rendszerüket kijátszani, mert ők írták a DRM-et. Azért sem szólnak igazán az AMD törései ellen, mert ők is tudják, hogy erre szükség van, hogy a GameWorks egyáltalán működjön. Meg eleve a DRM-et a fejlesztők optimalizálásai ellen tervezték, és nem a gyártóik ellen. A gyártó még a D3BC után is tud módosításokat végezni, csak jóval nehézkesebben, de ha kell, akkor akár minden játékra állítanak egy csapatot és megcsinálják. A fejlesztőnek a D3BC shader cseréje az egyetlen lehetőség arra, hogy gyorsabb kódot futtassanak, de a DRM ezt megakadályozza. Ahhoz tehát, hogy a fejlesztői akarat érvényesüljön az adott shadert az NV-hez kell elküldeni mondva, hogy ezt akarják futtatni, és az NV vagy beépíti, vagy ajtót mutatnak.
A shadert nagyon egyszerű megszerezni. Az még a fejlesztőknek sem okoz igazából fejtörést. Cserélni problémás.
Manapság a shaderek cseréje egyre ritkább. Ennek a fő oka az, hogy sokkal egyszerűbb a fejlesztőkhöz odamenni még a megjelenés előtt pár héttel és mondani nekik, hogy ez a shader nem az igazi. Adni helyette egy jobb shadert és azt építik be. Ez nem csak hatékonyabb fejlesztés a teljes iparág számára, hanem megakadályozza azt is, hogy hetekkel a játék kiadás után kelljen a megírt és letesztelt új shadert biztosítani a meghajtóban. Persze ez ma sem akadály, de ma már az új meghajtók nem hoznak +30-40%-ot, hanem leginkább 4-10%-ot, mert ma már nem igazán nyerő nagyon rossz hatékonyságú shadert szállítani. A legtöbb stúdiónak ma már egy zárt csatornája is van, ahonnan a forrást a gyártók elérhetik, és tehetnek javaslatokat a jobb teljesítmény kinyerése érdekében. Ez sokkal hatékonyabban működik, mint a régi modell.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#24195
üzenetére
Semmi köze a számítási teljesítménynek ehhez, hiszen a DX11 ugyanazokat a shadereket használja, amiket a DX12. Ahol ez számítani fog az.a Shader model 6.0, és az ebben érkező DXIL
A skalár egység nem lenne lényeges, ha a Microsoft nem erre építette volna fel a DX12 bekötésig modelljét. De mivel ez az API már támogatja azt, ha egy erőforrás direkten a multiprocesszorba kerül bekötésre, így az előny annyi, hogy semmilyen bekötés nem jár processzorterheléssel. Ezért ment el az Intel is öszvér megoldás felé, mert számít az, hogy a processzoridő 15-20% ezáltal felszabadul.
A Microsoft nem írja elő, hogy miképp kell használni az RS-t. A fejlesztőknek ajánlásokat tesznek elsősorban a fejlesztők érdekében.
Félreérted, az NV támogat mindent, ami kell a base funkcionalitáshoz. Az RS-nek magának vannak limitációi, ha egy buffer view direkten van kapcsolva, vagy egy leíróra mutató pointeren keresztül. Ez teljesen hardverfüggetlen, magában az API-ban van limitálva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#24208
üzenetére
Bocs, de ez megint nem ilyen egyszerű. A TFLOPS és a blending teljesítmény igazából csak architektúrán belül lényeges. Elsődlegesen azért, mert az AMD és az NV ma már eléggé hibrid architektúrákat tervez. Nem igazán IMR-ek, de nem is igazán TBR-ek. Valahol a kettő között vannak, de az gyártótól függ, hogy mennyire húznak az egyik irány felé. Az NV a Maxwell óta inkább a TBR felé húz, ami miatt jóval aktívabban használnak mozaikos optimalizálást, mint az inkább IMR felé húzó AMD GCN. Ennek a hátránya, hogy jóval nagyobb blending teljesítményt igényel, viszont kisebb terhelés a memória-sávszélesség felé. Az AMD ennek pont az ellentéte. Nem igényel nagy blending teljesítményt, de nagyon igényli a memória-sávszélességet. Tehát már az eltérő architektúrák miatt is lényegtelen a direkt ROP és sávszél összehasonlítása, mert az NV-nek sok ROP kell, de kevés sávszél, míg az AMD-nek kevés ROP, de sok sávszél. Persze ezt relatív összehasonlításban kell érteni. A TFLOPS pedig azért erősen elméleti, mert a DX12 alatt is D3BC-n keresztül működnek a rendszerek, amely IR-t a 2000-es évek elején befutott architektúrákra húztak fel. Ma már egyáltalán nem úgy működnek a hardverek, hogy a D3BC jól mappelhető legyen rájuk. Ezért hoz a Microsoft a shader model 6.0-ban egy új IR-t, ami a DXIL. Microsofttól elszakadva ugyanezért hozott a Khronos is egy SPIR-V-t. Szóval az elméleti TFLOPS az tök jó, de nincs olyan PC-s hardver, ami nem SIMT modellt használna és ezáltal ne függene a teljesítmény a regiszterhasználattól, hiszen minél erősebb terhelés éri a regisztereket, annál kevesebb wavefront-warp/akármiwave futhat párhuzamosan, és annál rosszabb lesz a rendszer kihasználása. Ugye erre reakció részben a GCN4 utasítás-előbetöltése. A DXIL-en és a shader model 6.0-n már lehet látni, hogy a SIMT modell felé lépdel, hiszen mindegyik hardver ilyen már. Ettől nőni fog a hardver kihasználhatósága is, mindegyik hardveré.
A DirectX 12 több szintre bontja a bekötési rendszer. Van a TIER_3, aminél az erőforrás direkten a multiprocesszorba kerül bekötésre. Ez az alapvető modell, és ennek vannak butított szintjei. A TIER_2 szint a mintavételezőbe engedi bekötni az erőforrást, és driverrutinra van szükség ahhoz, hogy az onnan átkerüljön a multiprocesszorra. Na most ez a driverrutin processzoridőt igényel. A TIER_1 szint esetében maga a bekötés úgy zajlik, hogy a host processzor végzi a teljes munkafolyamatot, és köti be az erőforrást a multiprocesszorba.
Abból egyébként nincs semmi gond, hogy minden cég hardvere ideálisan működik a maga módján, és ha nem lenne az API, akkor ezek abszolút tökéletesek lennének, de az API létezik, és ebben vannak bizonyos szabályok, amelyeket követni kell az adott implementációnak. Szóval az NV-nek azért van szüksége arra a processzoridőt használó driverrutinra, mert abban a fránya DX12 API-ban megkövetelte a Microsoft, ugyanis a pure bindless modellre építették fel a bekötést, és a rosszabb modelleket ehhez igazították hozzá, ami áldozatokkal járt, hogy ez a három szint egyáltalán kompatibilis legyen egymással. Ez teljes mértékben egy szoftveres döntés volt, gondolva arra, hogy a DX12 itt lesz 2020-ban is, amikor már minden hardver pure bindless lesz. De egyébként dönthettek volna úgy is, hogy a DX12 bekötési modelljét arra húzzák fel, hogy elég a mintavételezőbe bekötni az erőforrást, és akkor az az NV-nek lett volna jó, de a jövő szempontjából nem ez tűnt a legjobb döntésnek.Persze, hogy nincsenek kötelező szabályok. Az MS csak azért ajánlja, amit ajánl, mert így működik az API gyorsan. Lásd Rise of the Tomb Raider, ahol nem követték az MS ajánlásait. Azóta mindenki ezeket követi, mert látványosan nem működik akkor a DX12, ha kifejezetten nem ajánlott RS modellt követnek a fejlesztők. Függetlenül attól, hogy az NV ajánlja ezt vagy nem.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#24325
üzenetére
Nagyon is jellemző a TBR rendszerekre, hogy több ROP-ot igényelnek. Bár az NV-é nem tipikus TBR, de alkalmaz egy olyan optimalizálást a Maxwell óta, amivel a sok pixelt lefedő háromszögekre vonatkozóan nem engedi kiírni a részleges pixeladatokat a memóriába. Ezzel sávszélt spórol meg, és a hardver belül tárol sokezer nagy háromszögre vonatkozó adatot. Ezért van a nagy L2 cache. Viszont azt el kell dönteni, hogy melyik háromszög részleges pixeladatai maradnak belül és mi kerül kiírásra. Ezt a ROP ellenőrzi minden háromszögre még a valós munka előtt. Ez egy ballansz döntés az NV ROP teljesítményt áldoz a sávszél spórolásért. Ilyen formában legalább 40-50%-kal több ROP kell, de 30-40% sávszél spórolható.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#29701
üzenetére
A skalár egység alapvetően hozzájárul a hardver vezérléséhez, hiszen számos fixfunkciós egységek kivált, amellett persze, hogy felkínálja a programozhatóságot, így optimálisan rámappelhető a hardver rengeteg API-ra. Gyakorlatilag teljesen mindegy az API által használt bekötési modell, a GCN-en csak le kell programozni és működik. Más hardveren esetleg emulációhoz kell nyúlni. Szerinted az Apple miért nem tért még vissza NV-re? Nem igazán tudják hatékonyan rámappelni a Metal 2-t.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#29705
üzenetére
Megfelelt akkor, amikor még nem próbálták ki. Azóta már nem az eredeti implementációt használják, hanem átálltak emulációra. Ezzel ugyan sebességet vesztenek, de sokkal jobban tudnak igazodni a készülő motorokhoz. Valószínűleg ezt ők a laborjaikban már látják, hiszen számos ilyen játék készül őszre és télre. Tehát a pro-kontra érveket átnézve úgy gondolták, hogy az emulációval jobban járnak, még a sebességcsökkenés ellenére is.
Leginkább abból, hogy a Kaby Lake-G-hez az Intel is az AMD-t választotta. Holott választhatott volna NV-t is.
(#29706) Oliverda: Sokat a TB3-mal nem érnek el. Az Apple kemény nulla devkitet szállított GeForce-szal. Akkor érne ez valamit, ha legalább egy dizájnba visszakerülnének.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#29708
üzenetére
Hogyne sikerülne. Meg is oldják, csak nem mindegy, hogy milyen hatékonyan.
Nem csak nekik készül, de valószínűleg megkérdezték őket, hogy mit látnának szívesen. A véleményük minden bizonnyal komoly szempont volt.
(#29709) Oliverda: Mert vissza akarnak kerülni. Az pedig csak úgy megy, ha megmutatják, hogy tudnak legalább annyit, mint az AMD. Ha vakargatnák a tökeiket, akkor soha többet nem választaná őket az Apple.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30350
üzenetére
A mai gyári meghajtókban mindben van többszálú optimalizáció. Nem a gyártóknál keresendő a kihasználás hiányának problémája. Ebből még az explicit API előtt tartott egy elődadást Repi. Ő mondta, hogy elméletben nagyszerű az egész, de a gyakorlatban nem működik. A driver elveszi az erőforrást a programtól, kritikus szituációkban lassít, még akkor is, ha enyhébb terhelés mellett gyorsabb, stb. És persze a gyártók implementációja eltérő.
Aki többszálú rendert ír ma az eleve nem választ már DX11-et és OpenGL-t, mert a Vulkan és a DX12 sokkal hatékonyabb megoldást kínál a problémára.
A cégek próbálkoznak sokfelé. Az AMD és az NV is. Csak az AMD úgy gondolta, hogy a DX11 után kialakult egy olyan fejlesztői támogatás, amit ki tudnának használni arra, hogy behozzák PC-re az explicit API-kat. Az NV valószínűleg átgondolta ezt is, csak ők azt hitték, hogy még ha csinálnak is egy új explicit API-t, akkor sem tudnák átverni az akaratukat a Microsofton. Az AMD csak kockáztatott, és bejött nekik. Gondolom maguk lepődtek meg rajta a leginkább.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30391
üzenetére
Itt elég jól elmagyarázzák, hogy nem olyan egyszerű ez, hogy marad idő a CPU drivernek. [link]
Bizonyos sűrűn használt dolgokra az NV egy speciális fast path-ot használ. Ennek az előnye, hogy az általános path-nál gyorsabban oldja meg ugyanazt a munkát. Az NV például régebben mondta egy prezentáción, hogy viszonylag sokat nyernek a konstans pufferre vonatkozó fast path-jukon, amelyet DX11-ben nagyon sokan használnak, de DX12-ben ez nem létező opció. Az OS nem ismeri, hogy van egy ilyen lehetőség a hardverben így nem is használja. Emiatt a DX11->DX12 váltásnál már csak emiatt is sebességet vesztenek, mert lassabban érik el a konstans puffert. Ez a DX12 egyik nagy újítása, hogy a Microsoft betervezte azt, hogy minden pufferelérés ugyanolyan gyorsnak kell lennie. Ez nem hangzik rosszul önmagában, csak ez sok hardvernél azt jelenti, hogy a DX11-hez képest bizonyos pufferelérések lassulnak. Az apró betűs rész ugye.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30457
üzenetére
Nem az a lényeg, hanem az, hogy az a zöld paca egy kihasználhatatlan CPU idő. Láthattad, hogy ahogy átléptek deferred contextre egy picit javult a sebességük (azt is elmondták, hogy sokan veszítenek egy ilyen lépéstől), de még mindig használhatatlan volt a CPU jelentős része. Amint pedig átléptek explicit API-ra elkezdett a programjuk működni. Magát a gondolatmenetet a demós rész után folytatják itt. [link]
Nem az számít, hogy van-e dedikált cache a hardverben. Az NV korábban többször hangsúlyozta az előadásain (főleg a gyorsabb DX12-es meghajtót bemutatón), hogy óriási különbség van aközött, hogy a hardver mire képes és az API mit enged meg. Például a D3D12-nek a kötött implementációja nem engedi meg, hogy egy compute shader közvetlenül a konstans pufferbe írjon, ezért a fejlesztőknek erre strukturált puffert kell használni. Ugyanakkor a GeForce-on csak a konstans pufferre van fast path, míg egy strukturált pufferre nem, tehát ennek az írása és olvasása lassabb. Például a Hitmanre van egy külön kidolgozott meghajtórutin a 384.76-os drivertől kezdve, amely a strukturált puffer tartalmát mindig átmásolja egy fast pathot lehetővé tevő pufferbe, és azzal dolgozik a hardver (persze ezt csak a Hitmanre tudják használni, mert feltételei vannak ennek meghajtó oldali trükknek, de ennél a játéknál tényleg használ). Ezzel egyébként az a gond, hogy egy ilyen optimalizálást akkor lehet használni, ha a játékot alapját képző leképezőt már nem fogják frissíteni, illetve a kidolgozása is hónapokat vett igénybe. Az NV is mondta, hogy kockázatos a módszer, mert ha jön egy leképezőbe nyúló patch, akkor onnantól kezdve lőttek a Hitman futtatásának, amíg nem veszik ki a meghajtóból a gyorsulást biztosító trükköt.
Az tök jó, hogy van driver csak az a baj, hogy a Microsoft az implementáció egy kis részét maga oldja meg. Egyfajta univerzális meghajtót ír, és azt kell használnia mindenkinek. Igazából nem sok indoka van annak sem, hogy a compute shader közvetlenül ne írhasson a konstans pufferbe. Ez a limitáció a Qualcomm és az ARM miatt lett meghúzva, de az Intel, az NV és az AMD is támogatná ezt a lehetőséget, ha meglenne. Viszont így, hogy nincs meg, azok a hardverek hátrányt szenvednek a DX11-hez képest, amelyek meghajtója kifejezetten épített arra, hogy a hardver gyorsabban tud olvasni a konstans pufferből, mint egy strukturáltból. A GCN-nek és az Intel cuccainak ez amúgy nem számít, mindegyik pufferből ugyanolyan gyorsan olvasnak.
Az NV-nek egyébként a vertex fetch-re és a statikus bindingre van még fast path-ja. Előbbi nem számít, mert a hiánya elég kevés veszteséget okoz, míg utóbbi még nem számít, mert a hiányát akkor fogja megérezni a hardver, amikor bindless bekötést használ a program.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30552
üzenetére
Egyszerű, csak meg kell hallgatni, amit mondanak. A kernel meghajtó server szálai rengeteg stallt eredményeznek, ami a processzoridő jelentős részét kihasználhatatlanná teszi. Látható, hogy deferred context mellett több aktív szerver szál van, és bár ez az Oxide esetében picit pozitív változást eredményez, azt is elmondták, hogy többen negatív változást tapasztaltak. Emiatt hibás a deferred context koncepciója. Ahogy átváltottak explicit API-ra hirtelen elkezdett az egész skálázni.
Mindenki fejlesztett többszálú drivert, és ezeket használják is. Amikor ezt a munkát elkezdték, akkor még nem tudták, hogy ez az egész nem sokat ér. A tapasztalat hozta meg a kijózanító pofont és erre volt reakció az explicit API-k fejlesztésének elkezdése.Nem tudom, hogy az NV meddig tárolja a korábbi press előadásait, de azt tudom, hogy mindenképpen press engedély kell hozzá, tehát ha nem vagy regisztrálva az NV-nél újságíróként, akkor nem engedik ezekhez a hozzáférést. Ezt nagyon komolyan veszik, még a PDF-eket is titkosítva nézhetem meg, benne lesz a letöltött állományban a neved és az azonosítóm, illetve online kapcsolat kell a megnyitáshoz.
Az rendben van, hogy a hardver így működik, de az NV pont ezt magyarázta, hogy nem ezt kell nézni, hanem azt, hogy az API mit enged meg.
A konstans puffer a GPU számára írható. Ugyanolyan pufferként kezeli a hardver, mint egy másikat. Az API nem engedi meg az írását, és mivel a meghajtó sem tudja ezt felülbírálni a D3D12-ben elvesztik erre a trükközést, hacsak nem csinálnak minden alkalmazásra speciális hacket, ami nyilván nem realitás. Eddig csak a Hitmanre vállalták be, mert az nagyon rosszul futott.Ahogy a strukturált puffer is cache-elt a GCN-en, tehát mindegy, hogy egy puffer konstans vagy strukturált. Az elérése ugyanolyan gyors. A GeForce-oknak ez nem mindegy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#30578
üzenetére
Ugyanez volt Windowson a DX11 és OpenGL alatt is. Teljesen kiszámíthatatlan a viselkedése. Hiába fejlesztik, ezen a gyártók átmentek és ugyanezt tapasztaltál. Hol javít, hol nem.
Írtam, hogy az NV trükközik, csak játékra építenek profilt rá. A Hitman csak ezért gyorsult. De mindegyik játékra ezt megcsinálni nem túl célszerű, mert sok erőforrást visz el, és meg kell várni azt a kódot, amikor a játék már nem változik. Ezt konkrétan elmondták a nyáron. Emiatt inkább a hardveren fognak változtatni ... utalás a Voltára? Lehet. Elképzelhető, hogy a Volta már ugyanolyan gyorsan fogja kezelni a konstans és a strukturált puffereket. Ez logikus előrelépés lenne elvégre a GCN és az Intel Gen9 is így működik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
válasz
namaste
#33791
üzenetére
"Ha már vs, az AMD csinálja jól, nem számozza a GPU-kat, hanem neveket ad és 1. vonalbeli GPU-t küld a 3. vonalbeli ellen."
Szerintem kifejezetten korrekt dolog az NV-tól, hogy nem sumákolják el a GPU-k belső kódneveit, így a hozzáértő vásárlók pontosan tudhatják, hogy mit vesznek.
Abu85: "A HBM-mel egyébként az a problémája az NV-nek, hogy kevés memória építhető a GPU mellé."
A Quadro GV100 -on lévő 32GB HBM2 kevés?
SZVSZ játékra 8GB VRAM bőségesen elég lesz a következő konzolgenerációik (~2020), vagy akár tovább is. Attól függ mennyi RAMot kapnak az új konzolok.
A HBM-el az a gond, hogy nagyon megdrágítja a játékos kártyákat, miközben minimálisak az előnyei.
[ Szerkesztve ]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Azt tudjuk, hogy honnan indultunk, ezek az információk a 970-gate kapcsán keringtek, de nagyon gyorsan helyettesítésre kerültek 
)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Lenovo ideapad C340 / i3-10110U / 8 GB / 1 TB SSD / FullHD érintőkijelző
- RAZER BlackWidow V4
- Eladó/cserélhető iPad Pro (2018) 11", 64 GB, WiFi, Space Gray, 94% BH + tok
- Dell UltraSharp U2415b, AH-IPS, 100% sRGB, FHD+, pivot talp, számla +garancia 1 év
- Acer Predator Helios 500 - 17"- GTX 1070 - Gamer
- Samsung 27" S27F350FHU monitor
- Korg nanoKontrol2
- Lenovo Thinkpad E14 Gen 2 Ryzen 7 PRO 4700U/16GB RAM/512GB NVME SSD/14" FULL HD garanciás laptop ela
- Félkonfig Asus B250M-Plus alaplap, i7-6700 proci,Crucial 2x8GB 2400Mhz memória, gyári hűtő eladó.
- I7-es Acer számítógép! I7-2600, 8GB, 128GB SSD, 1TB HDD, GTX650 VGA
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen