Új hozzászólás Aktív témák
-
#24
hapakj
őstag
vérjancsika
#23
hapakj
őstag
válasz
vérjancsika
#23
üzenetére
lol. Még egy hozzánemértő rageelős komment
Btw. mintha a DX-be mindig is csupa jó ötletek lettek volna. (Khm geomety shader, meg khm a tesselation pipeline)
S tényleg a legjobb példa egy alternatív platformra egy döglött platform (Stadia)
-
#23
vérjancsika
kezdő
julius666
#22
vérjancsika
kezdő
válasz
julius666
#22
üzenetére
Igen, egyrészt megvan. Régóta mondom, hogy a windows koppincsolása mögött egy egész iparág áll. Először a dxvk-nak (dx11) nem volt elég a meglévő Vulkan feature set, most meg a vkd3d-nak (dx12).
Másrészt meg nézz bele a videóba, ott a nő elismeri, hogy amúgy de, sz@rf0sra sikerült a specifikáció. Desktop kártyákra a mobilos leggyengébb láncszemek miatt bevezett API igazából nagyrészt hulladék.
Harmadrészt ha annyira csodálatos lenne ez a Vulkan mint platform, akkor nem a windowst másolnák, hanem már rég kialakítottak volna linuxra is valami saját gaming platformot, saját SDK-val, mint ahogy a Goolag is tette a Stadia-val.
-
#22
julius666
addikt
vérjancsika
#16
julius666
addikt
válasz
vérjancsika
#16
üzenetére
Aztán amikor kiderül, hogy ez nem elég a dxvk-nak, akkor bevezetnek egy dx12-es extensiönt. Aztán most majd megint, mert a mostani megoldás még mindig nem elég, a vkd3d-nek. És minden ilyen lépésnél kiderül (a fanboyok részéről), hogy az addigi feature set tulajdonképpen mekkora xar volt.
Az ugye megvan, hogy ezek a problémák eleve a DX12 emulációt érintik?
Nem azért pakolják ezeket az extensionöket a Vulkanba, mert sz@rf0sra sikerült a specifikáció, hanem hogy a Windowsos API emulátorokkal minél inkább "súrlódásmentes" legyen a kapcsolat, minél kevesebb extra kört kelljen futni a különbségek áthidalásakor a wine/proton grafikus stackjében. Más szóval hogy a Windowsra írt játékok Linuxon minél kisebb teljesítményhátrányból induljanak. -
#21
hapakj
őstag
Nestor-xyz
#13
hapakj
őstag
válasz
Nestor-xyz
#13
üzenetére
Továbbra se látom, hogy a "PC + Linux/Windows + AMD" felállás miért lenne olcsóbb a "PC + Windows + NVIDIA" felállásnál, hogy a Vulkan kiérdemelje a szegény ember DirectX-e címet
-
Abu85
HÁZIGAZDA
Nem, a Mantle még így is nehezen implementálható Vulkan API-ra, és ezen belül is igazából csak AMD hardveren működne igazán jól. A Mantle-nek nagyon letisztult volt a bekötési modellje, ahhoz egyetlen API sem hasonlít, mert nem csak a GCN-re és RDNA-ra dolgozik a Microsoft és a Khronos. Ehhez hasonló letisztult bekötési modellt nem tudna hatékonyan kezelni más hardverdizájn.
-
#18
hapakj
őstag
vérjancsika
#16
hapakj
őstag
válasz
vérjancsika
#16
üzenetére
Nah ez már egy sokkal objektívebb meglátás
Hát aki bármelyik API körül fanboy-kodik az valszeg nagyon nem ért hozzá. Mindegyik máshogy szar, aztán jó esetben tanulnak egymás hibáiból
Hát valszeg a descriptor set-ek esetén nem az MS oldotta meg, ők csak leírták a specifikációt
Aztán a driverek meg hasonló emulációkat csináltak, mint amit a VKD3D csinál most. Ferminek különösen, de a Kepler-nek sem nagyon feküdt az amit a DX12 akart.Az MS ezt megtehette mert lényegében ők diktálnak és max 4 vendorra kellett gondolniuk, míg a Vulkannak sokkal szélesebb körben kellett támogatni a hw-eket.
A Win32 meg a Direct3D, meg a WDDM egyáltalán nem szar. Sajnos a Windows kezd utóbbi években egyre gázabb lenni...
-
#17
vérjancsika
kezdő
hapakj
#10
vérjancsika
kezdő
Ja, amúgy igen, a DX12-es szinkronizációs/barrieres megoldás valóban nem volt egy tökély, de legalább cserébe egyszerűen használható.
A renderpass meg igazából csak egy optimalizációs fogalom, a DX12-ben is benne van, de szerencsére nem kötelező jelleggűen. Az, hogy egy "renderpassban" éppen milyen rendertarget meg egyéb input van becsatolva, driver szinten is kideríthető a Draw-callban. Ez nyilván nagyobb költségű, mintha a meghajtókód mondaná meg explicit renderpass keretében, de mindenesetre nem szükséges, ezért opcionális. Még egy Surface Pro X-ben levő Adreno 690-en is "simán" megy a renderpass nélküli renderelés, pedig úgy tudom, az is tile-based architektúra. -
#16
vérjancsika
kezdő
hapakj
#10
vérjancsika
kezdő
Hát, azért valami fogalam van.
Egyetlen API-val akartak szokás szerint minden eszközt lefedni, amivel együtt jár a "leggyengébb láncszem" jelenség.
De ha konkrétan a descriptor set-ekről beszélek, ha a MS meg tudta oldani azt, hogy korlátozásokkal ugyan (pl. maximum számú (16) deszkriptor egy tömbben), de olyan hardvereken is elérhető legyen a descriptor set fogalma, amelyek távolról sem támogatják, akkor a Khronosnak is illett volna már az elején kijönnie egy ilyen deszktop extension-nel, de nem tették. Inkább ráerőltették mindenre az 1.0-ás megoldást. Aztán amikor kiderül, hogy ez nem elég a dxvk-nak, akkor bevezetnek egy dx12-es extensiönt. Aztán most majd megint, mert a mostani megoldás még mindig nem elég, a vkd3d-nek. És minden ilyen lépésnél kiderül (a fanboyok részéről), hogy az addigi feature set tulajdonképpen mekkora xar volt.
Mindezt főleg azért írom, mert emlékszem még, 10 éve mekkora világszintű hiszti ment azon, hogy a DX12 mekkora egy szar, a Vulkan meg az isten, főleg, hogy valami benchmarkban a DX12 éppen tök xar performanszt adott.
A saját tapasztalatom meg az, hogy a DX api-k egyáltalán nem szoktak rosszak lenni, tökéletesek sem persze, de ezek valahogy mindig "menet közben", évek alatt derülnek ki.
Ja, és ugyanezt el tudom mondani általában véve a Win32-ről is. Azt is állandóan fikázzák, persze mindig olyanok, akiknek lövésük sincs az egészről. -
#15
vérjancsika
kezdő
hapakj
#12
vérjancsika
kezdő
A DXGI olyan értelemben a core DX API része, hogy DX10+-hoz mindenképpen szükséges, és azért képez független API-t (a korábbi DX-ekkel ellentétben), mert a device-ok/display outputok-hoz kapcsolódó funkcionalitás nem fejlődik olyan gyorsan, mint a core GPU-funkcionalitás. A MS is leírja, hogy ezért lett belőle külön komponens. A kettő együtt egy szép kerek egységet alkot.
Lehet azt mondani, hogy az adott platformnak kellene a DXGI helyére a megfelelő API-t biztosítania, de akkor minek vannak az extension-ök? Miért nincs egy "desktop Vulkan" extension set, ami ugyanazt biztosítja, mint a DXGI?
Azt hittem, ebből már az OpenGl óta kinőttünk, de nem...
(megjegyzem, a DX a kezdetektől fogva (90-es évek) valódi multimonitor API volt, még DirectDraw-val is lehet külön-külön display-ekre "device"-okat létrehozni) -
#13
Nestor-xyz
csendes tag
hapakj
#11
Nestor-xyz
csendes tag
Engem hiába provokálsz hülye kérdésekkel, a válasz mindig ugyan az: "PC + Windows + NVIDIA = boldog és kiegyensúlyozott élet". Ha keresed a kihívásokat: mehetsz "PC + Linux/Windows + AMD = az aranyeremet rólad fogom elnevezni" úton. Beszélj erről még néhány fejlesztővel, ők is bizonyosan megerősítik.
-
#12
hapakj
őstag
vérjancsika
#7
hapakj
őstag
válasz
vérjancsika
#7
üzenetére
a device-okhoz csatolt display output-ok enumerálásáról se álmodjon senki
- ez mondjuk DirectX esetén sem a core DirectX API része, hanem a DXGI-é, ami egy elég Windows specifikus platform API. S mivel a Vulkan egy multiplatform design eredménye így nem igazán tartalmazhat fix swapchain vagy display enumerációs API-t sem. Ezeket az egyes platformoknak kellene biztosítania, mint Windows, Linux, Android. -
#11
hapakj
őstag
Nestor-xyz
#9
hapakj
őstag
válasz
Nestor-xyz
#9
üzenetére
Miért? Olcsóbb a Vulkan HW mint a DirectX? Mesélj még
-
#10
hapakj
őstag
vérjancsika
#7
hapakj
őstag
válasz
vérjancsika
#7
üzenetére
wow, ezekkel a megnyilvánulásokkal nagyon tükrözöd, hogy foggalmad sincs milyen design megfontolásokból fejlődtek az egyes apik.
Másrészt a DX12-nek is voltak elkúrtuk pillanatai, ezért koppintsolták utólag a Vulkanból a szinkronizációs és renderpass modellt több kevesebb sikerrel.
-
#9
Nestor-xyz
csendes tag
vérjancsika
#7
Nestor-xyz
csendes tag
válasz
vérjancsika
#7
üzenetére
Amióta létezik, a Vulkán a szegény ember DirectX-e! Pontosan, ahogy mondod!
-
#8
Abu85
HÁZIGAZDA
vérjancsika
#7
Abu85
HÁZIGAZDA
válasz
vérjancsika
#7
üzenetére
Ez nem ilyen egyszerű. Ezek grafikus API-k. Számos eltérően működő architektúra van, aminek meg kell felelni. A Microsoft ezt a kérdést másképp közelítette meg, mint a Vulkan, de csakis azért, mert a DirectX 12-nek nem kellett szembenéznie egy rakás ultramobil dizájnnal. És ez jelentős különbség, mert így a szem előtt tartott hardverek száma sokkal szűkebb volt.
A Vulkan több olyan kiterjesztést is kapott már, ami a Core 1.0 bekötési modellját kiterjesztette, hogy ne legyen annyi megkötés. De ez nem azért van, mert a Vulkan rossz, hanem azért, mert futnia kell a mobiltelefonokon is, és emiatt nyilván nem csinálhatják ugyanazt, amit a Microsoft.
Ha mondjuk csak azt néznék az API tervezői, hogy minden a fejlesztőnek legyen jó, akkor azt a bekötési modellt látnád bennük, ami a Mantle-ben volt. És akkor ezzel ki is zártad a hardverek zömét, tehát nem nézhetik ezt.
-
#7
vérjancsika
kezdő
Abu85
#5
vérjancsika
kezdő
Ebben a videóban a nő gyakorlatilag elismeri, hogy a DX12 kezdettől fogva jobb tervezés, "beleadtak mindent" (a fanboi-ok ezt pont fordítva gondolták már 10 éve is), a DX12-t általában véve szeretik, a Vulkant meg utálják. Ideje hát végleg lekoppincsolni a DX12-t.
Egyébként ezzel én is így vagyok, akárhányszor kényszerülök valami Khronos-API-val foglalkozni, egyből az az érzés fog el, hogy az a szegény ember DirectX-e.
Még swapchain sincs desktop vulkanban (akkor mégis mire van a swapchain extension), a device-okhoz csatolt display output-ok enumerálásáról se álmodjon senki, ettől kaptam kezdésként agyvérzést legutóbb. -
Abu85
HÁZIGAZDA
Faith Ekstrand foglalkozott ezzel a kérdéssel nagyon sokáig. Mert ez egy nagyon specifikus gond, ugyanis a Vulkan API-nak, a DirectX 12-nek, a VKD3D-Protonnak és az NVIDIA hardvereknek nincs baja külön-külön, de együtt jelentős gondot okoz, hogy nem lehet olyan emulációt találni, ami gyorsan dolgozik a GeForce-okon, ha Vulkan API-n futtatunk DirectX 12 játékot az említett rétegen keresztül.
Erről számtalan előadás volt, talán ez a legutolsó. [link]
Nem azért pakolják ezeket az extensionöket a Vulkanba, mert sz@rf0sra sikerült a specifikáció, hanem hogy a Windowsos API emulátorokkal minél inkább "súrlódásmentes" legyen a kapcsolat, minél kevesebb extra kört kelljen futni a különbségek áthidalásakor a wine/proton grafikus stackjében. Más szóval hogy a Windowsra írt játékok Linuxon minél kisebb teljesítményhátrányból induljanak.
Új hozzászólás Aktív témák
- Horgász topik
- A '90-es évek jutnak az eszünkbe az ATK készülő egeréről
- Luck Dragon: Asszociációs játék. :)
- Formula-1
- Lassan 2027-re is elfogy a TSMC 2 nm-es gyártókapacitása
- Formula-1 humoros
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Iqos cigaretta
- Samsung Galaxy S23 Ultra - non plus ultra
- PlayStation 5
- További aktív témák...
- HP EliteBook 640 G11 Core Ultra 5 125U 1 év gar
- Samsung Galaxy A16 / 4/128GB / Kártyafüggetlen / 12HÓ Garancia
- Playstation 4 FAT 1 TB kontroller 6 hó garancia, számlával!
- BESZÁMÍTÁS! ASUS B150M i5 7500 8GB DDR4 256GB SSD GTX 1050Ti 4GB Nbase Black Midi DeepCool 400W
- HIBÁTLAN iPhone 11 128GB White -1 ÉV GARANCIA - Kártyafüggetlen, MS4258
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest