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

[Marek Olšák]

On Mon, Mar 7, 2011 at 11:38 AM, Keith Whitwell <keithw at vmware.com> wrote:

> On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
> >
> > Hi,
> >
> > I have several questions about Gallium. Some of them are about
> > undocumented
> > stuff, others are just little things from the top of my head. Please
> > consider these as things I may do when time allows.
> >
> >
> > 1) Flush flags
> >
> > Which PIPE_FLUSH_* flag is used to flush the command stream? There
> > doesn't
> > seem to be one and we need it for glFlush.
> >
> > What is PIPE_FLUSH_FRAME for? To my knowledge, Gallium doesn't know
> > "frames". What a driver should do when it gets that flag? The same for
> > PIPE_FLUSH_SWAPBUFFERS.
> >
> > I propose replacing the current flags with:
> > - PIPE_FLUSH_COMMANDS // flush the command stream
> > - PIPE_FLUSH_FRAMEBUFFER_CACHE // flush the write cache of the
> > currently-set
> > framebuffer
> > - PIPE_FLUSH_TEXTURE_CACHE // invalidate the read cache of the
> > currently-set
> > textures
>
> I'm not sure if the flags add any value & have been the source of
> bugs/confusion in the past.
>
> How about just removing the parameter?
>

I was thinking the flush cache flags could be used to implement
GL_NV_texture_barrier (or we could add another entrypoint for it). I don't
know of any other use, though.


> >
> > 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.
>

Yes, drivers can do it internally very easily (and st/mesa doesn't even use
is_resource_referenced now).


> > 3) fence_signalled and fence_finish
> >
> > Both of these functions take a driver-specific "flags" parameter
> > (according
> > to p_screen.h) and return an integer (probably driver-specific too),
> > where
> > zero means success. Could we either:
> > - specify a valid set of arguments for "flags" and the return values,
> > - or remove the "flags" parameters and change the return types to
> > boolean?
>
> I'd prefer the latter.
>
> >
> > 4) geom_flags in is_format_supported
> >
> > Not only are these unused by any driver, they also are redundant.
> > - PIPE_TEXTURE_GEOM_NON_SQUARE was obsoleted by PIPE_TEXTURE_RECT,
> > which can
> > be directly passed to is_format_supported.
> > - PIPE_TEXTURE_GEOM_NON_POWER_OF_TWO was obsoleted by
> > PIPE_CAP_NPOT_TEXTURES.
> >
> > Could the geom flags be removed?
>
> This is OK with me too.
>
> > 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.
>
> > 6) Pixel buffer objects
> >
> > It woud be nice to have hardware-accelerated PBO copy in Gallium.
> > Would
> > resource_copy_region be a good candidate for this, where one of the
> > arguments would be PIPE_BUFFER and the other one would be
> > PIPE_TEXTURE_*, or
> > am I missing something?
>
> Do you have a more concrete proposal?
>
> For me, it's always been a bit difficult to pin down what a PBO really
> should map to either in hardware or gallium's abstraction of hardware.
> Sometimes it's a long lived entity (eg. pipe_buffer), other times it's
> just a transient object used for uploads - dma memory from a pool or a
> pipe_transfer in gallium.
>
> But if there's a sensible addition to gallium that improves the
> situation, I'm all for it.
>

A PBO to me is just a way to copy data between a buffer and a texture. Two
cases may arise:
- The copy can be implemented using util_copy_rect (basically it's a memcpy
with strides), in this case, resource_copy_region could be used to let
drivers do the copy in hardware.
- The copy cannot be implemented using util_copy_rect, in this case, the
state tracker would use the current software implementation of PBOs.

Again, another two cases may arise inside resource_copy_region:
- If the strides are well aligned, the copy can done in hardware. (what is
"well aligned" is hardware-specific)
- If they are not, a util function similar to util_resource_copy_region
could be used as a fallback.

But then resource_copy_region needs to know the stride for the buffer being
copied. New entrypoint maybe?

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110307/87e5f8a7/attachment-0001.htm>