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

[Keith Whitwell]

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?

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

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


> 7) Stippling and smoothing
> 
> Would anyone be against removing these two from the Gallium interface
> and
> fully implementing them in st/mesa? It's not like any of the radeon
> people
> wants to implement them in the hardware drivers, and the Draw module
> is not
> an option, because we still would like to have hardware-accelerated
> vertex
> shaders even with stippling and smoothing.

I don't think this is such a good idea.  There is hardware out there
that can do this natively & would benefit from continuing to have it
passed through.

What I think we need is an alternative to the draw module which does
what you're looking with geometry shaders rather than software vertex
transformation.

All these emulated rasterization paths really need the window-space
vertex positions and the assembled primitive (ie all three vertices) to
do their stuff, and the only ways to do that are in software after
vertex transformation or with geometry shaders.

It's an open question how much work it is to do this in the GS (eg. do
you have to emulate clipping first?), but it would be interesting to see
someone take it on.

Keith