Hirdetés

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

  • ervinke78

    lelkes újonc

    Egyrészt: :DDD , 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.

  • fatpingvin

    senior tag

    LOGOUT blog

    válasz ervinke78 #1 üzenetére

    én inkább azt a kérdést feszegetném hogy ezt a directx nevű koloncot minek rángatja magával még mindig az ipar... régen át kellett volna már állni a teljesen nyílt API-kra...

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • dabadab

    titán

    válasz fatpingvin #2 üzenetére

    Azért, mert működik: vannak hozzá remek fejlesztőeszközök, drivertámogatás, ilyesmi.

    DRM is theft

  • fatpingvin

    senior tag

    LOGOUT blog

    válasz dabadab #3 üzenetére

    ugyanez elmondható az alternatívákról is, azzal a különbséggel hogy azokat nem csak egy szoftveres platform ismeri.

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • dabadab

    titán

    válasz fatpingvin #4 üzenetére

    Nem igazán, a DirectX kifejezetten a fejlesztői támogatás miatt tudta magát kinőni és amikor utoljára néztem, akkor a windowsos OpenGL driverek azért hagytak kívánnivalót maguk után.

    DRM is theft

  • Abu85

    HÁZIGAZDA

    válasz dabadab #3 üzenetére

    Ezek a Vulkan API-hoz is vannak.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • fatpingvin

    senior tag

    LOGOUT blog

    válasz dabadab #5 üzenetére

    NYILVÁN hagytak maguk után kívánnivalót, ki nem találnád hogy mi köze lehet ennek ahhoz hogy a dx a microsoft saját, házon belüli és jobbára exclusive megoldása, az OpenGL meg egy open standard amire ha fejlesztenek abból kb az összes platform profitálhat.

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • ervinke78

    lelkes újonc

    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?

  • Abu85

    HÁZIGAZDA

    válasz ervinke78 #8 üzenetére

    Éppenséggel a Vulkan az a nyílt API, ami zajos siker lett a Khronosnak. Rengeteg projekt épül rá, és nagyon szépen fejlődik. Van hozzá support, nagyon jó debugger, stb. Pont arra példa, hogy ezt jól is lehet csinálni, nem csak szarul, mint az OpenGL-nél.

    És az Apple eszközeire szép számmal érkeznek a Vulkan játékok a MoltenVK-n keresztül. Tehát oké, hogy van Metal API-juk, de natívan azt ritkán támogatják. Ez teljesen logikus sok fejlesztő részéről. Valamelyik más platformra úgyis van Vulkan kód, ami meg fut a MoltenVK-n, ami meg kis sebességvesztés árán fut a Metal eszközökön.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • ervinke78

    lelkes újonc

    válasz Abu85 #9 üzenetére

    Zajos siker csak linuxon lett a gaming miatt, a többi pont annyira lényeges, mint az OGL volt.

  • Abu85

    HÁZIGAZDA

    válasz ervinke78 #10 üzenetére

    Meg van számos Vulkan cím Windowsra is. Ráadásul kevesen tudják, de a mai motoroknak van Vulkan és D3D12 leképezője is. Célszerű mindkettő implementálni, mert nem különbözik annyira a két API, hogy gondot jelentsen, és a Vulkan is megeszi a HLSL shadereket, hiszen lefordíthatók SPIR-V-re. Azért nem szokott általában két API-val megjelenni egy adott játék, mert az plusz karbantartási költség, de maga a leképező minden motorban támogatva van és fejlődik. Az OpenGL-nél ilyen nem volt. Az annyira különbözött, hogy nem is implementálták.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • fatpingvin

    senior tag

    LOGOUT blog

    válasz ervinke78 #10 üzenetére

    elég vicces ahogy arra utalgatsz hogy baj lenne egy olyan API létezése és fejlesztése ami linuxon ÉS windowson is működik, mert hogy csakawin és csakadx a jó.

    amiket te próbálsz panaszként felhozni az az OpenGL-re talán valóban igazak lehettek, az ugyanis tényleg csak egy standard keretrendszer, a Vulkanra ez viszont már rég nem igaz.

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • ervinke78

    lelkes újonc

    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 ]

  • ervinke78

    lelkes újonc

    válasz Abu85 #11 üzenetére

    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 ]

  • Abu85

    HÁZIGAZDA

    válasz ervinke78 #13 üzenetére

    Mitől halad a Vulkan az OpenGL felé? A kiterjesztésektől? A DirectX 12-ben is vannak képességek, amelyek meglétét előbb ellenőrizni kell, mert nem minden DirectX 12-es hardver támogatja. Aztán erre vannak feature_level összesítések, így elég csak ezt csekkolni, amire szintén van a Vulkan API-ban verziócheck, ami bizonyos kiterjesztéseket kötelezővé tesz. De ahogy a Vulkan API-ban a legmagasabb verzió sem tartalmazza az összes kiterjesztést, úgy a DirectX 12-ben a legmagasabb feature_level sem tartalmazza a legjobb képességeket, tehát mindkét oldalon van egyedi per feature és kiterjesztés szintjén ellenőrzés. Tehát a kiterjesztések ugyanúgy megvannak a DirectX 12 oldalán is, csak feature néven.

    Az alapvető eltérés annyi, hogy a Vulkan lehetővé teszi már az API-hoz illesztve a gyártói kiterjesztéseket, míg a Microsoft esetében ehhez gyártói szervizkönyvtár kell. Például az AMD-féle AGS tele van DirectX 12 kiegészítésekkel. És ez nem jobb a Vulkan-féle gyártói kiterjesztéseknél, mert kell egy extra könyvtár használata az implementálásukhoz. Vulkan esetében elég csak a kiterjesztést meghívni, nem kell pöcsölni szervizkönyvtárakkal.

    Az más kérdés persze, hogy a fejlesztők pöcsölnek vele, sőt, az Ubisoft éppen olyan motort írt az új Snowdrop kapcsán, aminek az alapvető működésébe is beleavatkozik az AGS, tehát nem csak egy-két effekt miatt lesz benne, hanem konkrétan máshogy számol sugárkövetést, ha az AGS be van töltve. És ez nem kis költség ám a fejlesztés oldalán, mert kell egy fix AGS specifikáció az AMD részéről, hogy az jó sok évig ne változzon, ugyanis, ha módosítják az AGS runtime-ot egy friss driverben, akkor az az Ubisoftnak szar, mert nem működik tovább a motorjuk. Ez valamivel kellemesebb a Vulkan oldalán a gyártói kiterjesztésekkel, mert specifikusak ugyan, de idővel a nagy részük át lesz emelve EXT-be, onnan pedig a KHR-be. És nem szoktak jelentősen változni, így utána lehet menni a szabványosításnak egy patch-csel. Az AGS-ből viszont tudod mikor lesz átemelve valami a DirectX 12-be? Soha. Tehát az Ubisoft AGS kódja szabványosíthatatlan, azt jól át kell írni, ha a Microsoft szíveskedik azt a képességet beépíteni a szabványba, amit az Ubisoft használni fog.

    Szóval egyáltalán nem rosszabb a Vulkan a DirectX 12-nél használhatóságban és fejleszthetőségben sem. És a kiterjesztések sem teszik tönkre, mert hasonló opciók más formában a DirectX 12-höz is vannak, csak nem kiterjesztésnek hívják, hanem inkább kiegészítésnek.

    #14 ervinke78 : A Vulkan API-hoz írt fejlesztőeszközöknek is van supportja. Elég jól működő. Annyira, hogy még a DirectX 12-höz is nagyon sok stúdió RenderDoc debugot használ. Egyszerűen most ez a legjobb a piacon.

    Meg az Androidot, meg az Apple cuccokat a Metal miatt, meg bármi, ami esetleg jön, mert Vulkan mindenre lehet, DirectX viszont nem. Az Xboxhoz pedig úgyis van a motornak DirectX 12 leképezője. Ahogy fentebb írtam, manapság tipikus, hogy mindkét API-t támogatja egy motor, mert a Vulkan is meg tudja enni a HLSL shadereket a SPIR-V-n keresztül, tehát a két API nagyon hasonló működése miatt olcsó mindkettőt beépíteni. Az OpenGL-nél ez azért nem működött, mert nem ette meg a HLSL shadereket, és úgy már százezer sornyi kód módosítása lett volna a support, ami egyszerűen sok.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • bitblueduck

    senior tag

    válasz ervinke78 #13 üzenetére

    és akkor linuxon (többek közt android) pl mit használjanak, metalt vagy directx-et?

    An open mind is like a fortress with its gates unbarred and unguarded.

  • fatpingvin

    senior tag

    LOGOUT blog

    válasz ervinke78 #13 üzenetére

    nem tudom hallottál-e róla, de amilyen tájékozotnak próbálsz tűnni, elvárnám: nem csak a MS vacka létezik a világon.

    that being said, abszolúte semmi bajom nem lenne a directx-szel ha a microsoft nem őrködne felette tyúkanyó módjára hogy más platformon ne lehessen normálisan natívan implementálni mint open standard.

    persze, csinálják ha jó nekik, otthon négy fal között, és ne erőszakolják rá az iparágra a hülyeségeiket olyan módon ami elveszi a teret a nyílt, szabadon felhasználható és implementálható megoldásoktól.

    bár ezt a szempontot te láthatóan nem tudod értelmezni, szval inkább hagyjuk is. elvégre csak az üzemben lévő számítógépek nagyobb részéről beszélünk (mielőtt valami okos rákezd hogy de hát desktop: szerinted mondjuk egy GPU computing szerver mit használ?)

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • Busterftw

    addikt

    válasz fatpingvin #17 üzenetére

    Csak ugye kérdés hogy ezek a szerverek használnak-e egyáltalán DirectX-et.
    Tehát oké hogy ott Linux dominál, viszont gpu computing-nál cuda van és kész kb.

    Ez a négy falas érv is érdekes, mert jelenleg ez a megoldás az "iparági" megoldás.
    "it is the generally accepted requirements followed by the members of an industry."

    Ennek lehet örülni vagy sem, de ez van.

    [ Szerkesztve ]

  • fatpingvin

    senior tag

    LOGOUT blog

    válasz Busterftw #18 üzenetére

    miért használnának?

    amúgy GPU computing terén persze, nvidia vason a CUDA a standard, de egyrészt nem csak CUDA van, ami meg még fontosabb, nem csak nvidia. AMD-n pl a ROCm van (én is jelenleg ezt használok, igaz desktopon de lehetne szerveren is csak így egyszerűbb perpill) ami mielőtt valaki nekem esik, tisztában vagyok vele hogy nem Vulkan cucc, viszont azt is engedtessék meg kiemelni, a Vulkan nem csak grafikai hanem computing API is.

    csak hogy szakterületemnél maradjak, határozottan emlékszem rá hogy olvastam egy molekulaszerkezeti és reakciódinamikai modellező szoftverről amiről pont ez volt a nagy hír hogy OGL-ről átáll Vulkanra.

    egyébként meg ahol igazán nagy jelentősége lehet az talán pont hogy nem a desktop hanem a handheld eszközök, kezdve az Androiddal ami a mindenki által passzióból utált OpenGL-t használta kizárólagosan a 7. főverzióig.

    záró gondolatként: semmi bajom a directx-el, biztos nagyon jó cucc a saját limitációival. nekem csak azzal van bajom, amikor valaki úgy csinál mintha a dx az már így teljesen lefedett volna mindent és csak ez számítana, ami meg csak simán objektíve nem igaz. a dx egy windows exkluzív cucc, mielőtt valaki nekiáll sarkos véleményt formálni, gondoljon bele hogy hogy nézne ki a világ ha a Metal kapna ilyen "kitüntetett" figyelmet a piacon, úgy hátha érthetőbbé válik amit képviselek.

    a Vulkannal egyszerűen nincs ilyen gond, az implementálja aki akarja és olyan extensiont gyárt hozzá amilyet akar. ha beválik mehet is az upstreambe.

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • Abu85

    HÁZIGAZDA

    válasz fatpingvin #19 üzenetére

    Kiegészíteném, hogy ha egy kiterjesztés beválik, akkor nem rögtön az upstreambe megy, hanem előbb EXT-be, aztán KHR-be.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • fatpingvin

    senior tag

    LOGOUT blog

    válasz Abu85 #20 üzenetére

    ebben nem akartam belemenni, nyilván így, de ez részletkérdés.

    A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

  • Busterftw

    addikt

    válasz fatpingvin #19 üzenetére

    Ezt mondom én is, csak írtam hogy az érv a Linux elterjedésére szerver fronton itt annyira nem érvényes, tekintve hogy ott nincs nagyon DirectX használva. Amiből ugye a vita elindult, hogy melyik API miért/mennyire terjedt el.

    Tehát a fenti "mindenkire" ráerőltetik nem éppen állja meg a helyét, csupán arról van szó hogy ahol ilyen API használva van, ott a DirectX dominál.
    Én inkább úgy mondanám, hogy a DirectX egy gaming ipari szabvány, ahol meg nyilván a Windows dominál.
    (Xbox is Windows alapú)
    De például Linuxon a Proton elég jó cucc, ami meg a Vulkan translation layert használja.

    A DirectX nem csak d3d render hanem hangért es másért is felel, amit az OpenGl/Vulkan nem kínált. (nem tudom hogy azóta igen)

    Ha utánanézel akkor érthető, ugye említették a support és terjedelmes dokumentációt, mivel a Microsoft konkrét hardverben is érdekelt (Xbox) ezért nyilvánvalóan megtesz mindent hogy legyen fejlesztve ezerrel, egy már elterjedt és széles körben használt megoldásról van szó.

  • Abu85

    HÁZIGAZDA

    válasz Busterftw #22 üzenetére

    A Vulkan már nem csak egy szimpla játékokhoz használt grafikus API. Rengeteg compute projekt fut rajta, például nem kevés neural network inference keretrendszer le van rá kódolva. Ennek az az előnye, hogy nem kell ezekhez zárt futtatási környezet, mivel a Vulkan van mindenhol, csak indít és fut.

    Már nem felel sok más dologért a DirectX. A Microsoft jó ideje átgyúrta már a rendszert, így a DirectSound meg a DirectInput már nincs használatban.

    Dokumentáció és support van Vulkan API-ra is.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Busterftw

    addikt

    válasz Abu85 #23 üzenetére

    "Dokumentáció és support van Vulkan API-ra is. "
    Nyilván, csak nem annyi olyan mértékű mint a DirectX esetében.

  • ervinke78

    lelkes újonc

    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.

  • ervinke78

    lelkes újonc

    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. :DDD )
    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.

  • ervinke78

    lelkes újonc

    válasz ervinke78 #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. :D
    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.

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

Hirdetés