Re: [Mesa3d-dev] [PATCH] intel: Expose more FBconfigs in the 3D driver.

[Peter C. <pc...@ca...>]

On Fri, 2009-02-06 at 01:50 +0000, Peter Clifton wrote:
> On Thu, 2009-02-05 at 17:40 -0500, Kristian Høgsberg wrote:
> > On Thu, Feb 5, 2009 at 4:46 PM, Peter Clifton <pc...@ca...> wrote:
> > > On Fri, 2009-01-30 at 11:51 -0500, Kristian Høgsberg wrote:
> > >> On Thu, Jan 29, 2009 at 6:08 PM, Eric Anholt <er...@an...> wrote:
> > >> > We can support any combination of (a8r8g8b8, x8r8g8b8, r5g6b5) x (z0,z24,z24s8)
> > >> > on either class of chipsets.  The only restriction is no mixing bpp when also
> > >> > mixing tiling.  This shouldn't be occurring currently.
> > >>
> > >> Cool, that should fix it.  Or at least let the compositing managers
> > >> pick the right fbconfig.  We should probably fix all drivers to report
> > >> RGB visuals, and then we can yank the reset-alpha-channel hack in the
> > >> tfp sw fallback.
> > >
> > > It doesn't fix it on its own.. certainly not for the intel driver.
> > >
> > > The setTexBuffer hook still explicitly sets the format of the texture to
> > > be BGRA, and I assume it ought to be setting this information based on
> > > the FBconfig (now hopefully correct) of the GLXPixmap the texture is
> > > being mapped from.
> > >
> > > Does anyone have any hints how start fixing that?
> > 
> > Something like the attached patch?  Haven't tested it...
> 
> I've not tried it yet, but I'm looking at the 965 brw code, and am not
> sure the right format is going to make it...
> 
> In the  brw_update_texture_surface function (brw_wm_surface_state.c),
> the bo key's texture format is set to firstImage->TexFormat->MesaFormat
> in the case where there is no format override (e.g. from the DRI1 TFP
> hack).
> 
> The code path then goes via brw_create_texture_surface(), and since the
> key->bo field is set, the following code-path is taken:
> 
>     if (key->bo) 
>       surf.ss0.surface_format = translate_tex_format(key->format,
> key->depthmode);
> 
> That code-path has no conditional which ends up returning the desired:
> BRW_SURFACEFORMAT_B8G8R8X8_UNORM, as might be hit in the DRI1 override
> path where no bo is set, and the alternative code-path sets that format
> type for the case where key->depth == 24.
> 
> Any ideas what MESA format will be appropriate to select the above
> BRW_SURFACEFORMAT_B8G8R8X8_UNORM for inside translate_tex_format() ?
> 
> 
> (And I presume there might be other fixes required for the non 965
> drivers.)


I've tried this, but it didn't work.. any clues?

(Ok.. I've not verified that compiz is definitely choosing the correct
FBconfig...)

Does the attached patch look like the correct approach though? (Adding a
new mesa texture format for an RGB texture with 4cpp spacing?

Or should we just use a similar approach to the DRI(1) tfp override
hack, and keep the details within the driver?

Of course.. if someone wants to beat me to fixing this, please do!

I'm not sure about whether I managed to get all the texel store / fetch
routines for the xrgb8 right.. and there was one I didn't even attempt.
I fugured someone here could do this quicker, or at least point me in
the right direction.

Best regards,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)