I am wondering if you will be allowing this to be public knowledge before your drivers are released to support this. I will be implementing a feature in the future that uses image units for on the fly GPU texture decoding, and implementing it in compute shaders or fragment shaders depends on if image units are exposed in fragment shaders.
According to the OpenGL ES 3.1 spec, the minimum amount of image units that the spec requires to be conformant is 4 units. These 4 units are only required to be in the compute shaders, the minimum maximum(GL_MAX_FRAGMENT_IMAGE_UNIFORMS page 395 of the GLES 3.1 spec) specifies that one can have 0 image uniforms available to the fragment shader to be standards compliant with OpenGL ES 3.1.
Will you be exposing image units to the fragment/vertex shaders in order for one to do image load/store operations in these shader types?
Hi Sonic,
Not commenting on the availability of the image units in the fragment shader (I don't know), but I'm interested in your specific use case. If you use a supported compressed texture format, you just sample from it, so are you using an unsupported compression format and you want to decompress to an uncompressed texture? Is the compression format block based?
Thanks,
Chris
I've been working on an emulator for over five years. My use case is that the emulated game hands over a texture in a certain format(CMPR, RGBA8, RGB5A3,RGB565, C14X2, IA4, IA8, I4, I8, C4, C8) and we decode that texture format in to RGBA32 then upload it to the video card.
On x86/x86_64 specific devices this decoding is /exceedingly/ quick due to SSE optimizations. Instead of going that route and making a host specific video decoder for ARM. It would be better off creating a GPU texture decoder which would be host architecture agnostic.
We've decided that using compute/fragment shaders with image units will be the best option to go with for this. Fragment shaders would hit a wider audience of desktop GPUs for us(Intel HD graphics, older Nvidia cards, OSS Mesa drivers) so we would prefer to stick to fragment instead of creating an annoying system to use compute on some GPUs and fragment on others. No need to overly dirty the code in that regard.
Hmm, Do you have any firm numbers from other vendors? The spec is probably written that way because there is some current hardware that cannot support that for some reason, although I don't know what the difference would be between compute/fragment shaders for unified architectures. If the spec only guarantees 4 in the compute shaders then I would suggest that's the best way of doing this on ES3.1 devices. I think compute shaders are core on desktop from 4.3 and available as an extension on 4.2, what's your minimum supported version for desktop?
Qualcomm has refused to comment with, "Thanks for inquirying. Unfortunately we can't comment on future, unannouned hardware or drivers."
For the Nvidia K1 I don't know how many units they support, but since they have OpenGL 4.4 support and they expose the image units to fragment shaders it isn't an issue.
For IMGTec I haven't even cared to inquiry since I haven't been able to bring up support for the hardware since there aren't any Android/Linux devices with it that support OpenGL ES 3.0.
Our minimum required OpenGL version is 3.1 + sampler_objects. We support quite a few extensions running all the way up to 4.4 with buffer_storage.
For OpenGL ES our minimum required version is of course 3.0, which is quite limiting compared to what we use with desktop GL.
I think for now I'll have to take Qualcomm's line and say we don't have anything public in relation to this at the moment... But again, it's spec guaranteed you'll have 4 in the compute shaders. You might have to compromise slightly and go for compute shaders on ES 3.1, fragment on desktop, or require the compute shader extension on desktop, and go pure compute shader. Actually, as you already have an SSE fast path for x86, maybe it's ok to use compute everywhere if it's available, including desktop, and ignore the fragment option?
Hth,