Bad caching of the scratch pixmap

[Michel Dänzer]

On Die, 2013-04-16 at 11:42 -0600, Daniel Drake wrote: 
> On Tue, Apr 16, 2013 at 11:22 AM, Michel Dänzer <michel at daenzer.net> wrote:
> > On Die, 2013-04-16 at 10:54 -0600, Daniel Drake wrote:
> >> On Sat, Apr 13, 2013 at 11:14 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >> > Given the same fix works, it does sound like a very similar issue. The
> >> > difference is that the DDX is under control of the creating the scratch
> >> > pixmap in your case and should be well aware of the lifetime constraints
> >> > and so remember to decouple the GPU object when it destroys the screen
> >> > pixmap. So the bug is really in the driver and this just happens to
> >> > workaround the bug by forcing the release
> >>
> >> Good that you have a feeling for where the real problem actually is.
> >> I'm happy to fix the driver, but I am facing a bit of a learning
> >> curve. If I get a good grasp on things, I will try to produce some
> >> documentation for the next person...
> >>
> >> So, the DDX is in control of pixmap allocations. It does that by
> >> providing these hooks:
> >>
> >>     if (pExa->flags & EXA_HANDLES_PIXMAPS)
> >>     {
> >>         pExa->CreatePixmap       = NULL;
> >>         pExa->CreatePixmap2      = mrvlExaCreatePixmap2;
> >>         pExa->DestroyPixmap      = mrvlDestroyPixmap;
> >>         pExa->ModifyPixmapHeader = mrvlModifyPixmapHeader;
> >>         pExa->PixmapIsOffscreen  = mrvlPixmapIsOffscreen;
> >>     }
> >
> > Do you really need the ModifyPixmapHeader hook? It shouldn't be
> > necessary with CreatePixmap2. Do things work better without it?
> 
> Causes a crash early in X init. Maybe this has uncovered a driver bug?

Possibly. E.g. I see that mrvlPrepareAccess() returns TRUE but doesn't
set pPix->devPrivate.ptr. 

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