diff options
author | Dave Airlie <airlied@panoply-rh.(none)> | 2008-04-16 16:22:05 +1000 |
---|---|---|
committer | Dave Airlie <airlied@panoply-rh.(none)> | 2008-04-16 16:22:05 +1000 |
commit | 7cc7ff7051d427ff45b4d7d3664e2eecd13d0e13 (patch) | |
tree | 743d9ec37ba54d381524910fa57a480fef8ebe3e /src/mesa/drivers/dri/i810/i810state.h | |
parent | bbb042f0b809ebb754547397b8f22a5751c275da (diff) |
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.
Diffstat (limited to 'src/mesa/drivers/dri/i810/i810state.h')
0 files changed, 0 insertions, 0 deletions