I don't understand the concept

[RDS5]

Disclamer: I am NOT a graphics developer. Most of my knowledge in this space is out of pure curiosity from adjacent projects.
Everything said here is my best interpretation of kernel API documentation & Mesa, but I have never used these APIs in practice.

From what i can tell (correct me if im wrong), you're trying to create an ENTIRE directX driver using only DRM to "abstract" things away.

You do realize DRM (afaik) doesn't expose an "abstracted GPU" right?
It only exposes a common memory management/object creation/etc.. API
The actual GPU assembly code for drawing objects and advanced functions is still handled by userspace drivers like.. MESA!!

From what i can tell, this project is essentially an attempt to reinvent the wheel, also known as Gallium9.
Why not build on Gallium9 & Mesa's advanced GPU support?
You wouldn't go through any additional layers; DirectXprog.exe(DX9) -> Mesa/Gallium(Compiles the shaders) -> DRM(iHD assembly, for example)

Windows GPU drivers (on a high level, atleast) work the same way, ie:

iHDkernel.sys driver manages memory allocation and such (in practice, this would be something like igdkmd64.sys)
iHDuserspace.dll compiles your shaders for the kernel driver
Your userspace program hooks in the iHDuserspace.dll and sends it's DXyy calls through it, which then sends the calls through the custom API iHDkernel.sys exposes

Linux is better than this, since the APIs a theoretical "iHDkernel.ko" must expose are standardized, facilitating userspace driver creation (and simple fb drivers).
Atop that, the community now uses Mesa as a common base for all it's userspace drivers, so we can all share quality OpenGL/Vulkan parsing logic together. (and more, hence the Gallium "layer". It's a way to expose GPU logic in a generic way so multiple frontends (ie. OGL, VK) can call into the same GPU driver. It is a bit of a "Vulkan-for-your-driver" kinda thing, but under most drivers, it runs natively)

On Windows, Intel, NVIDIA and AMD all struggle to create their own parsing logic and internal object management while on linux we benefit from each other's work. So why are you trying to, essentially, reinvent Mesa? (rather than just creating a mesa frontend)

[warriormaster12]

Then there's dxvk-native which already does exactly what this project tries to achieve since developers still have to go through compiling the project for linux.

[warriormaster12]

I see what's happening in here 5f6e101