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

• #25 #88750080 törölt tag bitblueduck #16

  Új Válasz 2022-11-23 22:08:24 #25

  Ú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

  

  #88750080

  törölt tag

  válasz bitblueduck #16 üzenetére

  Így van, igen, a minden platform hülyeségét lefedni akaró hülye kiterjesztésektől.

  A DX9-ig DX fronton is megvolt a kismillió cap bit, amit értelmes programozó nem vizsgált meg egyenként és írt 2^32-féle code path-t, legfeljebb párat, és inkább megcélzott egy ismert minimum hw-szintet, arra lőtte be kódot ("milyen kártya kell hozzá").
  DX10-től kezdve a MS kidobta a francba ezt a koncepiót, és az egyes cap-eket feature-levelekké vagy tier-ekké fogta össze, elég ennyit megcéloznia a programnak. DX12-től ismét kezdenek megjelenni a mindenféle cap-bitek (bár nem így nevezik őket), pl. olyanokra, hogy támogatott-e stencilérték kibocsátása pixel shaderből (NV nem támogatja), lehet-e depth buffert parciálisan másolni, stb. Ennek konkrétan nem örülök.

  De amikor pl. OpenGL-ben az 5millió kiterjesztéshez egy külön extensiön managert kell használni, attól én már majd' tökön szúrom magam. Ugyanis ott egy extensiön megléte azt jelentette, hogy az adott nevű függvény fizikailag létezik-e a OGL dll-ből kiexportálva vagy nem. A Vulkan mitől más ebben a tekintetben? A DX legalább lightweight COM, ott új metódusokhoz (gyártói bővítmények szabványosítása) hozzáadnak egy új interfészt a meglevők mellé, amit le tudsz kérdezni, emezek meg sima C-s interfészek, ki fejleszt manapság ilyen API-t?

  Az AGS-es dologról:
  Hát igen, ez a "one API" koncepció, ami azt jelenti, hogy ami egyszer bekerült az API-ba, az örökre ott marad. Így lehet az pl., hogy a 100 éves glBegin/glEnd együtt létezik pl. a mesh shaderekkel az OGL-ben. Nem tudom, van-e valami a specifikációban arról, hogyan hatnak ezek egymásra, de nem szívesen írnék hozzá drivert. Vagy hogy hogyan implementálják egy modern driverben a vonalvastagságot meg a kör alakú point sprite-ot, biztos kellemes lehet...
  
  Az összes többi API-kreátornak volt legalább annyi esze, hogy az API nagy ugrást vagy paradigmaváltást hordozó verzióit legalább fizikailag elszeparálja a régitől. A 3Dfx pl. új dll-ekben szállította, a MS meg új COM-objektekkel.
  
  Ami a RenderDoc-ot illeti, én is szoktam használni, és nem rossz. Van benne pár dolog, ami más debuggerekhez képest tök király, más meg nem. Az is egy DX11 debuggernek indult, aztán később jött támogatás más APIkhoz is, de itt kb. annyi az újdonság, hogy egyáltalán van valami debugger Vulkanhoz, és azért a legjobb a piacon, mert más komolyan vehető debugger nincs is. Olyan ez, mint maga a Vulkan léte: azért nagyon király API pl. linuxos körökben, mert ott eddig nem volt semmi más. Csak az OGL, amit már csak manapság illendő lefikázni, korábban blaszfémia volt. Szóval, jó dolog az a RenderDoc, de pl. DX12-es capture-re nekem az 1.6-os verzió után már egyszerűen szétszáll. 64 bites DX12-re meg ott a PIX.

  Ja, ami a HLSL-t illeti, igen, a DXC tudja SPIR-V-re is fordítani. Ebben mondjuk nagy tapasztalatom nincs, de biztos vagyok benne, hogy van pár limitáció és nyűglődés vele kapcsolatban a gyakorlatban, ugyanis a HLSL olyan fogalmakat használ pl. a shader input/output signature-ök tekintetében, amik a DX logikájára építenek (pl. vertex binding egy vertex shaderbe). Elképzelhető, hogy az új, SM6-os shadereket tudja csak fordítani, mert azok már DX-re sem DXBC-re hanem DXIL bájtkódra fordulnak. Jó, hogy felhoztad, utána is nézek.

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