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

[Marek Olšák]

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


2) is_resource_referenced

Now that the transfer functions are in pipe_context, is this hook really
necessary?


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?


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?


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.


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?


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.


Best regards
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110306/a97030da/attachment.htm>