bkaradzic/bgfx

Dynamic vertex buffers getting overwritten after bgfx::update

oxheron opened this issue · 19 comments

oxheron commented

Describe the bug
Some dynamic vertex buffers get partially over written with invalid data after 2+ calls of bgfx::update on the buffer, with each call adding 1 vertex layout's worth of data to the buffer. This then causes the things that these buffers are used for to not work properly. However, if bgfx::update is called once it seems to work properly, and the last call to bgfx::update also produces valid data for that section of the buffer. But previous sections may/do become corrupted. Also, doesn't happen with every type of vertex buffer, as the vertex buffer doesn't end up corrupted (it is pre allocated and has much large writes with many vertices being submitted)

To Reproduce

  1. Create a dynamic vertex buffer of size 0, that is rewritable, with any vertex layout.
  2. Call bgfx::update(buf, 0, bgfx::makeRef(, vertex_layout.getStride());
  3. Call bgfx::update(buf, 1, bgfx::makeRef(, vertex_layout.getStride());
  4. Then, if you try and use the buffer for anything the first part of the buffer will be corrupted.

Expected behavior
The buffer has the proper data, and doesn't end up having corrupted data in it.

Screenshots
Screenshot_20230707_152641

If a renderdoc capture is wanted I can provide it.

Additional context
Vulkan & Archlinux.

bkaradzic commented

Please create repro by modifying some existing example.

oxheron commented

how to build the examples?

bkaradzic commented

Any luck with repro?

oxheron commented

Sorry I've been gone for the past day ish. I should have it working by tomorrow

oxheron commented

Don't know if ill have time today.

  • 👍1
bkaradzic commented

Whenever you can.

oxheron commented

As i was trying to get the bug to work it ends up crashing on a call to bgfx::update() because of the fact that the initial memory size is for the buffer is 0, even though BGFX_BUFFER_RESIZEABLE is set. I don't know if this is intentional or not, and it might be connected to the original bug. I haven't been able to get the original bug to work in a simple example yet. If I cannot get it to work after a bit more playing ill probably just upload my code (with the bug).

Here is a link to a repo with the example code (just cloned bgfx and it is example 50 but it is in the example 5 folder). https://github.com/0xheron/bgfx

bkaradzic commented

Also you're using bgfx::makeRef with data that's on the stack, which is incorrect too. You should use bgfx::copy instead.

bkaradzic commented

Also you're not releasing dynamic vertex buffer you're creating, which will cause leak.

oxheron commented

Thats just me being stupid then. That being said, on my code the bug still occurs with a fixed size.

oxheron commented

Oh, because I couldn't figure out the build system I ended up hacking one of the existing examples for the last 2 points. However i still am using 0 which is the main focus of this. (example 5)

oxheron commented

Also, the code that in my case causes the bug (could just be my fault again, but i have tried a few things) is here.
https://github.com/0xheron/engine

oxheron commented

134 & 135 are the lines of the bgfx::update call.

bkaradzic commented

Everything you need to know about build system is explained here:
https://bkaradzic.github.io/bgfx/build.html#getting-source

It's fine that you used existing example. You should just make it correct, so that repro of your issue you're claiming exist is focused only on the issue.

oxheron commented

Just out of curiosity, did you look at it anymore with some of the resources I sent? Also, sorry for not doing more with repro as I did fail to get a replicated copy of the bug and because I had a solution I didn't do anymore. Thanks for your time.

bkaradzic commented

I sent you my feedback here: #3126 (comment)

oxheron commented

Of the repro? Because that never demonstrated the bug I initially talked about. That was my bad as I rushed to finish it. However, after the fact I was still never able to replicate the bug in the repro context. At a certain point I decided it didnt matter for my case. However, it may affect someone else. The repo I posted, with a pretty self explanatory build system does demonstrate this bug, in case you want to look at it further.