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

VDR: Fix vertex offset in indirect draw calls #1984

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

panos-lunarg
Copy link
Contributor

No description provided.

@ci-tester-lunarg
Copy link

CI gfxreconstruct build queued with queue ID 354749.

@ci-tester-lunarg
Copy link

CI gfxreconstruct build # 5917 running.

@ci-tester-lunarg
Copy link

CI gfxreconstruct build # 5917 passed.

@@ -1553,9 +1558,14 @@ VkResult DrawCallsDumpingContext::DumpVertexIndexBuffers(uint64_t qs_index, uint
abs_index_count = indirect_index_count + indirect_first_index;
}

if (greatest_vertex_offset < i_params.draw_indexed_params[d].vertexOffset)

Choose a reason for hiding this comment

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

should the vertex offset not be stored along in index_count_first_index_pairs (well, not as pair, but as struct or tuple)?
Would be much shorter and not need this min/max computation and be more precise.

@hongSARC
Copy link

So if I understood what the code is doing correctly, in FindMinMaxVertexIndices function, you are processing the index buffer to find the minimum and maximum indices used in the range of the index data.
This function takes into account the index count and the first index, and computes the min and max of the indices.

Then, you are adding the vertex offset to the min and max values for the index range.


When you add different offsets to the min and max, you essentially expand the range incorrectly, as you are applying two different offsets. You should be applying a single vertex offset to both the min and max values.

The offsets you add should be uniform for both min and max, based on the range of indices you are processing.

I think it should calculate the min and max indices first then apply the vertex offset for that specific draw call to the indices. Then track the overall min and max indices across all draw calls comparing the adjusted values.

@panos-lunarg
Copy link
Contributor Author

So if I understood what the code is doing correctly, in FindMinMaxVertexIndices function, you are processing the index buffer to find the minimum and maximum indices used in the range of the index data. This function takes into account the index count and the first index, and computes the min and max of the indices.

Correct.

Then, you are adding the vertex offset to the min and max values for the index range.

When you add different offsets to the min and max, you essentially expand the range incorrectly, as you are applying two different offsets. You should be applying a single vertex offset to both the min and max values.

The offsets you add should be uniform for both min and max, based on the range of indices you are processing.

I think it should calculate the min and max indices first then apply the vertex offset for that specific draw call to the indices. Then track the overall min and max indices across all draw calls comparing the adjusted values.

I think I understand what you mean and I think you are right. I updated the patch accordingly

@panos-lunarg panos-lunarg force-pushed the vulkan_dump_resources_fix_vertex_offset_for_indirect_draw_calls branch from 00c42d9 to bcc5726 Compare January 29, 2025 08:44
@ci-tester-lunarg
Copy link

CI gfxreconstruct build queued with queue ID 359227.

@ci-tester-lunarg
Copy link

CI gfxreconstruct build # 5961 running.

@ci-tester-lunarg
Copy link

CI gfxreconstruct build # 5961 passed.

@hongSARC
Copy link

Could you also pass the original binary file offset? (bufferOffset)

The vertexOffset is relative to the buffer segment for that draw, but the actual data in binary file may be in different location.
I'll need that bufferOffset to correctly subtract or add it when reading vertex data, ensuring that the offsets match the actual memory layout. Then I can properly adjust the vertex positions when parsing.

@panos-lunarg panos-lunarg marked this pull request as ready for review January 30, 2025 07:24
@panos-lunarg
Copy link
Contributor Author

Could you also pass the original binary file offset? (bufferOffset)

What do you mean with bufferOffset? Do you mean the offsets used in vkCmdBindVertexBuffers, vkCmdBindIndexBuffer and co?

@hongSARC
Copy link

hongSARC commented Jan 30, 2025

No, I'm looking for the absolute offset within the original binary file where the vertex buffer data starts. (I just referred as "bufferOffset")
This would allow me to correctly calculate the memory layout and adjust the vertex positions when parsing. The vertexOffset provided is relative to the buffer segment, but I need to know the starting point within the binary file to properly read the data.
Otherwise, I'll need to reconstruct it using buffer bindings (I think), which is more complex..

Maybe within the "parameters" or inside "vertexBuffers in api json? (fileOffset is what I meant. We need to have for both index buffer and vertex buffer file offset to handle indirect draw calls since it contains multiple draws I need to parse.)
example)

"indexBuffer": {
  "bufferId": 2145,
  "file": "indirect_indexBuffer_qs_2167_bcb_2094_dc_2103_uint16.bin",
  "fileOffset": 4
},
"vertexBuffers": [
  {
    "bufferId": 2144,
    "vertexBufferBinding": 0,
    "file": "indirect_vertexBuffers_qs_2167_bcb_2094_dc_2103_binding_0.bin",
    "fileOffset": 20
  },

Here are the steps of my parsing, (FYI)
-Use firstIndex and indexCount to get the indices array from the index buffer.
-Use the vertexOffset (relative to the buffer segment) along with the "bufferOffset" (absolute offset within the binary file) to calculate the correct starting point for the vertex buffer.
With the correct starting point, I can then parse the vertex buffer using the calculated offset.

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.

3 participants