[Mesa-dev] 7 questions and proposals about changes in the Gallium interface

[José Fonseca]

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