Intel is overgestapt op DirectX 9-emulatie voor nieuwe Arc- en Xe-videokaarten

Intel is gestopt met het aanbieden van native ondersteuning van DirectX 9 op zijn meest recente Arc- en geïntegreerde Xe-videokaarten. In plaats daarvan gebruiken die gpu's een DirectX-emulatielaag van Microsoft, die volgens de maker relatief goed presteert.

Intel bevestigt op zijn website dat de Arc-videokaarten en de geïntegreerde Xe-gpu's uit twaalfdegeneratieprocessors geen native ondersteuning meer bieden voor DirectX 9, merkte Tom's Hardware als eerste op. Applicaties die gebruikmaken van die api werken op die videokaarten nog steeds via D3D9On12. Dat is een soort emulatielaag van Microsoft, die DirectX 9-instructies doorstuurt naar D3D9On12 en deze vervolgens vertaalt, zodat ze gebruikt kunnen worden op de DirectX 12-driver van een videokaart. De geïntegreerde gpu's in Intels elfdegeneratieprocessors en ouder houden native DirectX 9-ondersteuning.

D3D9On12 is al jaren een onderdeel van Windows 10 en de broncode van de vertaallaag is sinds vorig jaar open source. Microsoft zegt dat deze emulatieaanpak in de afgelopen jaren is uitgegroeid tot 'een complete en relatief goed presterende implementatie van een D3D9-driver'. Daarmee zouden de prestaties niet veel lager moeten liggen dan bij native DirectX 9.

Intel maakt geïntegreerde gpu's voor in zijn processors en werkt momenteel aan zijn losse Arc Alchemist-videokaarten voor laptops en desktops. In de eerste reviews bleek dat die Arc-gpu's kampen met driverproblemen en tegenvallende prestaties. Het bedrijf bevestigde eerder al dat games die gebruikmaken van oudere grafische api's, zoals DX11 en ouder, nog niet goed geoptimaliseerd zijn op Arc. Dat is omdat die oudere api's extra 'driverbagage' tussen de game en de gpu-hardware hebben, waar modernere api's zoals DirectX 12 en Vulkan meer low-level zijn en dus directer met de hardware kunnen communiceren. Het bedrijf zegt te werken aan het optimaliseren van Arc voor oudere api's.

Het is niet duidelijk wat de prestatiegevolgen van DirectX 9-emulatie zijn op Arc en Xe, maar gezien de driverproblemen die Intel heeft met oudere api's en Microsofts claims dat D3D9On12 relatief goed presteert, lijkt het een goede zet. De Arc-videokaarten komen na uitstel later dit jaar breed beschikbaar.

Reacties (50)

[NESFreak]

Veel dx9 games zijn ook al 'stuk' op de huidige NVIDIA videokaarten.

Om bijvoorbeeld sonic & allstar racing transformed werkend te krijgen moet je de windows versie van DXVK in de gamemap plaatsen. https://steamcommunity.co...ns/0/2944747978665782364/

Maar überhaupt veel dx9 games kunnen een performance gain krijgen door simpelweg te switchen naar DXVK. Een aantal games draaien onder wine/proton/linux dan ook beter dan op windows.

Ik ben eigenlijk wel benieuwd naar benchmarks tussen native dx9, DXVK, en D3D9On12

[Reactie gewijzigd door NESFreak op 22 juli 2024 15:35]

[Blaat]

Niet alleen DX9 games en niet alleen bij nVidia. Het meest bizarre voorbeeld wat ik heb is Assassin's Creed Origins, welke op AMD videokaarten vanaf GCN op native DX11 gewoon dramatisch presteert. Installeer DXVK, en je prestaties stijgen met 20% of meer en je frametime variaties worden met 80% of meer gereduceerd.

Zo ging ik van 50fps gemiddeld en dips naar 12fps op 3840x2160 met een 6900XT naar 65fps gemiddeld met dipjes naar 55fps.

