Intel is using DXVK for their Windows Arc GPU DX9 drivers
gamingonlinux.com
gamingonlinux.com
Certainly better than the joke that is ROCM support for AMD GPUs.
More details in a prior comment: https://news.ycombinator.com/item?id=32908918
¹ https://community.amd.com/t5/knowledge-base/amd-rocm-hardwar...
Just see this thread for an example of the frustration people feel: https://github.com/RadeonOpenCompute/ROCm/issues/887
This hasn't been an issue with day one CUDA and ML functionality on any recent Nvidia GPUs.
> once compiled properly and sometimes with the right environment flags
Not interested in apologism for the corporation. If AMD wants to compete with CUDA, they have to support the consumer GPUs that are accessible to hobbyists and non-experts. This is user hostile support.
Unfortunately for ARC they pretty much marketed it solely for gaming applications, where the chip and drivers don't really excel in. Linux support, AV1 encoding, and so on are its strong points, not raw performance. You can argue that those things don't make as much money as the gaming market, but if Intel's beaten by the competition on the performance side they'll need to find another route to sell this.
This statement in particular:
> "unlike AMD ROCM which requires a custom kernel and closed-source components"
As far as my experience, ROCm does not require a custom kernel nor special kernel modules as it works just fine for me with stock distro kernels, nor does it require closed-source components. OpenCL and OpenGL have pretty much always worked fine for a long time now. I think that AMD drivers are just as good as Intel ones especially when it comes to how open-source they are. While it's cool that Intel already has AV1 encoding on their new cards, I fully expect AMD will have just as good AV1 encoding on their next gen RDNA 3 cards too when they come out soon.
Even with 37, rocm is not complete. HIP is missing, blender doesn't work and asks for the proprietary driver (which, again, works only with Ubuntu and CentOS).
$ env LD_LIBRARY_PATH=/opt/rocm-5.4.0/opencl/lib clinfo
Due to the first class Linux support on even Intel's IGPU, I was expecting Arc to be a great fit.
More over I don't have to sell my Kidney to buy Intel products in my country, Unlike the Red team & Green team products.
Mostly eSports titles have those native ones.
that said, intel arc has been slow as dirt for old games. they seem to have, through hard work, turned the corner. im curious how much of that improvement has gotten upstream to the public, to others. versus how much intel has done only for themselves, after putting all their eggs in this open source community project.
Hearing that NVIDIA engineers actually re-implemented many of the un-optimized shaders released on triple-A games and made their drivers to dynamically swap to their shader implmentation on the fly, is a testament to how NVIDIA really did care about game driver performance.
Technically this does sort of still happen these days (eg the period of time when NVIDIA cards had ray tracing support but AMD cards did not, the quality of the video encoder, or nowadays with the various super-resolution methods used by each vendor), in which case those do tend to get treated separately in third-party benchmarks since not everyone really cares for the quality of those.
(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)
Unfortunately, it looks like it's up to the application developer to support it, unless I'm reading it wrong.
[1] https://arstechnica.com/gadgets/2022/08/intel-turns-to-code-...
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?
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.
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 ?
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.
P.S.: I am starting to suspect that Steam now doesn't show which games are Linux native, and which run through Wine, am I getting this right ?
From my understanding, Vulkan/DX12 are APIs that are supposedly very low-level and allow fine-grain control over things like memory access, synchronization, and hardware-level optimizations (usually through the use of extensions). For OpenGL and DX9/10/11, these are basically higher-level abstractions that can be implemented on top of the lower-level APIs.
Assuming the above is accurate, what advantage do you get by having "native" OpenGL or DX9/10/11 implementations on your GPU? Is there anything Intel is missing out on by using DXVK as opposed to implementing their own implementations?
And how does Gallium3D (from the Mesa project) fit in all of this for Linux? Is that a lower-level abstraction than Vulkan?
One key issue is that Vulkan makes assumptions about the structure of graphics pipelines, which can make it harder to optimize the driver when an application changes a piece of state. For example, if an application changes the face culling mode, this may require recompiling the entire pipeline, which can be inefficient.
In contrast, native OpenGL or DirectX implementations allow for more flexible and efficient ways of managing state changes. For instance, they may provide hardware toggles that can be used to quickly and easily update the state without needing to recompile the entire pipeline. This can significantly improve the performance of the driver.
They're adding new VK_EXT_extended_dynamic_state extensions to allow setting state dynamically, but the extensions don't support every single random piece of hardware state, and some hardware state can be limited or weird enough that it's hard to export in any sort of generic interface. Try explaining to a user that dynamic state A only works if there's enough free internal memory that hasn't been filled up by state B + C or D + A.
Also any abstraction layer will add CPU overhead because you need to manage/allocate more objects, process state through more layers, etc. It doesn't matter in every piece of code, but processing draw calls (which can happen millions of times a second) it can add up.
> Gallium3D
Is a lower layer below OpenGL. It was originally intended to be at a similar level to D3D9, so OpenGL drivers could avoid a lot of state tracking (e.g. texture dimensions are immutable open creation). It's still higher-level than Vulkan, since memory management and synchronization implicit (at least last I checked).
Vulkan is growing extensions specifically for that though, so in the medium term it might catch up.
> The third option, surprisingly, is Gallium3D (or simply "Gallium"), he said. He has been learning that it is basically a hybrid approach between state streaming and pre-baked pipelines. It uses "constant state objects" (CSOs), which are immutable objects that capture a part of the GPU state and can be cached across multiple draw operations. CSOs are essentially a Vulkan pipeline that has been chopped up into pieces that can be mixed and matched as needed. Things like the blending state, rasterization mode, viewport, and shader would each have their own CSO. The driver can associate the actual GPU commands needed to achieve that state with the CSO.
The (admittedly very dumb) issue I as a developer have switching from MFC/ATL to newer kits is that it makes it very hard to ship all in one apps without bloating them by shipping the control toolkit every single time. I realize this is a dumb complaint, but when I can get something down to ~3.5MB which I consider a win for size squishing in modern apps. But does it make sense for all cases? No, if I was writing something people need to use on more than an occasional basis I'd probably grab a toolkit that did the work for me to use D2D (which btw operates on top of either GDI or DX11, not DX12).
[1] https://learn.microsoft.com/en-us/windows/win32/direct2d/com... [2] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...