intel/fake_bufmgr: Attempt to restrict references to objects in a batchbuffer > apert...
authorDave Airlie <airlied@panoply-rh.(none)>
Wed, 16 Apr 2008 06:22:05 +0000 (16:22 +1000)
committerDave Airlie <airlied@panoply-rh.(none)>
Wed, 16 Apr 2008 06:22:05 +0000 (16:22 +1000)
commit7cc7ff7051d427ff45b4d7d3664e2eecd13d0e13
tree743d9ec37ba54d381524910fa57a480fef8ebe3e
parentbbb042f0b809ebb754547397b8f22a5751c275da
intel/fake_bufmgr: Attempt to restrict references to objects in a batchbuffer > aperture size.

So with compiz on Intel hw with fake bufmgr, opening 4 firefox windows at 1680x1050 and hitting alt-tab, could cause the batchbuffer to try and reference more than the 32MB of RAM allocated.

Fix 1:
Fix 1 is to pre-verify the list of buffers against the current batchbuffer and if it can't possibly fit in the aperture to flush the batchbuffer to the hardware
and try again. If the buffers still can't fit well then you are hosed as I'm not sure there is a nice way to tell anyone.

Fix 2:
Next problem was that even with a simple check for total < aperture, we ran
into fragmentation issues, this meant that half way down a set of buffers,
we would fail as no blocks were available. Fix this by nuking the memory
manager from orbit and letting it start again and relayout the blocks in a
manner that fits.

Fix 3:
Finally the initial problem we were seeing was a memcpy to a NULL backing store.
We seem to end up with a texture at some point that never gets mapped but ends up with data in it. compiz al-tab icons have this property. So I created a card dirty bit that memcpy's any buffer that is !static and is written to back to memory. This probably is wrong but it makes compiz work for now.

Caveats:
965 support is still fail.
src/mesa/drivers/dri/common/dri_bufmgr.c
src/mesa/drivers/dri/common/dri_bufmgr.h
src/mesa/drivers/dri/common/dri_bufmgr_fake.c
src/mesa/drivers/dri/i915/i915_vtbl.c
src/mesa/drivers/dri/intel/intel_batchbuffer.c
src/mesa/drivers/dri/intel/intel_blit.c
src/mesa/drivers/dri/intel/intel_bufmgr_ttm.c