[unsigner]

That's amazing!

What does the API look like? I see you're calling it FuryGL so it must have some roots in OpenGL? What did you have to change because of the underlying hardware? compared to OpenGL? Compared to what a software rasterizer API would look like? You probably are familiar with Glide?

[PfhorSlayer]

It's actually modeled very closely after Vulkan, but I couldn't think of a clever re-wording that would fit that and "Fury" together. I would have taken Vulkan's API as-is, but the hardware itself is fixed-function and does not support shaders, which Vulkan's API takes for granted; if you've seen Vulkan applications, it's nearly identical except that the pipelines do not include shaders. The way Vulkan (and D3D12) build and submit command buffers very closely matches how the hardware actually works, so it felt like a good fit.

If the hardware were ever to support actual shaders, I would be writing a full D3D-driver stack for it as Windows would then be able to utilize the GPU as a "real" GPU, rather than as just a display controller. As things are now, Windows has no idea that the device can do anything other than display a pre-composited desktop. When an application wants to utilize its 3D rendering capabilities, the driver actually does a mode swap similar to how the old Voodoo cards used to work - the OS still thinks it's rendering the desktop, but the hardware is actually displaying the application's content.

[uis]

I guess in Linux it would be so much easier. KMS for modswitching and DRI for 3d stuff.