[PATCH] radeon: fix exa texture setup v2

[Michel Dänzer]

On Die, 2012-11-13 at 13:59 -0500, Jerome Glisse wrote: 
> On Tue, Nov 13, 2012 at 4:30 AM, Michel Dänzer <michel at daenzer.net> wrote:
> > On Mon, 2012-11-12 at 16:11 -0500, j.glisse at gmail.com wrote:
> >>
> >> diff --git a/src/evergreen_exa.c b/src/evergreen_exa.c
> >> index 883fa5c..10c53d0 100644
> >> --- a/src/evergreen_exa.c
> >> +++ b/src/evergreen_exa.c
> >> @@ -844,8 +844,8 @@ static Bool EVERGREENTextureSetup(PicturePtr pPict, PixmapPtr pPix,
> >>
> >>      /* Texture */
> >>      if (pPict->pDrawable) {
> >> -     tex_res.w               = pPict->pDrawable->width;
> >> -     tex_res.h               = pPict->pDrawable->height;
> >> +     tex_res.w               = pPix->drawable.width;
> >> +     tex_res.h               = pPix->drawable.height;
> >
> > I doubt this is quite right yet...
> >
> > E.g. if pPict->pDrawable is a window which is smaller than the backing
> > pixmap (which I'd expect to be a common case for window pictures), this
> > should still use pPict->pDrawable->width/height? (But that probably
> > still isn't enough if the window origin doesn't lie at the pixmap
> > origin...)
> >
> > OTOH if the pixmap is smaller than the window, I don't think this change
> > will do the right thing for RepeatNormal or RepeatReflect.
> >
> > Not sure rendercheck tests such corner cases at all yet.
> >
> 
> Intel always use pixmap size no matter what and exa header says to use
> it.

I can't see how that can be right for the cases described above; if a
client was special enough to use a window for a repeated picture, surely
it would want the contents of the window to be repeated, not of the
pixmap it happens to be stored in.


> I am totaly lost in the Xorg pixmap, drawable, window thing but I
> don't see how the window origin would not be at pixmap origin.

For example:

Without compositing: Any window whose origin isn't at the screen origin.

With compositing: Any window whose origin doesn't coincide with the
toplevel window origin. E.g. any decorated window with a reparenting
window manager, or other child windows.


I suspect what we need to do is carefully check for the cases we can
accelerate (basically if the window extents coincide with the pixmap
extents, or the difference doesn't matter for the picture semantics),
and fall back otherwise.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer