Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

partial updates to buffers/textures (e.g. offset and size args to glBufferSubData, glTexSubImage) #1075

Open
digitalsignalperson opened this issue Jul 7, 2024 · 1 comment

Comments

@digitalsignalperson
Copy link

digitalsignalperson commented Jul 7, 2024

sg_update_buffer lets you replace the entire buffer, but there are times you only want to e.g. update one row or one section of a buffer or texture between frames.

sg_append_buffer is close by letting you update parts of the buffer at a time, but uses buf->cmn.append_pos so you can only update in small parts sequentially from the buffer start to finish

Possible solutions:

  • provide a method to increment or set buf->cmn.append_pos to an arbitrary offset (helps buffers only, not images)
    • maybe: in sg_append_buffer, if the passed sg_range has a non-zero .size but a null .ptr, then interpret this as "move append_pos forward but don't update the buffer"
  • add functions like sg_sub_buffer(), sg_sub_image()
  • add extra args to sg_update_buffer() and sg_update_image (breaking change)
@floooh
Copy link
Owner

floooh commented Jul 7, 2024

I have a complete rewrite of the resource update functions in mind that would basically look like the WebGPU update functions (e.g. write from CPU to GPU memory, copy between two GPU resources, and possibly copy from GPU memory to CPU memory) - no ETA for that yet though.

Main problem is that this orthogonal resource update API would almost definitely introduce lock-stalls on the OpenGL backends (GL is the main reason for the currently very restricted update and append APIs - end even sg_append_buffer() is making trouble on WebGL, so it's not recommended to use).

Until then the currently recommended workaround is to keep a shadow copy of the resource content in CPU memory, apply partial updates to this shadow copy, and then update the entire resource from the shadow copy - this might even be the best solution after the above mentioned API change in order to avoid lock-stalls on GL backends.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants