<div class="gmail_quote">On Tue, Mar 8, 2011 at 5:11 PM, José Fonseca <<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">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: </div><div class="im">> > 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. </div>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. <div><div></div><div class="h5"> > > 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. </div></div>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. </blockquote><div> </div></div>Yeah, I later realized there is no benefit in doing this. Marek