On Tue, Mar 8, 2011 at 5:11 PM, José Fonseca <jfons...@vmware.com> wrote:
> 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. > Yeah, I later realized there is no benefit in doing this. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
