summaryrefslogtreecommitdiff
path: root/src/mesa/drivers/dri/intel/intel_batchbuffer.c
AgeCommit message (Collapse)Author
2010-01-26intel: Clean up stale comments about cliprects.Eric Anholt
2010-01-25i965: Remove unnecessary malloc/free in VS binding table setup.Eric Anholt
2010-01-04intel: Drop batchbuffer cliprect_mode trackingKristian Høgsberg
2010-01-04intel: Drop LOCK/UNLOCK_HARDWARE()Kristian Høgsberg
2009-11-19intel: Remove non-GEM support.Eric Anholt
This really isn't supported at this point. GEM's been in the kernel for a year, and the fake bufmgr never really worked.
2009-11-19intel: Consistently use no_batch_wrap in intel_context struct.Eric Anholt
2009-11-06intel: Use PIPE_CONTROL on gen4 hardware for doing pipeline flushing.Eric Anholt
This should do all the things that MI_FLUSH did, but it can be pipelined so that further rendering isn't blocked on the flush completion unless necessary.
2009-10-29intel: Clean up merge leftover from the DRI2 swap throttling.Eric Anholt
2009-08-05Merge branch 'mesa_7_5_branch'Brian Paul
Conflicts: src/mesa/main/state.c
2009-08-04intel: Wait on the last swapbuffers to complete before queuing a new one.Brian Paul
This fixes jerkiness in doom3 and other apps since the kernel change to throttle less absurdly, which led to a thundering herd of frames. Because this is a rather minimal fix, there is at least one downside: If the whole scene completes in one batchbuffer, we'll end up stalling the GPU. Thanks to Michel Dänzer for suggesting using glFlush to signal frame end instead of going to all the effort of adding a new DRI2 extension. (cherry picked from master, commit 0828579a658af01a64b5e699175dc9bbbedcd685)
2009-08-03intel: Wait on the last swapbuffers to complete before queuing a new one.Eric Anholt
This fixes jerkiness in doom3 and other apps since the kernel change to throttle less absurdly, which led to a thundering herd of frames. Because this is a rather minimal fix, there is at least one downside: If the whole scene completes in one batchbuffer, we'll end up stalling the GPU. Thanks to Michel Dänzer for suggesting using glFlush to signal frame end instead of going to all the effort of adding a new DRI2 extension.
2009-06-29intel: Make LOCK_HARDWARE recursive to avoid hand-rolling recursiveness.Eric Anholt
2009-03-05intel: Add always_flush_cache driconf option for debugging cache flush failure.Eric Anholt
I keep wanting to hack this knob in as a one-time thing, so it seemed useful to have all the time.
2008-11-11intel: reset cliprect_mode to IGNORE_CLIPRECTS.Xiang, Haihao
This ensures all batchbuffers have a same cliprect mode after calling _intel_batchbuffer_flush even if there aren't invalid commands in the current batch buffer. (fix bug#18362).
2008-10-28intel: Don't keep intel->pClipRects, and instead just calculate it when needed.Eric Anholt
This avoids issues with dereferencing stale cliprects around intel_draw_buffer time. Additionally, take advantage of cliprects staying constant for FBOs and DRI2, and emit cliprects in the batchbuffer instead of having to flush batch each time they change.
2008-09-10intel: track move of bo_exec from drivers to bufmgr.Eric Anholt
2008-09-10intel: track bufmgr move to libdrm_intel and bufmgr_fake irq emit/wait change.Eric Anholt
2008-09-10intel: Move the bufmgr back to the screen.Eric Anholt
Mesa requires that we be able to share objects between contexts, which means that the objects need to be created by the same bufmgr, and the bufmgr internally requires pthread protection for thread safety. Rely on the bufmgr having appropriate locking.
2008-08-24Revert "Revert "Merge branch 'drm-gem'""Dave Airlie
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
2008-08-24Revert "Merge branch 'drm-gem'"Dave Airlie
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03. Conflicts: src/mesa/drivers/dri/i965/brw_wm_surface_state.c
2008-08-08intel-gem: Update to new check_aperture API for classic mode.Eric Anholt
To do this, I had to clean up some of 965 state upload stuff. We may end up over-emitting state in the aperture overflow case, but that should be rare, and I'd rather have the simplification of state management.
2008-06-23i915: Accumulate the VB into a local buffer and subdata it in.Eric Anholt
This lets GEM use pwrite, for an additional 4% or so speedup.
2008-06-03[intel] Convert drivers to using libdrm bufmgr code.Eric Anholt
2008-05-11[intel] update GEM api. Add bo_subdata and bo_get_subdata driver hooks.Keith Packard
Track DRM GEM name changes. Add driver hooks for bo_subdata and bo_get_subdata so that GEM can use pread and pwrite.
2008-05-08[intel] intel_batchbuffer_flush using uninit 'used' to check for buffer emptyKeith Packard
Make sure 'used' tracks the right value through the whole function. Also, use GLint for intel_batchbuffer_space in case we do bad things in the future.
2008-05-07GEM: Make dri_emit_reloc take GEM domain flags instead of TTM flags.Eric Anholt
The GEM flags are much more descriptive for what we need. Since this makes bufmgr_fake rather device-specific, move it to the intel common directory. We've wanted to do device-specific stuff to it before.
2008-05-07GEM: Don't emit an extra MI_FLUSH in the batch since GEM handles it.Eric Anholt
2008-05-05Make intel_{batch,exec}_ioctl return an error code so we can recover better.Eric Anholt
2008-05-02[intel] Fix build for GEM. TTM is now disabled, and fencing is gone.Eric Anholt
Fencing was used in two places: ensuring that we didn't get too many frames ahead of ourselves, and glFinish. glFinish will be satisfied by waiting on buffers like we would do for CPU access on them. The "don't get too far ahead" is now the responsibility of the execution manager (kernel).
2008-05-02Add intel_bufmgr_gem for new graphics execution manager.Eric Anholt
2008-05-02[intel] Warnings fixes.Eric Anholt
2008-04-16intel/fake_bufmgr: Attempt to restrict references to objects in a ↵Dave Airlie
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.
2008-01-17[i915] Fix driver from cliprects changes, and clean up state emission.Eric Anholt
The fix for pageflipping with cliprects ended up causing a batch flush at an inopportune time, which is fixed by moving it up. Additionally, the recovery code for handling batch wraps at bad times is replaced by just checking for the space up front, and using a no_batch_wrap assert like on 965 to make sure that we weren't wrong about how much space that was.
2008-01-15[i915] Prevent recursive batchbuffer flushing.Kristian Høgsberg
Workaround for recursive batchbuffer flushing: If the window is moved, we can get into a case where we try to flush during a flush. What happens is that when we try to grab the lock for the first flush, we detect that the window moved which then causes another flush (from the intel_draw_buffer() call in intelUpdatePageFlipping()). To work around this we reset the batchbuffer tail pointer before trying to get the lock. This prevent the nested buffer flush, but a better fix would be to avoid that in the first place.
2008-01-10[intel] Only flush batch when changing draw buffers, not every cliprect update.Eric Anholt
The previous code would reference freed memory on window moves.
2008-01-10[intel] Add more cliprect modes to cover other meanings for batch emits.Eric Anholt
The previous change gave us only two modes, one which looped over the batch per cliprect (3d drawing) and one that didn't (state updeast). However, we really want 4: - Batch doesn't care about cliprects (state updates) - Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing) - Batch needs to be executed just once (region fills, copies, etc.) - Batch already includes cliprect handling, and must be flushed by unlock time (copybuffers, clears). All callers should now be fixed to use one of these states for any batchbuffer emits. Thanks to Keith Whitwell for pointing out the failure.
2008-01-09[intel] Rename lost_hardware vtbl entry to new_batch.Eric Anholt
Both drivers have ended up relying on lost_hardware being called after each batch buffer, so update the name. This removes one of the calls on 965 whic h was outside of the batchbuffer handling code and just duplicating what had already happened through batchbuffer handling.
2008-01-09[intel] Clean up cliprect handling in intel drivers.Eric Anholt
In particular, batch buffers are no longer flushed when switching from CLIPRECTS to NO_CLIPRECTS or vice versa, and 965 just uses DRM cliprect handling for primitives instead of trying to sneak in its own to avoid the DRM stuff. The disadvantage is that we will re-execute state updates per cliprect, but the advantage is that we will be able to accumulate larger batch buffers, which were proving to be a major overhead.
2007-12-12[intel] Move bufmgr back to context instead of screen, fixing glthreads.Eric Anholt
Putting the bufmgr in the screen is not thread-safe since the emit_reloc changes. It also led to a significant performance hit from pthread usage for the attempted thread-safety (up to 12% of a cpu spent on refcounting protection in single-threaded 965). The motivation had been to allow multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
2007-12-11Use previous buffer offsets to compute proposed relocationsKeith Packard
This takes advantage of the DRM_BO_HINT_PRESUMED_OFFSET change and allows the kernel to avoid mapping and re-writing buffers when relocations occur.
2007-12-07[965] Convert the driver to dri_bufmgr interface and enable TTM.Eric Anholt
This is currently believed to work but be a significant performance loss. Performance recovery should be soon to follow. The dri_bo_fake_disable_backing_store() call was added to allow backing store disable like bufmgr_fake.c did, which is a significant performance win (though it's missing the no-fence-subdata part). This commit is a squash merge of the 965-ttm branch, which had some history I wanted to avoid pulling due to noisiness and brokenness at many points for git-bisecting.
2007-11-30[intel] Move batch bo_unmap from TTM code to shared, and add more asserts.Eric Anholt
2007-11-26i915: Catch cases where not all state is emitted for a new batchbuffer.Keith Whitwell
This could lead to incorrect rendering or even lockups.
2007-11-16[i915] Add INTEL_DEBUG=sync debug flag to wait for fences after making them.Eric Anholt
2007-11-16[i915] Reenable batchbuffer debug under INTEL_DEBUG=bat.Eric Anholt
2007-11-09[intel] Move over files that will be shared with 965-fbo work.Eric Anholt
2007-09-27Revert "WIP 965 conversion to dri_bufmgr."Eric Anholt
This reverts commit b2f1aa2389473ed09170713301b042661d70a48e. Somehow I ended up with my branch's save-this-while-I-work-on-master commit actually on master.
2007-09-27WIP 965 conversion to dri_bufmgr.Eric Anholt