Heel bijzonder hoe een wrapper soms sneller is dan native. Hoewel ik wel denk dat dit ten dele door de drivers van AMD komt.

[Luuk1983]

Is het niet zo dat er allerlei effecten komen te vervallen via DXVK? Dan snap ik wel dat de framerate een stuk hoger is.

[Blaat]

Dat zou kunnen, daar heb ik inderdaad wel het een en ander over gelezen. Als je echter screenshots naast elkaar legt is er geen enkel verschil te zien. De hypothese op dit moment is dat met DXVK ertussen de renderthread multithreaded wordt gemaakt (wat nVidia al doet met hun drivers omdat ze geen hardware scheduler hebben), daar waar deze normaliter single threaded zou zijn in DX11.

[Metal spoon]

DXVK is geloof ik redelijk feature complete, ik gebruik het geregeld op linux en het is mij nog nooit opgevallen dat er features zouden missen.
Ik denk dat het verschil hem zit in de drivers, AMD's windows drivers zijn geloof ik nooit hun sterkste punt geweest.

[Amanoo]

Dat is wel bij sommige nieuwere spellen het geval, maar ik meen zeker niet bij alle spellen. Maar dan heb je het wel over spellen met DX11 of DX12. DX9 is wel ongeveer volledig geïmplementeerd.

[Reactie gewijzigd door Amanoo op 22 juli 2024 15:35]

[LongTimeAgo]

Bij heel wat spellen moet je vaak nog even handmatig de DX9 installatie starten die binnen in de installatie game folders staat sinds Windows 10 voordat het werkt.
Daarna werkt het meestal wel weer.

[NESFreak]

Windows komt standaard idd niet met de volledige DX featureset. (want waarom zouden ze )

Dat kun je in 1x oplossen door alle optionele DX features binnen te halen via de volledige
Microsoft DirectX® End-User Runtime download https://www.microsoft.com...load/details.aspx?id=8109

Na een schone installatie gooi ik zodoende ook vaak in 1x alle vcredist varianten erop. https://www.techpowerup.c...ntime-package-all-in-one/

[LongTimeAgo]

En de oude spellen houden natuurlijk ook geen rekening met de nieuwe Windows en de installers of benodigdheden voor hun spel. Wel fijn dat er tenminste nog wel vaak rekening wordt gehouden met benodigdheden en dat deze vaak binnen de bestanden van de CD/DVD of installatie folders van het spel zelf staan.

Anno 1404 (met Venice uitbreiding) had hier bijv. last van. Even de DX9 nog handmatig na installeren en het werkt als een zonnetje. Anno 1404 History Edition uiteraard niet (meer).

[rjmno1]

Alles zal wel op 11 en 12 draaien die versie 9 directx is heel erg lang meegegaan.
Tijd voor vernieuwing.
Die arc videokaarten van intel lopen ook op vulkan en natuurlijk directx 12

[RRRobert]

Het emuleren van chips... voor de ouderen onder ons (moi ), wie herinnert zich emm387.exe nog, wat je installeerde als je geen math coprocessor op je 386DX moederbord had geprikt en toch bijv. AutoCAD wilde draaien?

[Hobbit13]

denk dat je emm386.exe bedoelt.

Dat was een expanded memory manager, waardoor je geheugen dat normaal niet bereikbaar was voor DOS applicaties kon inzetten. Het vereist de Virtual Mode van de 386 processor om geheugen te heralloceren zodat achtergrond processen in het upper memory deel kunnen zitten wat normaal gesproken niet bereikbaar is voor een DOS applicatie.

Dit wordt nog steeds ondersteund in Intel VT-x e.d. dus je zou in legacy mode nog steeds dit soort applicaties moeten kunnen draaien.

Ik kan niets vinden over een link tussen de Math Coprocessor en een EMM.

[KeiFront]

