DRI2 RGB / RGBA visual problems [WAS: Re: intel 2.6.0: EXA choppy, UXA has artifacts]

[Peter Clifton]

On Wed, 2009-01-21 at 08:54 +0100, Michel Dänzer wrote:
> On Wed, 2009-01-21 at 04:45 +0000, Peter Clifton wrote:
> > 
> > Questions to those who might know..
> > 
> > Should DRI2 be clearing the Alpha channel (even if it requires making a
> > copy for these cases)?
> 
> It mustn't do this for pixmaps that actually have an alpha channel, and
> it shouldn't need to otherwise.
> 
> 
> > Should compiz be decorating RGB windows using shadows which require
> > RGBA?
> 
> I don't think there should be a problem with that; traditionally compiz
> doesn't reparent application windows but uses separate drawables for the
> decorations.

Ok - I probably just need to figure out what its doing, and why its
triggering my test for the "window" being 24 bits. Its possible I'm
testing a property relating to the original window being decorated,
rather than the Drawable being rendered.

> > Is there some way to fake GL into thinking the non-copied texture from
> > DRI2 is in fact RGB, not RGBA, just with a stride of 4 bytes?
> 
> That's basically how the DRI1 AIGLX zero-copy tfp code handles this. See
> the code calling testTexOffset() in glx/glxdri.c and the corresponding
> SetTexOffset hooks in
> mesa/src/mesa/drivers/dri/{intel,r200,r300,radeon} . Something similar
> should be possible with DRI2.

My first attempt at hacking round this was to call the SetTexOffset
hook, but that didn't appear to work. Is it valid to do so for DRI2?

If this is the way forward, I'll have a dig at discovering why
SetTexOffset didn't stick.


One other question, whilst I was inside glxdri2.c, I noticed this:


static int
__glXDRIreleaseTexImage(__GLXcontext *baseContext,
			int buffer,
			__GLXdrawable *pixmap)
{
    /* FIXME: Just unbind the texture? */
    return Success;
}


The call:


static int
__glXDRIbindTexImage(__GLXcontext *baseContext,
		     int buffer,
		     __GLXdrawable *glxPixmap)
{

uses:


    texBuffer->setTexBuffer(context->driContext,
			    glxPixmap->target,
			    drawable->driDrawable);


Is there any leakage here?

I noticed the setTexBuffer hook appeared to be creating a mipmap tree. 

Should we be calling a hook to trigger intelFreeTextureImageData ?


(Please note, I'm still pretty much a noob w.r.t. the architecture of
mesa / GL / ....)

-- 
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!)