Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation Error Fixes #886

Merged
merged 13 commits into from
Feb 6, 2025
Merged

Validation Error Fixes #886

merged 13 commits into from
Feb 6, 2025

Conversation

jaremieromer
Copy link
Member

@jaremieromer jaremieromer commented Feb 5, 2025

closes #850

Outline:

Fix the validation errors introduced with the post process work.
There were two primary validation errors emitted every draw call:

  1. The texture array resources had uninitialized image views bound to the pipeline.
  2. The texture array resources had image views that were in different states within a single descriptor (SHADER_RESOURCE vs RENDER_TARGET)

Details:

To fix 1, a 1x1 pixel texture was default initialized to fill the entire array for each texture array resource.
To fix 2, the root cause was that a texture array is considered a single descriptor. All elements in the descriptor must have the same state (SHADER_RESOURCE vs RENDER_TARGET).

So, the fundamental design we were using for Post Process textures of:
-Bind the entire texture_array as SHADER_RESOURCE.
-Bind texture_array[0] as RENDER_TARGET.
-Render the post process pass [0] to texture_array[0].
-Bind the texture_array[0] AS SHADER_RESOURCE.
-Bind texture_array[1] as RENDER_TARGET.
-Use texture_array[1] as RENDER_TARGET while reading texture_array[0] as SHADER_RESOURCE.

Was causing this error, because you cannot have subresources in different states.

The fix was to create a SinkBufferResource for every post process pass. This is done dynamically by creating a single new SinkBufferDesc in ShaderBindings, and hijacking the Max Resources value. We create one SinkBufferResource (each with a single element) per count up to Max Resources.
However, there is only one SinkBufferResource in the PipelineResourceSignature, because we will only every bind one SinkBufferResource as a SHADER_RESOURCE at any given time. The SinkBufferResource is a dynamic variable, so each time the post process pass requires a different SinkBufferResource as a SHADER_RESOURCE, we dynamically change the variable that the PipelineResourceSignature is pointing to.

The new design is similar to:
-Initialize the Color and Depth Sink arrays as RENDER_TARGET
-Do all the non-post process rendering
-Bind the entire Color and Depth Sink arrays as SHADER_RESOURCE
-Render the post process pass [0] to post process sink buffer 0.
-Bind post process sink buffer 0 as SHADER_RESOURCE
-Render the post process pass [1] to post process sink buffer 1 while reading post process sink buffer 0 as SHADER_RESOURCE.
(Not using element notation for post process sink buffer as they're not a single array, but unique resources)

Cleanup:

Since I was up in the passes anyway, I cleaned up and unified the implementations of all the pass creation backends. Eventually we can move these out to helper methods, but that was out of scope of this PR. For now, all the logic that is exactly the same across pipeline creation is organized next to each other so we can eventually cut these out into shared methods. Got rid of all the factory stuff for each different pass type, all is unified across passes so its all in the pass constructor.

I also changed how PassBackend was acquiring render target indices by extracting that logic out into PassManifest rather than having it be scattered throughout PassManifest and PassBackend.

I also changed the PassDesc interface to add a "useDepthTest" parameter, and changed the ColorTarget/DepthTarget/PostProcessTarget (new) specified in the PassDesc to be enums.

I also greatly simplified the BindRenderTarget and ClearRenderTarget interfaces.

@jaremieromer
Copy link
Member Author

Looks like the Linux Runner is broken, the https://sdk.lunarg.com/sdk/download/1.3.261.1/linux/vulkan-sdk-linux-x86_64-1.3.261.1.tar.gz?Human=true is a dead link.
I can take a look tonight

Copy link
Member

@McCallisterRomer McCallisterRomer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wowzer, nice job!

@jaremieromer jaremieromer merged commit 7a9a710 into vnext Feb 6, 2025
10 checks passed
@jaremieromer jaremieromer deleted the jare-validation-fixes branch February 6, 2025 15:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Address Validation Errors in CI
2 participants