sebbbi/NoGraphicsAPI

> If the driver is optimally designed, this shouldn't be notably more work than changing the firstIndex in the draw call and should be faster than standard index buffer bindings (that needs to access the buffer object).

yeah I don't expect there to be notably more work in the no-validation path, and I'm assuming that all the draw call arguments remain

the only extra work I expect could be the validation on the pointer/size (e.g. alignment, and whether it exists within a known heap), and writing the same address to the command buffer a bunch of times, given that the offset would be mostly controlled by firstIndex

on the other hand, pointer validation in a pointer-heavy API might just be too slow to be practical

all that said, there is another question in the opposite direction - should firstIndex exist at all, given that the raw gpu address basically does everything firstIndex can do, and more? it seems one could replace it with a function that calculates a subrange from a gpu range

Index buffer concerns: Normally the driver calculates index GPU address using index buffer address + buffer binding offset + draw call's firstIndex. This is what happens on every draw call. You can change the firstIndex, and the effective index buffer GPU address changes. Now we instead set the GPU pointer directly. There's no buffer object involved (buffer address + binding offset). If the driver is optimally designed, this shouldn't be notably more work than changing the firstIndex in the draw call and should be faster than standard index buffer bindings (that needs to access the buffer object). So I don't think there's a reason to add a new API for setting the index pointer. That would also be stateful. Previous state leaks to next draw or even next pass. One of the worst OpenGL design flaws. I prefer setting all data at once. But we should definitely benchmark it.

I will close this bug now, since I think most of the concerns have been solved. If you like, you can open up VK_EXT_s...

https://github.com/sebbbi/NoGraphicsAPI/commit/c2ac263a3bf3e45f4c6ab722a17a36f94023329e separates depth/stencil and viewport/scissor from the PSO. Getting closer to the blog post.

VK_EXT_shader_object investigation next week. There's a potential performance hit. So far I have been aiming for optimal performance. Need to benchmark it before committing to it.

The current prototype doesn't have dynamic state. That is indeed super important to fix ASAP. Dynamic stencil/scissor will be the first ones to add. Burning those to the PSO has always been a stupid idea. Of course we want all Vulkan 1.3 dynamic state, since all of them reduce the PSO bloat, which is an important goal.

I will check VK_EXT_shader_object coverage. It seems promising addition.

Delete queue has already been refactored. It's now in the helper library. I will check for accidental leftover code.

Codex wrote the GpuCpuRange, I personally always use byteSize or similar to ensure people know the element type.

Thanks for the feedback! These are all valid points. I will fix next week!