On Fri, Jun 3, 2011 at 4:37 AM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > I have GEM allocation working on the GMA 500 and I can scribble in a > framebuffer (minus an odd 'last page' bug which is an off by one > somewhere I imagine) and display it with nice modetest stripes. > > If I kill the program however it all goes kerblam > > drm_release calls into fb_release which duely destroys the user frame > buffer. This drops the gem object reference and we start to release all > the resources but it blows up because the GEM object is still pinned in > the GTT as it's still being used as scanout. > > Where I'm a bit lost right now is understanding what is supposed to > happen at this point, and how the scanout is supposed to have ended up > cleaned up and reset to the system frame buffer beforehand thus unpinning > the scanout from the GTT. I think the intel driver forces a reset to the system scanout on release. I've actually never found a test to indicate it was completely necessary on other GPUs since they scan out of real VRAM which isn't going to get unbound from the card. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
