1

Intel Drops DirectX 9 Support On Xe, Arc GPUs, Switches To DirectX 12 Emulation

 1 year ago
source link: https://games.slashdot.org/story/22/08/15/2217246/intel-drops-directx-9-support-on-xe-arc-gpus-switches-to-directx-12-emulation
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Intel Drops DirectX 9 Support On Xe, Arc GPUs, Switches To DirectX 12 Emulation

Become a fan of Slashdot on Facebook

binspamdupenotthebestofftopicslownewsdaystalestupid freshfunnyinsightfulinterestingmaybe offtopicflamebaittrollredundantoverrated insightfulinterestinginformativefunnyunderrated descriptive typodupeerror

Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 30 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
×
An anonymous reader quotes a report from Ars Technica: Native DX9 hardware support is officially gone from Intel's Xe integrated graphics solutions on 12th Gen CPUs and A-Series Arc Alchemist discrete GPUs. To replace it, all DirectX 9 support will be transferred to DirectX 12 in the form of emulation. Emulation will run on an open-source conversion layer known as "D3D9On12" from Microsoft. Conversion works by sending 3D DirectX 9 graphics commands to the D3D9On12 layer instead of the D3D9 graphics driver directly. Once the D3D9On12 layer receives commands from the D3D9 API, it will convert all commands into D3D12 API calls. So basically, D3D9On12 will act as a GPU driver all on its own instead of the actual GPU driver from Intel. Microsoft says this emulation process has become a relatively performant implementation of DirectX 9. As a result, performance should be nearly as good, if not just as good, as native DirectX 9 hardware support.

  • ›

    It's called "How to Lose a Business Partner in 10 days" They're breaking up the family, ie not renewing some OEM agreement, and this is their way of papering over the row for a bit while the dust settles.

    • Re:

      DirectX 9 is way past its used by date, the fact it has any support at all in current OS or hardware is pretty cool.

      • Re:

        Microsoft can't drop DirectX9 anytime soon, not at least without rewriting their main C# GUI component library first (C# Windows Presentation Foundation). WPF is based in DirectX9 which you can confirm by looking at the WPF source code here [github.com]. Microsoft have recently introduced a new component library call WinUI3, but it's going to be a long journey before WinUI3 knocks WPF off the throne.

        • Re:

          On that note, DX9 has some serious backwards compatibility issues with hardware graphics moving forward. This same issue happened with OpenGL, so history repeating itself. DX was created to avoid backwards compatibility issues. Wonder if Vulkan will take over, lol. One of the big problems with OpenGL was extension support, but Vulkan seems to have eliminated that. DX now needs to catch up - maybe DX12 with DX 9 backwards compatibility does catch up, I don't know. Still a lot of features that came after DX9

          • Re:

            No, the main problem with OpenGL is that every major vendor wants to kill it.

            Microsoft has been trying to kill it since "Fahrenheit":

            https://en.wikipedia.org/wiki/... [wikipedia.org]

            Apple hasn't updated their OpenGL since 2010 and recently deprecated it.

            The other major problem is that everybody thinks it's "old" when it isn't. OpenGL is absolutely a modern API (I'm programming it right now) but the move from (eg.) version 4.4 to version 4.5 doesn't sound very exciting even though it makes OpenGL compete with Vulkan on spee

  • There's been dgVoodoo for quite a while. It's a drop-in replacement for d3d9.dll that replaces DX9 calls with DX10/11/12 compatible calls, with built-in fixes for specific games.

    Not sure which is better, but I've been using it to play Unreal Tournament 2004 for quite a while with no problems.

  • Who cares so long as it works?

    I can't imagine that games will run slower under a DX12 emulator than they used to run when they were released under DX9.

    • Re:

      What will be the impact on the Intel graphics Linux driver? Is this change going to mean more work for their developers?

    • Re:

      Well quite.

      I don't even get it. It's not like any GPU now supports DX9 natively whatever that means. They're basically a wide array of programmable barrelled SIMD cores with a somewhat exotic memory architecture, an interesting array of synchronisation primitives and hardware support for a number of operations such as texture sampling.

    • Re:

      Emulation often means input lag. Microsoft has replaced parts of their graphics APIs in the past with emulation such that old win9x stuff that requests exclusive access simply gets lied to. Stuff (mostly) still works, but now there's a noticeable delay. Because this delay was undeniable and the lost functionality was actually necessary they gave you new ways to actually request a real exclusive context. And then they moved that to emulation as well. It's good that old stuff still works, but sadly while you

    • Re:

      I can't imagine people running Xe integrated graphics care about gaming performance.

  • It's a lot less work to do in the software side and probably on the hardware side as well.
    But intel should check DXVK as their DirectX9 support as well before just committing to the microsoft stuff.

    • Re:

      Possibly, but letting Microsoft do the heavy lifting on supporting DX9 is a win for Intel today.

    • Re:

      Both are MIT-style opensource, but dxvk is Linux-only so they'd have to port it first, moreover D3D9On12 has corporate backing, AND it's made by the company that controls both the API and the OS. They'd have to be crazy to do with dxvk.

  • And performance degrades vs one API call, it's simple math and the more API calls you make, the more jump instructions you need and the better chance you get a cache miss, then it's a few cycles to get what's in memory. So tell me again how performance is "just as good"

    • Re:

      Win32 programs have a 1500 cycle penalty for executing system calls. Yes, that's absurdly large. So minimizing system calls has a bigger effect than anything micro like an extra indirect jump on every API call. All that matters is fewer system calls.

      • Re:

        "In most existing systems, switching from user mode to kernel mode has an associated high cost in performance. It has been measured, on the basic request getpid, to cost 1000â"1500 cycles on most machines. Of these just around 100 are for the actual switch (70 from user to kernel space, and 40 back), the rest is "kernel overhead".[11][12]"

    • Re:

      On a modern PC it's probably faster than when the DX9 game was originally released.

  • DirectX 9 essentially hasn't been updated since 2010 and Windows XP. I doubt there are many games where you'd even notice some additional thunking going on to translate calls from one API to another.

    • Re:

      Also most dx9 games have rather modest resource usage by modern standards. Though there's possibility that things would break if translation layer has bugs. Or doesn't implement original dx9 bugs that programs rely on.

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK