On Mon, 2011-03-07 at 02:38 -0800, Keith Whitwell wrote: > On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote: > > 2) is_resource_referenced > > > > Now that the transfer functions are in pipe_context, is this hook > > really > > necessary? > > Good question. I'd like to see those functions go away as they are > round-trips baked into the interface which is a pain if you try and > remote this stuff. > > I guess you'd still need to catch the write-after-read case within a > single context and turn that into a flush. > > I think others (Jose in particular) should comment, but I suspect that > individual drivers could now do this internally & not need to expose the > interface in gallium.
That's correct. State trackers no longer need this. This interface can be removed, and drivers that need it internally should be updated to use internal private interfaces. > > 5) Block compression formats naming > > > > Would anyone object to cleaning up the names of compression formats? > > > > There are (or will be) these formats: DXTn, RGTCn, LATCn, BPTCx. They > > have > > many things in common: > > - All of them have 4x4 pixel blocks. > > - One block is either 64 bits of 128 bits large. > > - RGTC and LATC are equal except for swizzling. > > - RGTC and LATC are based on DXTn encoding. > > > > I propose to copy the more consistent D3D11 naming and use the form > > PIPE_FORMAT_encoding_swizzle_type for all of them: > > > > PIPE_FORMAT_BC1_RGB_UNORM // DXT1 = BC1 > > PIPE_FORMAT_BC1_RGB_SRGB > > PIPE_FORMAT_BC1_RGBA_UNORM > > PIPE_FORMAT_BC1_RGBA_SRGB > > PIPE_FORMAT_BC2_RGBA_UNORM // DXT3 = BC2 > > PIPE_FORMAT_BC2_RGBA_SRGB > > PIPE_FORMAT_BC3_RGBA_UNORM // DXT5 = BC3 > > PIPE_FORMAT_BC3_RGBA_SRGB > > PIPE_FORMAT_BC4_R_UNORM // RGTC1 = BC4 > > PIPE_FORMAT_BC4_R_SNORM > > PIPE_FORMAT_BC4_L_UNORM // LATC1 = BC4 > > PIPE_FORMAT_BC4_L_SNORM > > PIPE_FORMAT_BC5_RG_UNORM // RGTC2 = D3D/3DC = BC5 > > PIPE_FORMAT_BC5_RG_SNORM > > PIPE_FORMAT_BC5_LA_UNORM // LATC2 = GL/3DC = BC5 > > PIPE_FORMAT_BC5_LA_SNORM > > PIPE_FORMAT_BC6_RGB_FLOAT // BPTC (BC6H) > > PIPE_FORMAT_BC6_RGB_UFLOAT > > PIPE_FORMAT_BC7_RGBA_UNORM // BPTC > > PIPE_FORMAT_BC7_RGBA_SRGB > > > > The layout for all of them would be UTIL_FORMAT_LAYOUT_BC. > > > > UFLOAT is a float without the sign bit. I guess UFLOAT should be used > > for > > R11G11B10_FLOAT and R9G9B9E5_FLOAT too. > > Sounds good again, though this is more Jose's domain than mine. Although I'm all for consistency, I really see no point in a format name which is based on an arbitrary number as used in DX11, instead of a symbolic name with meaning as we have currently Imagine we want to expose a different compressed format, e.g., Khronos' ETC format. Which BC number shall we give? What will happen when Microsoft decides to assign a different number? IMO, renaming compressed formats to PIPE_FORMAT_BC* is pure waste of time. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
