godot icon indicating copy to clipboard operation
godot copied to clipboard

Add Conservative Rasterization support to RenderingDevice

Open Lateasusual opened this issue 1 year ago • 5 comments

This adds a new option enable_conservative_rasterization to RDPipelineRasterizationState.

In Vulkan this is implemented with VK_EXT_conservative_rasterization (which is optional). In D3D12 no extra device options are needed.

Conservative Rasterization is not supported on all hardware (Metal, most mobile GPUs), currently no method is exposed to check for availability (this could be added as a RenderingDevice::Features flag, but these aren't exposed to user code anyway). Enabling conservative rasterization on unsupported hardware is a no-op.

Closes: https://github.com/godotengine/godot-proposals/issues/10927

Example project for testing

Lateasusual avatar Oct 07 '24 14:10 Lateasusual

Conservative Rasterization is not supported on all hardware (Metal, most mobile GPUs), currently no method is exposed to check for availability (this could be added as a RenderingDevice::Features flag, but these aren't exposed to user code anyway). Enabling conservative rasterization on unsupported hardware is a no-op.

See also https://github.com/godotengine/godot/pull/76073, which exposes an option that is also limited to non-Apple platforms (in fact, it's even more limited as per-sample shading doesn't exist on D3D12).

Calinou avatar Oct 07 '24 14:10 Calinou

See also #76073, which exposes an option that is also limited to non-Apple platforms (in fact, it's even more limited as per-sample shading doesn't exist on D3D12).

I see. Since this is a very low level option I figured it would fall more into the category of support of e.g. line width, specific texture formats, etc. which also have varying support on different hardware. (Line rendering width specifically is relevant since AFAIK a lot of alternatives to implementing conservative rasterization require it, so even the workarounds are limited to certain hardware either way)

And as you say, compared to per-sample MSAA shading the support for this feature is a lot broader (should be supported on all Nvidia, AMD, and Intel GPUs on win+linux as far as i can see from a glance at gpuinfo)

Lateasusual avatar Oct 07 '24 15:10 Lateasusual

Added a test/example project to the PR description.

image

Lateasusual avatar Oct 07 '24 15:10 Lateasusual

And as you say, compared to per-sample MSAA shading the support for this feature is a lot broader (should be supported on all Nvidia, AMD, and Intel GPUs on win+linux as far as i can see from a glance at gpuinfo)

Where did you get the information that this extension is supported on all NVidia, AMD, and Intel GPUs on Win + Linux? GPUInfo shows 40% coverage. There appears to be plenty of recent reports of devices not supporting this extension too https://vulkan.gpuinfo.org/listdevicescoverage.php?extension=VK_EXT_conservative_rasterization&platform=windows&option=not

clayjohn avatar Oct 07 '24 17:10 clayjohn

I may have been a bit quick to assume that most of the reports of it not being supported were on old drivers.

I do think for exposing lower level optional features like this maybe it would be worth it to establish a better way to check for support in higher level/user code. RenderingDevice provides really quite a good (maybe not perfect) abstraction as a graphics API in its own right IMO and i think optional extensions would be good for people using it in that way. (And moreso in future with mesh shaders or raytracing extensions)

Also as mentioned in the proposal, this specifically would be useful for GPU-ifying VoxelGI baking - although now i think if a workaround is going to be needed anyway to support all platforms, that's not really a good enough reason to justify this extension alone.

Lateasusual avatar Oct 07 '24 18:10 Lateasusual