RRRobert bedoeld het emuleren van de x87 instructieset https://en.wikipedia.org/wiki/X87, vroeger had je programma's bijvoorbeeld Q87/Q387/... om deze instructieset te emuleren zodat je toch bijvoorbeeld Autocad kon draaien want die verwachte een coprocessor.

Intels eerste x86-CPU’s hadden bijbehorende x87-FPU’s (floating-point units), bijvoorbeeld de 8086 kreeg hulp van de 8087 voor berekeningen met kommagetallen, de 80286 van de 80287 en de 80386 van de 80387. De 80486 was de eerste in de reeks met een ingebouwde FPU.

[TrekVogel]

Alleen de 80486DX had dat. Wij hadden helaas een SX.

[RRRobert]

Dank voor de toelichting.

[RRRobert]

Ik heb tijdens het schrijven zitten dubben of het nou emm386 of emm387, maar goed, dat was begin jaren negentig, dus inmiddels zo'n dertig jaar geleden. Verbazingwekkend inderdaad, dat zelfs Google nagenoeg niets aan uitsluitsel kan geven.

Ik weet nog wel dat een 386DX moederbord een aparte socket had voor een 387 coprocessor. Dat was voor mij als MTS student destijds toch weer een investering van ca. 500 gulden

[Henk Poley]

Ging waarschijnlijk 'gewoon' om 387.EXE / device=FRANKE.387: https://www.pcorner.com/list/UTILITY/387.ZIP/INFO/

[Reactie gewijzigd door Henk Poley op 22 juli 2024 15:35]

[joost00719]

Lijkt mij best een goede oplossing. Zo houd je de video chip qua software en hardware modern en kunnen ze focussen op nieuwere technologie die meer performance vereisen. De oude DX9 games zijn ook een stuk lichter, dus verwacht ik dat bijna alle DX9 games wel acceptabele performance zullen hebben door het te emuleren.

[Laurens-R]

Eens... de gemiddelde DX9 game zal niet veel vragen van een huidig systeem.

Ik denk dat emulatie niet eens echt het juiste woord is... Volgens mij kan je een beter parallel met Wine trekken. (Het vertalen van API A naar API B ). Dat is in dit geval alleen maar beter want dat betekend ook dat de performance impact relatief laag is tov wat we normaal onder emulatie verstaan (eg: console emulators, geemuleerde virtual machines (x86 op ARM) etc)

[Reactie gewijzigd door Laurens-R op 22 juli 2024 15:35]

[keranoz]

Dus het emuleert API B?

[Blaat]

Als ik me niet vergis noem je zoiets technisch gezien een wrapper (vertaalslag), geen emulatie (kunstmatig gerepliceerd ecosysteem).

Maar het is hier nogal een grijs gebied vind ik, je zou beide termen kunnen hanteren.

[Reactie gewijzigd door Blaat op 22 juli 2024 15:35]

[Pep7777]

Technisch gezien noemen we dat (eigenlijk heel logisch) een adapter.

[blorf]

Ik dacht aan parser. Iets wat informatie in een strikt formaat aanlevert om iets anders te laten functioneren. Adapting is eigenlijk hetzelfde vanaf de andere kant gezien.

[rphilipp64]

In de software wereld wordt de term parser voornamelijk gebruikt voor iets wat textuele input omzet naar data structuren. (JSON, XML, CSV, et cetera: daar vind je allemaal parsers voor).

Het woord adapter is zeer gangbaar als het gaat om een tussenlaagje wat vertaald van de ene API naar de andere. Zie het als een analogie van stroom adapters, waarbij je bijvoorbeeld een Europese stekker in een adapter steekt om hem in een US stopcontact te kunnen steken. Daarbij heb je adapters die pass-through zijn (je apparaat moet met 110V kunnen omgaan), óf die de voltages omzetten. Software adapters kunnen ook "pass-through" zijn, of net wat meer werk doen om aan beide kanten consistent gedrag te garanderen.

[blorf]

