There's cases where BGRA or ARGB or whatever avoids having to juggle things either in texture upload paths, or blits to scanout buffers -- if we didn't care about that, then yes, we could just default to the canonical layout.
I think we can also detect the cases for views via type==format==GL_NONE in mesa, and possibly avoid the parameter -- but that doesn't help for ARB_shader_image_load_store. -- Chris On Wed, Mar 12, 2014 at 8:47 AM, Francisco Jerez <curroje...@riseup.net> wrote: > Chris Forbes <chr...@ijw.co.nz> writes: > >> Hi Michel, and thanks for the quick feedback. >> >> This is why it's tagged RFC :) >> >> After thinking about it a bit more, I'm not convinced it's the right >> thing either. >> >> You're right, the spec is very careful not to say anything about the >> memory layout. The 4.2 core profile spec, section 3.9.20 defines >> reinterpretation of texels in a roundabout way to avoid having to >> specify the memory layout: >> >> " >> The re-interpretation for image >> loads and the read portion of image atomics is performed as though data >> were >> copied from the texel of the bound texture to a similar texel >> represented in the >> format of the image unit. Similarly, the re-interpretation for >> image stores and the >> write portion of image atomics is performed as though data were >> copied from a >> texel represented in the format of the image unit to the texel in >> the bound texture. >> In both cases, this copy operation would be performed by: >> >> - reading the texel from the source format to scratch memory according >> to >> the process described for GetTexImage (see section 6.1.4), using >> default >> pixel storage modes and <format> and <type> parameters corresponding >> to the source format in table 3.22; and >> >> - writing the texel from scratch memory to the destination format >> according >> to the process described for TexSubImage3D (see section 3.9.4), >> using default >> pixel storage modes and <format> and <type> parameters corresponding >> to the destination format in table 3.22 >> " >> >> My underspecified "exact matching format" and "correct order" are then >> those which make the above operations just a memcpy, so we don't >> actually have to do anything beyond aliasing the memory. >> >> I suppose there might be implementations which want to do other things. >> > > Yeah, that's right, an implementation of ARB_shader_image_load_store or > ARB_texture_view is still free to store the texture components in any > memory layout it pleases. If the memory layout used internally is just > a (consistently) swizzled variant of what's specified by > ARB_image_load_store, the implementation may still avoid the copy in > many cases, but the approach of this patch series seems like the best > thing to do to me. > > Is there any reason we need the 'prefer_no_swizzle' argument? Can't we > just default to the "canonical" layout if it's supported? > >> CC'ing Francisco on this as he was working on >> ARB_shader_image_load_store, which first introduces this -- I care >> mostly about the ARB_texture_view bits, which defines reinterpretation >> of a texture's data store by piggybacking on the load_store >> definition. >> >> -- Chris >> >> On Tue, Mar 11, 2014 at 3:42 PM, Michel Dänzer <mic...@daenzer.net> wrote: >>> On Mon, 2014-03-10 at 22:20 +1300, Chris Forbes wrote: >>>> If prefer_no_swizzle is set, try: >>>> - The exact matching format >>>> - Formats with the required components in the correct order, plus a junk >>>> component >>> >>> How are 'exact matching' and 'correct order' defined? My understanding >>> of GL internal formats is that they just specify which components are >>> there and possibly their sizes, but nothing about their memory layout. >>> If my understanding is correct, I think it's a bad idea to hardcode >>> driver / platform specific preferences here like this. >>> >>> I think you would either need to take the 'format' parameter into >>> account as well, or just use a driver specific ChooseTextureFormat hook. >>> >>> >>> -- >>> Earthling Michel Dänzer | http://www.amd.com >>> Libre software enthusiast | Mesa and X developer >>> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev