Hello there,
I want to write some data in my fragment shader and later read that data with the cpu. I have the whole thing working with a SSBO but SSBOs are not available with opengl 3.3. So is there any similar way to achieve this in opengl 3.3?
Thank you in advance
The only similar functionality is image load/store, which is OpenGL 4.2. However, gpuinfo.org has a handful of reports of ARB_shader_image_load_store being supported by OpenGL 3.3 systems (specifically, AMD Radeon HD 3450, 3800 and 4800), whereas the only reports of ARB_shader_storage_buffer_object being supported on 3.x are for Mesa (which may correspond to the period when Mesa only supported 3.x on 4.x-class hardware).
So it may be worth checking for the ARB_shader_image_load_store extension on 3.3 systems and using that if available.
Okay I will look into that. Thanks.
Also I’m using glNamedBufferStorage and glMapNamedBufferRange to map my buffer persistently. These functions are available when OpenGL 4.5 or ARB_direct_state_access is supported.
But what if OpenGL 4.4 and ARB_buffer_storage is not supported. Is that possible? And can I use glNamedBufferStorage in such a situation?
No, nor glBufferStorage(). You’ll need to read the buffer contents through some other means. Such as:
glGetBufferSubData(),glMapBufferRange()to map the buffer for read non-persistently,- write the data to a fragment output channel (e.g.
gl_FragData[n].w) and read it back from there, - etc.
It’s also important to consider the difference between “possible” and “likely”.
OpenGL 4.x contains specific features that require hardware improvements compared to 3.x hardware. Tessellation, etc. The only GPUs that will support it are those that support those specific pieces of hardware functionality.
Direct state access is an extension. ARB_direct_state_access was an extension released alongside GL 4.5’s release.
However, in order to support ARB_direct_state_access, something else has to happen: the implementation has to have been written after the extension debuted. Yes, there’s the older EXT_direct_state_access extension, but ARB_DSA is different and uses different function names (without the EXT or ARB suffix).
So in order for an implementation to support ARB_DSA, it has to have been written in 2014 or later, 7-8 years ago.
So, what is the likelihood that an OpenGL implementation exists and is still being maintained for the hardware, the implementaiton was written more recently than 7 years ago (ie: can support ARB_DSA), and the hardware in question cannot support OpenGL 4.x features?
Outside of open-source drivers for ancient hardware, not much. OpenGL 4.x hardware dates back to 2009. By 2014, pretty much every desktop GPU still being manufactured that supported OpenGL could handle GL 4.x, and support for GL 3.x-only hardware was waning. By nowadays, any GPU still being officially supported is 4.x-capable.
So the question is this: how much does support for hardware that is over a decade old matter to you?