Geen idee wat officieel is. Een programma wat ik ts_parser genoemd heb filtert touchscreen-acties uit de USB-interface, maakt daar leesbare coordinaten van en geeft die door aan een UI. Die zou in dit geval de adapter zijn.
"Overhandigen"...

Ik zou het beter daemon kunnen noemen. Dat is alles wat de hele tijd draait en iets regelt.

[Reactie gewijzigd door blorf op 22 juli 2024 15:35]

[koelpasta]

https://en.wikipedia.org/wiki/Parsing

[Waswat]

Dat kan... wrapper gebruik ik om een simplificatie en soms vertaalslag van een connector te benoemen.
Dit lijkt me meer een mapping library, als het ware een omzetter en doorgeefluik. Misschien 'passthrough' of translation layer...

Het is sowieso niet emulatie, inderdaad.

[Reactie gewijzigd door Waswat op 22 juli 2024 15:35]

[rjd22]

Een "API translator" zou een beter woord zijn. Een emulator doet zich voor als een bepaald systeem waardoor het lijkt op virtualisatie. Vaak is dit een stuk uitgebreider (nabootsen van een bepaalde CPU en Memory architectuur).

Een API translator vertaald de API call van de ene API (DirectX) direct naar een andere API (Vulkan) waardoor er geen architectuur nagebootst hoeft te worden. Vulkan draait namelijk gewoon native in Linux. Hierdoor kan je ook bijna voor native performance zorgen aangezien deze niet vertraagd wordt door de overhead van virtualisatie.

[Bulkzooi]

Een "API translator" zou een beter woord zijn. Een emulator doet zich voor als een bepaald systeem waardoor het lijkt op virtualisatie. Vaak is dit een stuk uitgebreider (nabootsen van een bepaalde CPU en Memory architectuur).

Een API translator vertaald de API call van de ene API (DirectX) direct naar een andere API (Vulkan) waardoor er geen architectuur nagebootst hoeft te worden. Vulkan draait namelijk gewoon native in Linux. Hierdoor kan je ook bijna voor native performance zorgen aangezien deze niet vertraagd wordt door de overhead van virtualisatie.

Weet je wat een ABI is?

[rjd22]

Een "application binary interface" wat is uw punt? Zo ver ik weet is Wine geen ABI aangezien het op hoger niveau de vertaalslag doet.

Edit: Heeft u een bron waarbij Wine een ABI type protocol gebruikt? Zo ver it weet is het namelijk nog steeds van userspace naar userspace.

[Reactie gewijzigd door rjd22 op 22 juli 2024 15:35]

[Bulkzooi]

Een "application binary interface" wat is uw punt? Zo ver ik weet is Wine geen ABI aangezien het op hoger niveau de vertaalslag doet.

Edit: Heeft u een bron waarbij Wine een ABI type protocol gebruikt? Zo ver it weet is het namelijk nog steeds van userspace naar userspace.

Ik probeer je het verschil tussen API en ABI te laten zien, voordat je doorgaat over emulatie en/of ISA architecturen.

[Nimja]

Api wrapping is niet hetzelfde als api emulation.

[keranoz]

Het was bedoeld als grapje, ik weet waar WINE voor staat.

[rjberg]

Om een of andere reden telt dat niet als emulatie. WINE (WINE is not an emulator) zegt dat.

[sympa]

Het is een implementatie van calls die (niet toevallig) andere calls gebruikt die ruwweg hetzelfde toen.
Het uitvoeren van de programmacode gebeurt als vanouds door de CPU.
Net als bij WINE eigenlijk, dat eerder een Windows-kloon te noemen is dan een emulator.
Als je een Android-telefoon op Windows gaat emuleren heb je eel een emulator. Niks draait native, eerst dlstart de emulator, die dan een OS laadt en ook het laden van applicaties gebeurt door dat OS via de emulator. Die dan waarschijnlijk ook zijn eigen file system implementeert.

[MauriceEnschede]

Sterker nog, dit concept is verre van nieuw. Alle moderne x86_64 CPU's doen dit al tijden. Low level werken ze met een RISC instructie set. Maar er zit een CISC abstractie bovenop (wat de pipeline nog wel lang houd) die x86 instructies fetched, decode en vertaald naar de interne RISC instructions.

Omdat de onderliggende RISC architectuur efficienter is levert deze translation layer een positief resultaat op voor de CPU.

De beste manier om naar al deze moderne GPU translation layers te kijken vind ik dan om het een X driver voor vulkan te noemen. En ik vind het ook een goede zaak want DXVK, VKD3D, Zink, etc ondergaan geweldige ontwikkeling door crowdsourcing en fabrikanten hoeven zo enkel nog op de Vulkan drivers te focussen.

[Genosha]

Inderdaad. Een DX9 game zal echt wel in 100fps draaien zelfs onder emulatie.

[fapkonijntje]

Maar ik heb er 144 nodig

[jaaoie17]

Niet 200+?

[gimbal]

Standaard geprogrammeerde DX9 games, ja waarschijnlijk wel. Garantie tot aan de deur wat betreft je favoriete game uit die tijd, het was nog steeds een klein beetje het wilde westen waar men redelijk onorthodoxe logica inbouwde om grafische kunsten uit te kunnen halen die niet goed schalen naar de toekomst toe.

[youridv1]

Voor dat soort dingen kun je misschien beter een soort retro game systeem houden.

Het klinkt natuurlijk suf, een hele losse pc voor oude games, maar als je echt veel oude games speelt kan dat wel lonen. Je kunt hardware uit die tijd vaak voor een zacht prijsje op de V&A kopen.
Als je je zorgen maakt over de beveiliging zet je hem gewoon niet aan internet

[field33P]

Toch een rare move om native Direct3D 9 bij het grofvuil te zetten terwijl de nummer 1-game op Steam (CSGO) nog steeds op D3D9 draait (en de Source 2-versie al jaren op zich laat wachten)

[A Lurker]

De mensen die zeer hoge FPS op CSGO moeten halen zitten al prima met hun highend AMD of nVidia-kaart.

Op dit moment is de ondersteuning van Arc over het hele spectrum toch wel tamelijk beroerd te noemen. Dus Intel moet keuzes maken, ofwel steken ze enorme moeite in het optimaliseren van alle gangbare dx9 games, ofwel doen ze dat niet en is er waarschijnlijk niemand die klaagt dat ie straks zijn dx9 game niet op 300 fps kan draaien. En bijkomend voordeel is dat ze meer tijd hebben om dx11 games te optimaliseren.

[SinergyX]

Ok, dat is pleister op DX9, maar DX11 dan? Linus had bijna 50% verschil bij Tombraider in DX11/DX12, dat ga je niet oplossen met je D9on12 oplossing.

Blijft een aardige hit&miss welke game wel of niet redelijk kan draaien (en relatief tot hun AMD/Nvidia gelijke), zullen ze nog wel tijdje mee bezig zijn.

[Wolfos]

DX11 word een kwestie van iedere game langs gaan en handmatig optimaliseren. 11on12 is inderdaad geen goede oplossing voor games van de laatste jaren.

[johnbetonschaar]

Op zich zou het prima moeten kunnen, feitelijk is dat dezelfde aanpak als DXVK gebruikt voor Wine/Proton,
en daar draaien een heleboel spellen gewoon prima op.

Misschien moet Microsoft ook maar gewoon DXVK gaan gebruiken voor Arc/Xe

[Bulkzooi]

Weet iemand hoe het met de patenten van Direct3D staat? Die zijn ondertussen toch wel afgelopen?

[TweakersFan]

.

[Reactie gewijzigd door TweakersFan op 22 juli 2024 15:35]

[TweakersFan]

Is derectX 9 goed?
Kan iemand het zeggen?