mesa: Changes to 'master'

[Dave Airlie]

The branch, master has been updated
        Commits at: http://cgit.freedesktop.org/mesa/mesa/log/?h=master

Summary of changes:
 src/mesa/drivers/dri/common/dri_bufmgr.c       |   10 ++-
 src/mesa/drivers/dri/common/dri_bufmgr.h       |    9 +-
 src/mesa/drivers/dri/common/dri_bufmgr_fake.c  |  121 ++++++++++++++++++++++--
 src/mesa/drivers/dri/i915/i915_vtbl.c          |   31 ++++++
 src/mesa/drivers/dri/intel/intel_batchbuffer.c |   10 ++-
 src/mesa/drivers/dri/intel/intel_blit.c        |   10 ++
 src/mesa/drivers/dri/intel/intel_bufmgr_ttm.c  |   14 +++-
 7 files changed, 187 insertions(+), 18 deletions(-)

       via  7cc7ff7051d427ff45b4d7d3664e2eecd13d0e13 (commit)
      from  bbb042f0b809ebb754547397b8f22a5751c275da (commit)


- Commits -----------------------------------------------
commit 7cc7ff7051d427ff45b4d7d3664e2eecd13d0e13
Author: Dave Airlie <airlied at panoply-rh.(none)>
Date:   Wed Apr 16 16:22:05 2008 +1000

    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.

---------------------------------