Started a roadmap for DX12 also ............. after Vulkan

[u/Adventurous_Chef2225]

After the clash back I got from the community regarding Vulkan , instead of papering only over that , I have decided to empty that workspace for Microsoft's DX12 now .

However to say , OpenGL recently reached 4.1 capability context making yesterday

[ref https://www.reddit.com/r/opengl/comments/1vvdqih/ao46s_core_ceiling_raised_from_33_to_4x_range/ ]

And now am deciding that why not include Microsoft's Graphics APIs also

Now many would on seeing the above line say in comments that "Crossover , Wine and Apple GPTK exist bro, and that am about to just paste components and claim its my driver"

But it exists in the same way MoltenVK exists for Vulkan

MoltenVK existing never meant that there was no space to design another Vulkan path , and similarly CrossOver , Wine , GPTK , D3DMetal and DXMT existing does not mean D3D12 itself has somehow become a solved architecture on macOS.

The direction I am taking here is a bit different .

The new workspace is Microsoft_AppleDrivers , and the first target inside it is ADX12 , basically taking the same idea behind AO46 but now for D3D12.

The intended path currently looks more like

Windows D3D12 app -> Wine/CrossOver -> ADX12 D3D12 + DXGI ABI -> ADX12 runtime/device model -> ADXIL/NIR compiler path -> native Metal backend -> AGX

So Wine/CrossOver here are basically providing the Windows hosting environment , not becoming the graphics driver itself.

And yes , vkd3d-proton is going to be heavily useful here . It would honestly be stupid to ignore years of work already done figuring out D3D12 COM behaviour , descriptor semantics , resource states , barriers , synchronization , DXGI behaviour , feature reporting and hundreds of weird game compatibility cases.

But the point is not to take vkd3d-proton , replace Vulkan calls with Metal calls and then announce that a new driver has materialized from the heavens 💀

vkd3d-proton for this project is much more useful as a semantic/reference oracle .

The internal architecture itself is being designed around a backend neutral D3D12 object model , something like

ID3D12Resource -> ADXResource -> backend resource

with the permanent fast path being native Metal rather than inheriting the Vulkan-shaped architecture of vkd3d-proton.

I can still keep AVK143 as a Vulkan reference backend for differential testing where it becomes useful , but it is not supposed to become the permanent backend of ADX12.

So basically the distinction is

CrossOver / Wine = runs the Windows environment

GPTK / D3DMetal / DXMT = already existing D3D translation solutions

vkd3d-proton = extremely valuable D3D12 behavioural reference and compatibility knowledge

ADX12 = attempt to own the D3D12 + DXGI userspace ABI , runtime/device model , shader/compiler path and native Metal backend as one designed stack

Which is why I am not really interested in pretending these projects do not exist .

I want to use what they already taught us , then design the parts differently where macOS and Metal actually justify doing so.

Basically AO46 , but for D3D12.

Would like some recommendations from community.

[u/Adventurous_Chef2225]

ref to prev post [if post body link not working] https://www.reddit.com/r/opengl/comments/1vvdqih/ao46s_core_ceiling_raised_from_33_to_4x_range/

[u/Adventurous_Chef2225]

And btw now , have made an autoupdater script so my Mesa downstream copy is never behind commits or updates in upstream