Ennek kicsi jelentősége van. Egyrészt látszódna a szintetikus méréseknél, amelyek direkt a driver overhead tesztelésére jók, de ott igazából nincs kardinális különbség az NVIDIA és az AMD meghajtóimplementációja között. Ahhoz, hogy ilyen mértékű eltérést mutasson egy meghajtó az egyes játékokban, legalább felezett tempó kellene az NV-től a szintetikus overhead tesztekben. De közel sem ennyivel lassabb a GeForce DirectX 12 és Vulkan drivere. Amennyivel lassabb az pedig a gyakorlatban nem okozhat pár százaléknál nagyobb deficitet.
#140 gbors : Explicit API, nem implicit. 
Elég sok problémát szülhetnek a program oldalán az olyan tényezők, hogy az NVIDIA-féle DirectX 12 Do's And Don'ts ( [link] ) esetenként konkrétan az ellentettjét ajánlja a Microsoft-féle DirectX 12 előírásoknak. A Microsoft az egész API-t egy tipikus erőforrás menedzsmentre tervezte, mégpedig arra, hogy a memóriahalmazok kerülnek a root signature-be, és a memóriahalmazokba kerülnek a pufferek és a konstansok. Az NVIDIA ezt kiemelten nem ajánlja, helyette azt mondják, hogy közvetlenül a root signature-be kerüljenek a konstansok és a konstans pufferek:
* Constants that sit directly in root can speed up pixel shaders significantly on NVIDIA hardware – specifically consider shader constants that toggle parts of uber-shaders
* CBVs that sit in the root signature can also speed up pixel shaders significantly on NVIDIA hardware
A Microsoft erre azt mondta régen, hogy ez papíron lehetséges, de egyrészt limitálja a pufferek kezelhetőségét, illetve alapvetően felboríthatja az API-hoz tervezett menedzsmentet, például a barrierek sokkal többször futhatnak nem valós függőségekbe akkor, ha egy puffer közvetlenül a root signature-ben van. Tulajdonképpen nem arra a működésre tervezték az API-t, amit az NV ajánl.
Látni kellene itt a játékok konkrét működését, de alapvető kérdés lehet az NV-nek, hogy a pixel shader teljesítmény visszaesésén buknak-e többet, vagy azon, hogy vállalnak az API-ra egy elvben megengedett, de nem optimális működést. Az NV oldaláról lehet, hogy az utóbbi a jobb, és ezt a program oldalán kell lemenedzselni. Márpedig annyira nem nagy meló csak a GeForce-okra átrakni a CBV-ket és a konstansokat a root signature-be, ha azok kezelhetősége az adott programban pont nem változik meg. Az már nagyobb meló, hogy ehhez optimalizálják a működést, és itt a barrierek tekintetében elég sok szopást kellene bevállalni, ami valószínűleg nem fér bele mindenki idejébe.
#145 gbors : Az aszinkron compute már nem akkora gond. Az azért volt baj régebben, mert elég szar hardverállapothoz volt kötve az NV-n a compute shader. Még most sem stateless, de az AC feladatok döntő része vagy compute-compute, vagy pixel-compute. Tehát az már elég jó, ha a pixel shader hardverállapotához van kötve a compute shader, és így már egy ideje. Persze, ha csinálsz valami rohadt egzotikus dolgot, mondjuk geometry shader mellett küldöd a compute shadert, akkor nem fog tetszeni a GeForce-oknak, de ez inkább teoretikus probléma, mintsem egy gyakorlatban valóban használt dolog.
A GPUOpen SPD-nek igazából nincs nagy jelentősége. Egyrészt ez egy rendkívül egyszerű eljárás, ami arányaiban elképesztően gyorsan lefut, a mai hardvereken nagyon bőven 1 ms-on belül. Másrészt a CPU-terhelésre nincs hatással. Annyi a lényege, hogy egy számítással generálja le a szükséges MIP szintet, vagyis egy csomó számolást kivág a rendszerből. Az, hogy futhat async compute-ban leginkább egy extra, de őszintén szólva egy mai combosabb hardver esetében kb. nyers az async lehetőséggel úgy 0,1 ms-ot, aminek igazán nincs jelentősége. Jójó persze, ki a kicsit nem becsüli...
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Persze, hogy explicit.
