sokol_gfx.h: Feature request fragment-writeable storage buffers
Hi there!
Since I needed to write to SSBOs from fragment shaders, I made a small "extension" that allows this feature, and was wondering if it's something that you'd be willing to have in mainline sokol_gfx.h.
I only implemented the Metal & OpenGL backends for now as those are the ones I have testing access/experience with.
Is this something you'd consider including, or is there some backend where this would be nonsense? I could try to start a PR if so, but I'd only be able to provide these two backends.
Example use case:
Imagine a noise shader that writes to specific fragments depending on the function evaluation and one needs feedback about this, rather than using a full channel just for that or using MRT that would force having the same resolution, one might choose to break up the frame buffer into "buckets" of a smaller size and use an atomic array to mark them as written (maybe the exact pixel written is not as important as "this bucket was touched", to avoid a full same-resolution-as-fbo CPU scan over each pixel after transferring this storage buffer to CPU)
The "extension" itself would be literally a 1 function one (so it can't quite be called an extension) if it wasn't that as part of this implementation I also had to write a "make storage buffer" extension that allows creating the (storage) buffer but also filling it with initial data (internally calls sg_make_buffer() but then calls glBufferSubData/memcpy to the MTLBuffer raw bytes) as when using this kind of buffers it's important to be able to pre-fill them with data (in the above example it'd be with zeroes, we can't let gibberish be the default state, specially when there isn't a clear rule for when data isn't written due to the value depending on an evaluated shader whose pixel value outcomes will depend on a number of things...) and another GPU>CPU readback as in OpenGL one has to specify GL_SHADER_STORAGE_BUFFER when reading it back (I should really bundle this support into my transfer extension and remove it from here, I might do actually)
The extension itself works ok, my concern is that the OpenGL side seems a bit more flimsy, as I have to internally fiddle with Sokol's gl cache by calling _sg_gl_cache_bind_storage_buffer, the Metal one, being straight up calls to setVertexBuffer/setFragmentBuffer seems more resilient to underlying change on the surface.
Thanks as always for the sokol libs!
Source: floooh/sokol