summaryrefslogtreecommitdiff
path: root/src/mesa/drivers/dri/intel/intel_blit.c
AgeCommit message (Collapse)Author
2009-04-16intel: Add support for argb1555, argb4444 FBOs and fix rgb565 fbo readpixels.Eric Anholt
Also enable them all regardless of screen bpp, as 32 bpp what I've been testing against, and haven't been able to detect any screen bpp-specific troubles with them.
2009-03-28fix various small intel blitter issuesRoland Scheidegger
use color format constants instead of magic numbers remove handling of cpp 0 or 3 (neither is possible) in various places don't misconfigure 8 bit surface blits as rgb565
2009-03-05intel: Fix bpp setting of blits to 8bpp targets.Eric Anholt
This was causing hangs in cairogears, as we would blit to the 8bpp target (A8 texture) as 16bpp, and stomp over state objects.
2009-03-05intel: Remove a gratuitous MI_FLUSH after clearing with a blit.Eric Anholt
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.
2009-01-20Remove intel pageflipping support in its entirety.Owain G. Ainsworth
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.
2008-12-08intel: Require the right amount of space in glBitmap blit acceleration.Pierre Willenbrock
This leads to problems when the batchbuffer is flushed, but the bitmap data could not fit into it.
2008-11-21i965: Add support for accelerated CopyTexSubImage.Eric Anholt
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.
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-10-26intel: GL_FALSE on a BO if it won't be modified when mapping this BO. ↵Xiang, Haihao
(thanks Eric).
2008-10-24intel: fallback for intelEmitCopyBlit.Xiang, Haihao
Use _mesa_copy_rect instead of BLT operation if dri_bufmgr_check_aperture_space still fails after flushing batchbuffer. Partial fix for #17964.
2008-09-18mesa: added "main/" prefix to includes, remove some -I paths from ↵Brian Paul
Makefile.template
2008-09-10intel: track move of bo_exec from drivers to bufmgr.Eric Anholt
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-07-25Merge branch 'master' into drm-gemIan Romanick
Conflicts: src/mesa/drivers/dri/common/dri_bufmgr.c src/mesa/drivers/dri/i965/brw_wm_surface_state.c
2008-07-11drm-gem: Use new GEM ioctls for tiling state, and support new swizzle modes.Eric Anholt
2008-07-11intel: fix batch flushing problem with cliprects handling.Dave Airlie
pointed out and debugged by stringfellow on #dri-devel
2008-06-26intel: Replace sprinkled intel_batchbuffer_flush with MI_FLUSH or nothing.Eric Anholt
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.
2008-06-24Merge commit 'origin/master' into drm-gemEric Anholt
2008-06-24i915: Add support for accelerated glBitmap, shared from 965.Eric Anholt
2008-06-18Merge commit 'origin/master' into drm-gemEric Anholt
2008-06-18i915: Bug #14313: Fix accelerated (PBO) ReadPixels.Eric Anholt
Refactoring of mine in 02d5ba849197e19843dad164239b51f18fb16faf broke it by failing to understand that the masking was about sign extension.
2008-06-11[intel-gem] Chase domain flag renaming in the DRM.Eric Anholt
This is an API breakage only.
2008-05-26[intel] all flushing in intelEmitCopyBlitKeith Packard
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.
2008-05-23Emit a flush after the swapbuffers blit, so contents end up on the screen.Eric Anholt
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.
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-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-04-18i965: initial attempt at fixing the aperture overflowDave Airlie
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.
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-02-14Hook up i915 driver to new DRI2 infrastructure.Kristian Høgsberg
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] Prepare intelCopyBuffer() for private back buffers.Kristian Høgsberg
2008-01-06Replace gl_framebuffer's _ColorDrawBufferMask with _ColorDrawBufferIndexesBrian
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.
2007-12-20[965] Enable EXT_framebuffer_object.Eric Anholt
To do so, merge the remainnig necessary code from the buffers, blit, span, and screen code to shared, and replace it with those.
2007-12-17[intel] Improve INTEL_DEBUG=blit description of clearing.Eric Anholt
2007-12-17[intel] Cleanup of */intel_blit.c to bring the two closer.Eric Anholt
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-11-26i915: Some additional blit fixes and assertions.Michel Dänzer
2007-11-16[intel] Add 965 support to shared intel_blit.cEric Anholt
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.
2007-11-09[intel] Move over files that will be shared with 965-fbo work.Eric Anholt