Comparing the backends revealed that one cannot expect that exposing a storage buffer or a texture to a shader with bufferLoad, imageLoad, bufferStore, imageStore, etc. will always be functional in any graphics and compute pipeline stage. In fact the only place where this is universally supported are compute shaders. In other shaders some backends will not expose the resources at all, e.g. because in D3D11 unordered access views (for a buffer or image used with load/store) have limitations on the API level, whereas others may have runtime limits, e.g. with OpenGL ES an implementation may just say GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS is 0 meaning no SSBOs in vertex shaders. (apparently the case on some embedded GPUs, presumably due to the tiled architecture, e.g. on Mali) So for now add a note to all the relevant QRhiShaderResourceBinding functions. It should be possible to make it work with fragment shaders to a degree at least, but for D3D we then have to deal with OMSetRenderTargetsAndUnorderedAccessViews and some remapping of binding points, whereas elsewhere they may be issues with missing or incorrect barriers. So do not go there now. Change-Id: Ib18949e0184626a9abf5bb72c6ef72bc1cb2e1fa Reviewed-by: Andy Nichols <andy.nichols@qt.io>