[Mesa-dev] [PATCH] st/xorg: add some support for non 32-bit color solid fills

[Marcin Slusarz]

On Tue, May 17, 2011 at 09:27:45AM +0200, Michel Dänzer wrote:
> On Die, 2011-05-17 at 00:12 +0200, Marcin Slusarz wrote: 
> > On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote:
> > > Otherwise, doesn't really look hacky to me - unless we could get other
> > > channel ordering or something similar...
> > 
> > It makes assumptions about how color components are ordered and what are
> > their widths - e.g. it can't distinguish r5g6b5 from a1r5g5b5.
> 
> Such assumptions should be fine for non-RENDER operations. For RENDER,
> maybe you could use something like exaGetRGBAFromPixel, at least for
> inspiration.

The problem is that exa does not pass format to PrepareSolid - only raw color
data and depth, but pipe_context->clear wants float[4], so we need to figure
out color format first. (Or add raw_clear operation...)

For 2D drivers this exa misdesign didn't matter because they used 2D engines
- which care only about BPP for solid fills.

Accelerating RENDER operations should not be a big problem for gallium, because
exa passes all formats (through PicturePtr). For now xorg st fallbacks too much,
but this is something I'm going to tackle soon.

Marcin