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.
Alan
On Fri, Jun 3, 2011 at 4:37 AM, Alan Cox alan@lxorguk.ukuu.org.uk 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.
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
I need to force this on the GMA500 because we want some kind of sane scanout left and the nice guys at Dell decided the Mini 10 didn't actually need a sysrq key so sysrq-V isn't going to help.
On the bright side GEM and the dumb kms stuff now seem to work with a new device id added to libkms and a daft bug in libkms dumb.c fixed (if you report a 32bit fb type, you probably want to allocate a 32bit fb not a 16bit one)
Alan
dri-devel@lists.freedesktop.org