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

Marcin Slusarz marcin.slusarz at gmail.com
Tue May 17 09:30:30 PDT 2011

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.


More information about the mesa-dev mailing list