Closed floooh closed 6 months ago
Oh, are you planning to eventually support compute shaders, on selected backends? That would be absolutely amazing, it's probably the number one feature I'm missing in sokol_gfx right now. Especially now I've moved on to 3D graphics. The storage buffers seem like a good first step!
Yes, compute shaders is planned afterward for the next 'big update' after this initial storage buffer support update. I need to come up with a 'resource barrier strategy' though, I'll most likely take WebGPU as a blueprint.
This is great milestone, thank you! (I can finally stop abusing uniforms for that 🙈)
Amazing work, thank you for this update.
First step will introduce storage buffers without compute shaders. This allows more flexibility for providing random-access data to the GPU (e.g. replacing float textures as 'poor man's storage buffers').
To investigate:
Allow multiple bind points? (e.g. allow to bind as storage buffer, but also as vertex buffer) => means getting rid of 'buffer type' in favour of 'bind flags'=> not initiallyD3D11: when is using an UnorderedAccessView instead of a regular BufferView required?vs ReadWrite vs WriteOnly storage buffers? Possible to write to StorageBuffers without compute shaders?=> possible but non-trivial, initially only support readonly buffers, writing from vertex- oder fragment-shaders requires resource barriers even in OpenGL. Delay until compute shader support.Add a special flagsg_buffer_desc.d3d11_structured_buffer
as fallback to allow using more convenient StructureBuffer in shader? Does this require providing the element size when creating the shader resource view?TODO:
sg_environment
.sbuftex-sapp
on my NVIDIA RTX 2070 Win10 PC across WebGPU, D3D11 and OpenGL (fixed, turned out to be a precision problem when converting between float and integer which only seems to manifest on NVIDIA)cleanup=> not worth the hassleSG_BUFFERTYPE_*
naming? (e.g.SG_BUFFERTYPE_VERTEXBUFFER
=>SG_BUFFERTYPE_VERTEX
)?SOKOL_GLCORE33
=>SOKOL_GLCORE
sg_environment.gl
shader-write to storage buffergl_InstanceID + SPIRV_Cross_BaseInstance
(fixed: SPIRVCross has options for that)figure out how to deal with write/read barriers for storage buffers, e.g. https://registry.khronos.org/OpenGL-Refpages/gl4/html/glMemoryBarrier.xhtml, conservative solution: issue a barrier after each draw that involves writable storage buffers.=> defer storage buffer write support into a followup update since it comes with a couple of problems that need solving: