3 ms·

IANA GPU expert, but AFAIK modern GPUs are pretty much are that already: massively parallel general-purpose CPUs. It's the GPU driver layer that takes either t

IANA GPU expert, but AFAIK modern GPUs are pretty much are that already: massively parallel general-purpose CPUs. It's the GPU driver layer that takes either the compute or graphics instructions and converts them into the particular instruction set/microcode used by the "CPUs" in the GPU. In a sense that code is "recompiled" (but may be cached) every time a "program" is run. [0] is a post that talks about reverse-engineering the interface to the GPU in the Apple M1, a lot of which consists of what I've just described, so reading that series might help understand. [0]: https://rosenzweig.io/blog/asahi-gpu-part-1.html https://rosenzweig.io/blog/asahi-gpu-part-1.html

qwerty456127 5y ago
The reason I feel interested in this is it seems we wouldn't need a vendor/model-specific 3D graphics driver in such a case. The vendors could just provide libraries implementing a standardized set of general purpose parallel calculation acceleration functions (e.g. OpenCL) and an app (or a vendor-agnostic 3D driver) would just use the vendor-agnostic interface to accelerate rendering-related calculations and then output to something like a VESA driver. We still seem to be pretty far from there though. It is also worth mentioning that actual 3D drivers have always been buggy. Seeing a mess of visual artifacts above or in place of the actual picture still is not and has never been anything unusual when using a driver which utilizes hardware graphics rendering functions. This is what got the idea into my mind in the first place. Too tired of swapping driver versions and hoping for the best. It's been more than 2 decades already and this still happens. Another motivation might be just reducing the chip complexity which might occasionally help in improving power efficiency in some usage scenarios.
- Const-me 5y ago
  What you described is fairly close to how it works on Windows. Vendor-specific GPU drivers don’t implement the complete Direct3D. They only do low-level hardware dependent pieces: VRAM allocation, command queues, and the JIT compiler from DXBC into their proprietary hardware-dependent byte codes (this last one is in the user-mode half of these drivers). Direct3D runtimes (all 3 of them, 9, 11 and 12) are largely vendor-agnostic, and are implemented by Microsoft as a part of the OS.
  - qwerty456127 5y ago
    I see. Thank you. This is curious to know. However, I have tried the Visual Studio 2019 WPF designer on a new laptop recently and it shown black artifacts on the form and complete garbage in place of the components palette. I've installed the graphics driver from the GPU vendor website and that fixed the problem. The driver used before that was a supposedly stable version developed by the same vendor and shipped by Microsoft. This led me to the conclusion there still is a lot of weird hardware-dependent stuff happening under the hood.
    - Const-me 5y ago
      WPF is relatively old tech, built in 2006 on top of DirectX 9.0c and unfortunately stayed that way ever since. Probably that’s why the bug in the GPU drivers went unnoticed. In my experience, in modern world the newer ones like D3D11 and 12 are generally more reliable. If I would be managing the relevant division at Microsoft, I would consider deprecating D3D9 support in drivers and kernel, instead rewrite d3d9.dll to emulate the API in user mode on top of D3D12. Microsoft already did similar trick long ago for OpenGL. Starting with Windows Vista they were emulating GL (albeit very old version of GL) on top of DirectX kernel infrastructure, unless the GPU vendor shipped their own implementation of a newer version of GL. More recently, third-party developers have re-implemented Direct3D 9 on top of Vulkan (which is very comparable to Direct3D 12 feature wise), the results seem good: https://www.reddit.com/r/pcgaming/comments/hirdfp/dxvk_is_amazing_on_windows/ https://www.reddit.com/r/pcgaming/comments/hirdfp/dxvk_is_am...
      - qwerty456127 5y ago
        > rewrite d3d9.dll to emulate the API in user mode on top of D3D12. There seem to be such a project actually, just released to open source: https://github.com/microsoft/D3D9On12 https://github.com/microsoft/D3D9On12 https://devblogs.microsoft.com/directx/open-sourcing-direct3d-9-on-12-and-the-release-of-the-dxbc-signer-nuget-package/ https://devblogs.microsoft.com/directx/open-sourcing-direct3... But it seems you have to actively enable it in the development time, the OS won't just silently do this on itself and I doubt Microsoft or anybody else is going to update their software to do so.

