Hacker News Reader

Comment by AstixAndBelix | Hacker News Reader

If DirectX were an open source standard we would have had almost no problem writing translation layers between all the versions and other APIs. Unfortunately, since it's a reverse engineering hack job, there's still too much lost performance left on the table

View on HN

So far, backward compatibility for D3D games on Windows has been excellent though. I really wonder why Intel is the only GPU vendor who has trouble supporting older D3D versions (and if this is such a problem for GPU vendors, why Microsoft doesn't step in and provide a generic D3D9-on-D3D12 driver).

(also I think the actual problem isn't a generic D3D9 emulation, but that a good emulation needs to implement thousands of game-specific performance and compatibility hacks which are usually taken care of by the GPU vendor or Microsoft)

Microsoft seems to have provided some of that in the OS as open source here: https://github.com/microsoft/D3D9On12

Unfortunately, it looks like it's up to the application developer to support it, unless I'm reading it wrong.

Intel were apparently using that for backwards compatibility on Arc[1]. I guess it wasn't good enough and they're using DXVK instead? Or is this new "native" mode DXVK instead?

[1] https://arstechnica.com/gadgets/2022/08/intel-turns-to-code-...

Their readme linked from the article mentions both D3D9On12 and dxvk as some of the licensed software being used: https://downloadmirror.intel.com/761751/readme.txt

They may be using both of those. They mention in the video linked from the article that the driver is choosing between native and the hybrid approach where appropriate, depending on what game/app is running. Maybe they also choose between different hybrid options as well?

That's what I gathered. Since D3D9On12 compatibility is supposed to be complete and supported by Microsoft themselves, and DXVK compatibility is hit or miss but much higher performance, they're whitelisting popular titles that they can validate for DXVK on Windows. It's the right approach.

There's zero sense in writing a DX9 driver today. Not with the performance you can get out of DXVK. Most of the remaining popular games on DX9 will be moved to native Vulkan or DX12 at a point regardless.

Some of this seem to Arc trying to be "legacy free" and not including much in Arc drivers / hardware to specifically cater for legacy APIs. AMD and Nvidia drivers are almost certainly eldritch abominations full of legacy. Intel also seem to have at least partly started anew on the drivers as well, although I doubt gaming performance was a major aim for Intel iGPU drivers before Arc. They probably though that Microsoft have an emulation layer, so that will be good enough, right? I bet the Microsoft team were probably more thinking "we want casual games like The Sims to work on ARM netbooks with a modern API only GPU, and nobodies going to be using those sort of things for maximum performance 110% stuff...".

As stated by others in the comments section, DX9 is a huge, complicated beast. nvidia and AMD have decades of experience here, so dragging it along with new generations of GPUs is relatively easy. Intel would've had to start almost from scratch. They're betting on the future, where backwards compat with it becomes less and less important, and the power of their GPUs keeps increasing, so the overhead for older titles is getting less noticeable.

Intels integrated GPUs have pretty good "legacy D3D" support though (much better than their legacy GL support anyway)... it's not like they are newcomers when it comes to graphics driver development. Also D3D11 support will be relevant at least for the next 10 years

I forget where but in one YouTube video at least where they were being interviewed they explained that they thought this too. They thought that their integrated graphics legacy would be able to be essentially transferred over to making desktop cards but it sadly wasn't the case. The things that they did for the drivers for the integrated chips and the way that they designed the integrated chips were not transferable knowledge. So they did have to start mostly from the ground floor to work on the Arc gpus.

Maybe if they hadn't spent the last 20 years making godawful iGPUs they would have actually had some transferable knowledge.

Well, on Vista+ versions of Windows the support of DX8- is generally pretty bad... and those early 3D games are too computationally intensive to be fully emulated !

DX9 is twenty years old; any game before that can be fully emulated. It is just easier to port any worth playing to DX9

You are forgetting the time for developers to adopt it, DX8- games were still released up to at least 2006.

And no, you cannot fully emulate all of these early 3D games, some of them will still crawl in software.

Finally, how do you port a game you do not have the source code for ?

Is there? Many games actually run faster on Linux via Proton than on Windows with the same hardware. I think the performance overhead of translation layers are pretty overstated in 2022

They are, and it's because they're able to multithread more in DXVK and return the results faster than in most native DX9 implementations.

Translation layers for a currently-intensive API like DX12 or Vulkan would be worth the criticism, and as developers most of us prefer as close to the metal as possible.

Eventually even Nvidia and AMD will drop their native DX9 drivers. It's driver bloat, and requires some level of maintenance for new GPU architectures. I expect all vendors to use D3D9On12 at a point.

It's like if our hardware directly supported DOS applications. We wouldn't need DOSBox for our Adlib emulation, but everyone agrees that DOXBox is the best approach.

The biggest DX9 titles, Starcraft 2 and CSGo, will be migrated to DX12 and Vulkan (respectively) if they continue to remain popular. CSGo itself has experimental Vulkan support on Linux already.

Reply on news.ycombinator.com