Chris Forbes <chr...@ijw.co.nz> writes: > 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. >
Right, but wouldn't it make more sense for the driver to define a driver-specific ChooseTextureFormat function in those cases, or just mark the problematic format as unsupported? > 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 >>>>
pgpayDd8AOuGf.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
