aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/intel/intel_blit.c
Commit message (Collapse)AuthorAgeFilesLines
* intel: Fix bpp setting of blits to 8bpp targets.Eric Anholt2009-03-051-0/+2
| | | | | This was causing hangs in cairogears, as we would blit to the 8bpp target (A8 texture) as 16bpp, and stomp over state objects.
* intel: Remove a gratuitous MI_FLUSH after clearing with a blit.Eric Anholt2009-03-051-1/+0
| | | | | The 3D destination shares the same cache so we don't have any trouble with the later commands needing the writes flushed inside of the same batchbuffer.
* Remove intel pageflipping support in its entirety.Owain G. Ainsworth2009-01-201-1/+0
| | | | | | | | It's been broken and deprecated for a while, so it's time to die. This has the wonderful benefit of cleaning up the code a fair amount; making it marginally less twisty. I'm unsure if the for loops in IntelWindowMoved are still needed.
* intel: Require the right amount of space in glBitmap blit acceleration.Pierre Willenbrock2008-12-081-1/+1
| | | | | This leads to problems when the batchbuffer is flushed, but the bitmap data could not fit into it.
* i965: Add support for accelerated CopyTexSubImage.Eric Anholt2008-11-211-45/+19
| | | | | | | | | | | There were hacks in EmitCopyBlit before to adjust offsets so that y=0 after the offsets had been adjusted for a negative pitch. It appears that those hacks were due to an unclear and surprising aspect of the hardware: inverting the pitch results in the blit into the specified rectangle being inverted, without the user needing to adjust y and base offset. Tested with piglit copytexsubimage test on 915GM and GM965. Should fix serious performance issues with ETQW and other applications.
* intel: Don't keep intel->pClipRects, and instead just calculate it when needed.Eric Anholt2008-10-281-6/+10
| | | | | | | 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.
* intel: GL_FALSE on a BO if it won't be modified when mapping this BO. ↵Xiang, Haihao2008-10-261-1/+1
| | | | (thanks Eric).
* intel: fallback for intelEmitCopyBlit.Xiang, Haihao2008-10-241-10/+39
| | | | | Use _mesa_copy_rect instead of BLT operation if dri_bufmgr_check_aperture_space still fails after flushing batchbuffer. Partial fix for #17964.
* mesa: added "main/" prefix to includes, remove some -I paths from ↵Brian Paul2008-09-181-3/+3
| | | | Makefile.template
* intel: track move of bo_exec from drivers to bufmgr.Eric Anholt2008-09-101-1/+1
|
* Revert "Revert "Merge branch 'drm-gem'""Dave Airlie2008-08-241-51/+62
| | | | This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
* Revert "Merge branch 'drm-gem'"Dave Airlie2008-08-241-62/+51
| | | | | | | | This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03. Conflicts: src/mesa/drivers/dri/i965/brw_wm_surface_state.c
* intel-gem: Update to new check_aperture API for classic mode.Eric Anholt2008-08-081-13/+17
| | | | | | 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.
* Merge branch 'master' into drm-gemIan Romanick2008-07-251-1/+4
|\ | | | | | | | | | | | | Conflicts: src/mesa/drivers/dri/common/dri_bufmgr.c src/mesa/drivers/dri/i965/brw_wm_surface_state.c
| * intel: fix batch flushing problem with cliprects handling.Dave Airlie2008-07-111-1/+4
| | | | | | | | pointed out and debugged by stringfellow on #dri-devel
* | drm-gem: Use new GEM ioctls for tiling state, and support new swizzle modes.Eric Anholt2008-07-111-12/+12
| |
* | intel: Replace sprinkled intel_batchbuffer_flush with MI_FLUSH or nothing.Eric Anholt2008-06-261-15/+10
| | | | | | | | | | | | | | | | | | Most of these were to ensure that caches got synchronized between 2d (or meta) rendering and later use of the target as a source, such as for texture miptree setup. Those are replaced with intel_batchbuffer_emit_mi_flush(), which just drops an MI_FLUSH. Most of the remainder were to ensure that REFERENCES_CLIPRECTS batchbuffers got flushed before the lock was dropped. Those are now replaced by automatically flushing those when dropping the lock.
* | Merge commit 'origin/master' into drm-gemEric Anholt2008-06-241-4/+5
|\|
| * i915: Add support for accelerated glBitmap, shared from 965.Eric Anholt2008-06-241-4/+5
| |
* | Merge commit 'origin/master' into drm-gemEric Anholt2008-06-181-4/+1
|\|
| * i915: Bug #14313: Fix accelerated (PBO) ReadPixels.Eric Anholt2008-06-181-4/+1
| | | | | | | | | | Refactoring of mine in 02d5ba849197e19843dad164239b51f18fb16faf broke it by failing to understand that the masking was about sign extension.
* | [intel-gem] Chase domain flag renaming in the DRM.Eric Anholt2008-06-111-9/+9
| | | | | | | | This is an API breakage only.
* | [intel] all flushing in intelEmitCopyBlitKeith Packard2008-05-261-0/+4
| | | | | | | | | | | | Add both MI_FLUSH and intel_batchbuffer_flush to intelEmitCopyBlit. This ensures that the data are flushed *and* the gem kernel driver sees the various memory domain transitions.
* | Emit a flush after the swapbuffers blit, so contents end up on the screen.Eric Anholt2008-05-231-0/+8
| | | | | | | | | | | | | | Otherwise, since the MI_FLUSH at the end of every batch had been removed, non-automatic-flushing chips (965) wouldn't get flushed and apps with static rendering would get partial screen contents until the server's blockhandler flush kicked in.
* | GEM: Make dri_emit_reloc take GEM domain flags instead of TTM flags.Eric Anholt2008-05-071-9/+22
| | | | | | | | | | | | 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.
* | [intel] Fix build for GEM. TTM is now disabled, and fencing is gone.Eric Anholt2008-05-021-13/+0
|/ | | | | | | 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).
* i965: initial attempt at fixing the aperture overflowDave Airlie2008-04-181-0/+8
| | | | | | | | | Makes state emission into a 2 phase, prepare sets things up and accounts the size of all referenced buffer objects. The emit stage then actually does the batchbuffer touching for emitting the objects. There is an assert in dri_emit_reloc if a reloc occurs for a buffer that hasn't been accounted yet.
* intel/fake_bufmgr: Attempt to restrict references to objects in a ↵Dave Airlie2008-04-161-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* Hook up i915 driver to new DRI2 infrastructure.Kristian Høgsberg2008-02-141-3/+1
|
* [intel] Add more cliprect modes to cover other meanings for batch emits.Eric Anholt2008-01-101-9/+9
| | | | | | | | | | | | | | | 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.
* [intel] Prepare intelCopyBuffer() for private back buffers.Kristian Høgsberg2008-01-091-2/+4
|
* Replace gl_framebuffer's _ColorDrawBufferMask with _ColorDrawBufferIndexesBrian2008-01-061-5/+5
| | | | | | | Each array element is now a BUFFER_x token rather than a BUFFER_BIT_x bitmask. The number of active color buffers is specified by _NumColorDrawBuffers. This builds on the previous DrawBuffer changes and will help with drivers implementing GL_ARB_draw_buffers.
* [965] Enable EXT_framebuffer_object.Eric Anholt2007-12-201-0/+74
| | | | | To do so, merge the remainnig necessary code from the buffers, blit, span, and screen code to shared, and replace it with those.
* [intel] Improve INTEL_DEBUG=blit description of clearing.Eric Anholt2007-12-171-2/+0
|
* [intel] Cleanup of */intel_blit.c to bring the two closer.Eric Anholt2007-12-171-55/+51
|
* [intel] Move bufmgr back to context instead of screen, fixing glthreads.Eric Anholt2007-12-121-1/+1
| | | | | | | | 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.
* i915: Some additional blit fixes and assertions.Michel Dänzer2007-11-261-8/+24
|
* [intel] Add 965 support to shared intel_blit.cEric Anholt2007-11-161-27/+64
| | | | | This requires that regions grow a marker of whether they are tiled or not, because fence (surface) registers are ignored by the 965 2D engine.
* [intel] Move over files that will be shared with 965-fbo work.Eric Anholt2007-11-091-0/+491
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 20:46:11 +0000