Open thatcosmonaut opened 1 month ago
We should document the legacy mode and limitations in the header in the category introduction.
Does this open the door for different Android devices, or is that orthogonal to this?
This would be orthogonal to Android - 11_0 has consistent support requirements but Android feature support is all over the place. I'd like to avoid putting clients in a position where they have to query support for everything they might want to use.
We are also targeting the 11_1 feature set in the 11 implementation right now, which is awkward - just about anything that supports 11_1 will have a Vulkan driver available too.
Not that it really matters a ton, but I think Haswell/Broadwell GPUs would fall into that bucket of FL 11_1 without Vulkan support. Intel only implemented Vulkan support for Skylake and later.
Oh interesting. But yeah I don't think it matters much because those will still benefit from legacy mode.
Out of interest, is there anything in particular that SDL3 requires from the 11_0 feature set that's not available in older ones?
Older than 11_0 and you're down to 1 UAV slot which is not great.
Right now GPU implements Vulkan, Metal, D3D12 and D3D11 backends. Out of these APIs D3D11 is the odd one out because it has awkward support for command buffers. Why do we support it?
The main reason is there is a surprising number of hardware still in use that only supports the D3D 11_0 feature set, and doesn't support anything newer than that. However, this feature set imposes artificial limitations on the newer APIs since we want features to work everywhere. We are also targeting the 11_1 feature set in the 11 implementation right now, which is awkward - just about anything that supports 11_1 will have a Vulkan driver available too.
My proposal is that we implement a flag on CreateGPUDevice called "legacy mode". The intention of legacy mode is that you will enable it if your application is interested in supporting older low-spec hardware and doesn't require the small amount of higher-end features that the mode will disable. This mode will target the 11_0 feature set specifically and impose those limitations on the feature usage. This will also be the only mode where we ever select the 11 backend - if your device supports a newer API, we should always be selecting one of those instead anyway.
This should be pretty unintrusive overall. We will simply return an error for the client in validation mode if they enable legacy mode and call a function that isn't supported in legacy mode or exceed the limits. The main restriction of legacy mode as of right now will be lowering of the maximum sampler and storage read resource targets per shader. This will also open the door for us to enable advanced features that have spotty support in 11, like fragment resource writes, without totally ditching compatibility for older hardware.