Fixing vkCmdDrawIndexedIndirect with index buffer offset for llvmpipe

[lists at luckyxxl.de]

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