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

[Marek Olšák]

On Tue, Mar 8, 2011 at 5:11 PM, José Fonseca <jfonseca at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110308/905f9763/attachment.htm>