Hello Lukas, I'm not a llmpipe developer, but I think the place for this discussion is on the Mesa gitlab. Feel free to open an issue about this there or better yet, submit a merge request with your proposed fix.
Best regards, Timur <li...@luckyxxl.de> ezt írta (időpont: 2023. febr. 19., Vas 12:10): > 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 > >