Fixing vkCmdDrawIndexedIndirect with index buffer offset for llvmpipe
lists at luckyxxl.de
lists at luckyxxl.de
Sun Feb 19 11:02:42 UTC 2023
Hello everyone,
newbie to the Mesa codebase here.
I found that in the current main branch the llvmpipe Vulkan driver does
not produce correct results for `vkCmdDrawIndexedIndirect` when the
preceding call to `vkCmdBindIndexBuffer` passed a non-zero value for
`offset`. I poked around in the code a little bit, found that the
`offset` parameter is just not used at all for indirect draws and came
up with the following two solutions to fix my usecase:
1)
https://gitlab.freedesktop.org/luckyxxl/mesa/-/commits/fix_indirect_draw_ib_offset1
While this is a pretty minimal change I don't think it's a good one.
Adding `index_offset` to `struct pipe_draw_indirect_info` feels like a
hack. Also it will fail silently when `offset` is not a multiple of the
index type size, which is valid according to the Vulkan specification.
2)
https://gitlab.freedesktop.org/luckyxxl/mesa/-/commits/fix_indirect_draw_ib_offset2
While this one adheres the Vulkan specification in that any value for
`offset` is supported, I feel like it is a fairly large/risky change.
`struct pipe_draw_info` is used throughout the codebase in various
utility functions and drivers, and I can't judge how big the impact of
the suggested change would be. Also, it seems to me that the code of
many drivers should be updated to handle the new parameter, though that
might not be necessary given that the new behavior cannot be triggered
via the OpenGL API (see below). How would such a global change be
handled if it's worth proceeding-on?
The issue can only be triggered using the Vulkan API, given that there's
no way (at least none that I know of / could find) to use an offset into
the index buffer for indirect draws with the OpenGL API. Therefore I
think that some changes to core data-structures/algorithms are necessary
in order to be able to implement the fix, unless I oversaw something. I
would be glad if someone could advise on how to proceed: Does it look
worth to you to try to upstream one of the two suggested fixes? In that
case I'd be happy to write a proper PR. Or is the issue better worked-on
by a developer who is experienced with the code, in that case I'll
gladly file an issue and provide a repro. Also, as a final feedback, is
this mailing-list the correct place to discuss such a matter, or would
that better be done in a PR or via IRC?
Thank you for your time :)
Lukas
More information about the mesa-dev
mailing list