Új hozzászólás Aktív témák
-
#88750080
törölt tag
Egyrészt:
, másrészt mi az, hogy "dolgozni" kellett rajta, gyakorlatilag csak egy koppincsról van már megint szó, harmadrészt "az összes fontosabb gyártó" már implementálta ezt a DX12-es driverében, szóval még inkább csak egy koppincsrólátemelésről van szó.Gratulálok a kemény munkához.
Még egy extensiön deszktopon csak azért, hogy a dxvk12d3d valamivel hatékonyabban működjön a steamdekken. -
#8
#88750080
törölt tag
fatpingvin
#2
#88750080
törölt tag
válasz
fatpingvin
#2
üzenetére
Mert fejlesztőstúdióként kapsz hozzá supportot a MS-tól, van hozzá egy csomó doksi és fejlesztői cucc, a nyílt API-kat meg valami nyomi kis "bizottság" "fejlesztgeti", másrészt nem fednél le vele többet, mint a dx-szel, sőt, ha a konzolokat is a képbe vesszük, akkor még kevesebbet is.
A Vulkanhoz még fordító sem volt, amikor kijött a szabvány, a MS meg már akkor adott egyet, amikor a "nyílt API" még ott tartott, hogy dobjuk be a drivernek a source-ot mint stringet, azt' majd kezd vele, amit akar.
Amúgy is látszik, hogy a nyílt API mindent is le akar fedni, de pont ettől xar. Aki sokat markol, keveset fog.
Az Apple se véletlenül döntött úgy, hogy saját API-t akar, és nem kínlódik tovább a nyílttal.
Szóval inkább én kérdezem, miért kell ezeket a nyílt hülyeségeket erőltetni? -
#13
#88750080
törölt tag
fatpingvin
#12
#88750080
törölt tag
válasz
fatpingvin
#12
üzenetére
Igen, bajnak tartom, példának ott az OGL. Egy rakás szerencsétlenkedés az egész, ami a mindent is lefedni akarásából és a khronos impotenciájából fakad, a Vulkan is láthatóan efelé halad, ráadásul az utált proprietary API-k a nyílt hülyeségekkel szemben nemcsak gamingre meg CAD-re használatosak, hanem az OS szerves részei, pl. a Windowson a DWM is azzal rakja össze magát a deszktopot. Elég hülyén is nézne ki, ha pl. MS-nak valami bizottságra kellene várnia és a kegyeire bíznia magát, hogy olyan dolgokat rakjon az API-ba, amivel ők az alacsonyszintű problémáikat meg tudják oldani (pl. videómemóriában GPU-k között megosztott textúrák, ez fontos, ha a monitoraidat több különböző GPU hajtja, de ez csak egy példa). És ha meg is tennék, akkor az kb. egy bloat formájában jönne, pl. "VK_MS_*" extensiönökkel.
Az Apple valószínűleg ugyanígy volt a Metallal.Amúgy igen, nekem az is tök ellenszenves úgy általában véve is, hogy jön valami csoport meg a hívei, és kijelentik, hogy az iparág minden szereplője dobja el a kalapácsot, mert ők kitalálták az egyetlen igaz útra vezető megoldást, és azt kell használni. Persze csak azért, hogy egyfajta ideológiai alapon a saját open platformjukat is be tudják valahogy tuszkolni a képbe.
[ Szerkesztve ]
-
#88750080
törölt tag
Igen, tudok róla, de játékfejlesztő stúdióként akkor is megmarad a két alapvető tény:
- Egy propietary API-hoz sokkal nagyobb valószínűséggel és gyorsasággal kapsz supportot a gazdájától, ha valami probléma merül fel, mint egy open senkiföldjéről vagy egy bizottságtól, aki csak az interfészt definiálta.
- Vulkannal pluszban legfeljebb csak a linuxot mint platformot feded le, az XBox-ot már nem, és ez utóbbi egyelőre legalábbis sokkal nagyobb piac.
[ Szerkesztve ]
-
#25
#88750080
törölt tag
bitblueduck
#16
#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.
-
#26
#88750080
törölt tag
fatpingvin
#17
#88750080
törölt tag
válasz
fatpingvin
#17
üzenetére
Igen, hallottam róla. És bátorkodom tájékozottnak tűnni, ugyanis elég régóta foglalkozom a témakörrel.
Most akkor mit csinál a MS az API-jával? Ráerőlteti a világra, vagy tyúkanyó módjára ül rajta?
Azt a felfogást egyébként egyszerűen képtelen vagyok megérteni, hogy egy cég a saját fejlesztését kötelező bedobni a közösbe, hogy más platformon (értsd: konkurrencia) is meg lehessen implementálni. Miért tenné? Hol itt a verseny?
(Ha meg véletlenül megteszi, akkor az a baj, mert az "egész világnak azt a szart" kell használnia. )
Pont úgy nem értem, mint az open source-ot, ahol analógiával élve a sok alkoholista fogyasztóként magasztalja az ingyensör intézményét, a sörfőzők meg ingyen dolgoznak.Minden értelmes cég védi a saját fejlesztését, az Apple különösen. Ott ha valaki elkezdené Wine módjára koppincsolni a cuccukat valami hippi ideológia nevében, azt szerintem még csírájában lekapcsoltatnák.
Na, mindegy, nagyon elkalandoztam már. -
#88750080
törölt tag
válasz
#88750080
#26
üzenetére
Ezt a #15-re akartam válaszolni.
Jut eszembe, ha már felhoztad, hogy HLSL-t lehet SPIR-V-re fordítani... ez is azért van, mert ahogy mondtam, a Vulkan megjelenésekor nem volt egy épkézláb fordító. A Khronos specifikálta a bájtkódot, csak nem lehetett miről arra fordítani. Ezért szétnézett az iparágban, és már nem is emlékszem, melyik céggel csináltatott egyet, ami GLSL-ről tudott a bájtkódjukra nem túl optimálisan fordítani. Vagy generáltad kézzel a kódot, vagy volt egy egyszál glslang.exe.
A MS ezt az űrt töltötte be a saját új fordítójával, márcsak azért is, hogy a HLSL nehogy (hirtelen) teret veszítsen egy másik fordító kárára, ha esetleg előáll egy ilyennel valaki.
, másrészt mi az, hogy "dolgozni" kellett rajta, gyakorlatilag csak egy koppincsról van már megint szó, harmadrészt "az összes fontosabb gyártó" már implementálta ezt a DX12-es driverében, szóval még inkább csak egy 
Új hozzászólás Aktív témák
ph A friss kiterjesztéssel közelít a DirectX 12 működéséhez a Khronos Group API-ja.
- Autós topik
- Győr és környéke adok-veszek-beszélgetek
- Yettel topik
- Motorola Moto G24 Power - hol van az erő?
- Vodafone mobilszolgáltatások
- Kerékpárosok, bringások ide!
- bitpork: Fogyasztásra ítélve
- A fociról könnyedén, egy baráti társaságban
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Melyik tápegységet vegyem?
- További aktív témák...