qwerty456127 5y ago

The reason I feel interested in this is it seems we wouldn't need a vendor/model-specific 3D graphics driver in such a case. The vendors could just provide libraries implementing a standardized set of general purpose parallel calculation acceleration functions (e.g. OpenCL) and an app (or a vendor-agnostic 3D driver) would just use the vendor-agnostic interface to accelerate rendering-related calculations and then output to something like a VESA driver. We still seem to be pretty far from there though. It is also worth mentioning that actual 3D drivers have always been buggy. Seeing a mess of visual artifacts above or in place of the actual picture still is not and has never been anything unusual when using a driver which utilizes hardware graphics rendering functions. This is what got the idea into my mind in the first place. Too tired of swapping driver versions and hoping for the best. It's been more than 2 decades already and this still happens. Another motivation might be just reducing the chip complexity which might occasionally help in improving power efficiency in some usage scenarios.

Const-me 5y ago
What you described is fairly close to how it works on Windows. Vendor-specific GPU drivers don’t implement the complete Direct3D. They only do low-level hardware dependent pieces: VRAM allocation, command queues, and the JIT compiler from DXBC into their proprietary hardware-dependent byte codes (this last one is in the user-mode half of these drivers). Direct3D runtimes (all 3 of them, 9, 11 and 12) are largely vendor-agnostic, and are implemented by Microsoft as a part of the OS.
- qwerty456127 5y ago
  I see. Thank you. This is curious to know. However, I have tried the Visual Studio 2019 WPF designer on a new laptop recently and it shown black artifacts on the form and complete garbage in place of the components palette. I've installed the graphics driver from the GPU vendor website and that fixed the problem. The driver used before that was a supposedly stable version developed by the same vendor and shipped by Microsoft. This led me to the conclusion there still is a lot of weird hardware-dependent stuff happening under the hood.
  - Const-me 5y ago
    WPF is relatively old tech, built in 2006 on top of DirectX 9.0c and unfortunately stayed that way ever since. Probably that’s why the bug in the GPU drivers went unnoticed. In my experience, in modern world the newer ones like D3D11 and 12 are generally more reliable. If I would be managing the relevant division at Microsoft, I would consider deprecating D3D9 support in drivers and kernel, instead rewrite d3d9.dll to emulate the API in user mode on top of D3D12. Microsoft already did similar trick long ago for OpenGL. Starting with Windows Vista they were emulating GL (albeit very old version of GL) on top of DirectX kernel infrastructure, unless the GPU vendor shipped their own implementation of a newer version of GL. More recently, third-party developers have re-implemented Direct3D 9 on top of Vulkan (which is very comparable to Direct3D 12 feature wise), the results seem good: https://www.reddit.com/r/pcgaming/comments/hirdfp/dxvk_is_amazing_on_windows/ https://www.reddit.com/r/pcgaming/comments/hirdfp/dxvk_is_am...
    - qwerty456127 5y ago
      > rewrite d3d9.dll to emulate the API in user mode on top of D3D12. There seem to be such a project actually, just released to open source: https://github.com/microsoft/D3D9On12 https://github.com/microsoft/D3D9On12 https://devblogs.microsoft.com/directx/open-sourcing-direct3d-9-on-12-and-the-release-of-the-dxbc-signer-nuget-package/ https://devblogs.microsoft.com/directx/open-sourcing-direct3... But it seems you have to actively enable it in the development time, the OS won't just silently do this on itself and I doubt Microsoft or anybody else is going to update their software to do so.