The presumption is that we wish to keep the target hot, so
copy to a new bo and move that to the CPU in preference to
causing ping-pong of the original.
Also the gpu is much faster at detiling.
Before (PineView):
400000 trep @ 0.1128 msec ( 8860.0/sec): GetImage 10x10 square
18000 trep @ 1.3839 msec ( 723.0/sec): GetImage 100x100 square
800 trep @ 30.0987 msec ( 33.2/sec): GetImage 500x500 square
After: (PineView)
180000 trep @ 0.1478 msec ( 6770.0/sec): GetImage 10x10 square
60000 trep @ 0.4545 msec ( 2200.0/sec): GetImage 100x100 square
4000 trep @ 8.0739 msec ( 124.0/sec): GetImage 500x500 square
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use a single code path to upload the image data after selecting the
right bo, and take advantage of pwrite() when possible.
Fixes:
Bug 28569 - [i965] IGN's flash-based video player crashes X
https://bugs.freedesktop.org/show_bug.cgi?id=28569
Bug 28573 - [i965] Fullscreen flash and windowed SDL games fail to
update the screen
https://bugs.freedesktop.org/show_bug.cgi?id=28573
Reported-and-tested-by: Brian Rogers <brian@xyzw.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We should be able to eliminate these as the drawable remains unchanged.
However, the implicit flush of BUF_INFO fixes the rendering in KDE.
Alternatively, we need an MI_FLUSH | INHIBIT_RENDER_CACHE_FLUSH between
composites. (Note that it is not stale cache data causing the rendering
corruption and that a pipelined flush is not sufficient either.) Also,
having tried varies points at which to flush, the only place where the
flush is effective seems to be between composite operations - that is a
flush after 2D is not sufficient.
Reported-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After d41684d545 we now allocate all framebuffers as tiled bo, and so
we must be careful to use the appropriate stride as returned from the
allocation, instead of assuming that it is just an aligned width.
Fixes:
Bug 28461 - screen rotation results in corrupted output.
https://bugs.freedesktop.org/show_bug.cgi?id=28461
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Till Matthiesen <entropy@everymail.net>
We depend upon the recent introduction of drm_intel_bo_is_reusable().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Julien Cristau <jcristau@debian.org>
Fixes:
Bug 28446 - Garbled Font with Mathematica 7
https://bugs.freedesktop.org/show_bug.cgi?id=28446
Rewriting the glyphs to render to the destination directly and removing
the more expensive multiple invocations of CompositePicture per picture
was a great performance boost -- except that it needs special handling
in the backend in order to not fallback. Having done so for i915, I
neglected to ensure the sanity checking in i965_prepare_composite() was
sufficient. As it turns out, it was not and so we misrendered CA-glyphs
when rendering directly to the destination. This causes us to fallback
properly, but is a performance regression as we no longer try the 2-pass
magic helper before resorting to s/w. At the moment, I'd rather live
with the temporary regression and fix i965 to do the same magic as i915,
as it critical to fixing the severe performance issues currently
crippling i965, as I believe that this regression only affects the
minority of applications (incorrect, as it turns out, as the glyphs are
overlapping) rendering directly to the destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if there is only a single clip rect, since the clip may be smaller
than the drawing rectangle on the destination we need to actually
compute the clipped glyph rectangle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Following a conversation with Owain G. Ainsworth, it was decided that
the second best approach to handling a wedged GPU was to hope that the
kernel could successfully reset it, which currently is only possible for
i965 and later chipsets.
The best approach is of course to prevent such hangs from ever occurring
in the first place.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
But emit the warning about rendering corruption every time for the
transient errors like out-of-memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When I made libdrm stop overallocating so much memory for the purpose
of bo caching, things started scribbling on the bottom of my
frontbuffer (and vice versa, leading to GPU hangs). We had the usual
mistake of size = tiled_pitch * height instead of size = tiled_pitch *
tile_aligned_height.
We need to install the acceleration functions so that they are wrapped
by the Damage layer. This fixes the corruption under a compositing WM
introduced in commit 8700673157.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
A trivial change, I thought, having tested it before rebasing, unworthy
even of a perfunctory compile test. How wrong I was.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The i915 textured video routine know how to handle drawing on an output
larger than the 3D pipe, so allow them to do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gcc is horribly bad at collapsing the constants:
text data bss dec hex filename
282336 8720 256 291312 471f0 intel_drv.so.old
269280 8720 256 278256 43ef0 intel_drv.so
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
All but uxa_copy_window() perform the preliminary checks for whether
acceleration is available. The simplest method for adding the fallback
for uxa_copy_window() seems to be to add it in the core copy function,
so be it.
This allows X to survive a little longer once we encounter a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use centre sampling of textures to match pixman, and remove numerous
off-by-one and visual artefacts when rendering. The classic example for
this is cairo/text/xcomposite-projection where the edge of the rotated
rectangle is jaggy due to the incorrect sample position.
Fixes:
Bug 16917 - [i915] Blur on y-axis also when only x-axis is scaled
billiear
https://bugs.freedesktop.org/show_bug.cgi?id=16917
And about 15 tests from the Cairo test suite.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
3DSTATE_BUF_INFO is an implicit flush of the piepline, so avoid emitting
that and associated state unless the destination pixmap has actually
changed. This is a win of around 3-5% for cairo-perf-trace, notably for
firefox.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris's new buffer exchange check is a good one, but we don't want to
hit the immediate blit fallback path if it fails. We still want to
schedule a blit for sometime in the future, and we need to use it
wherever an exchange might occur (like the secondary flip check or the
currently disabled CanExchange check).
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28252.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This is wildly optimistic, but it should work in a surprising number of
error situations and some output in those cases will be hopefully be
better than none...
If we submit a batchbuffer and the kernel reports the GPU is hung (which
will be caused by an earlier execbuffer, and so the kernel should have
had enough time to determine whether or not it could reset the GPU) then
disable any further attempt to accelerate gfx and force fallbacks to map
the buffers and use the CPU. We cannot normally map any more buffers if
the GPU is hung, so only those already mapped prior to the hang can be
written to, or those allocated in system memory. However, we can expect
that the framebuffer is already mapped, and so have a reasonable
expectation to continue to see the display update.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rewrite glyph rendering to avoid the intermediate buffer, accumulating
the glyph rectangles directly in the backend composite routines. And
modify the glyph cache routines to fully utilise the allocated size of
the tiled buffer on older hardware. To do this we alias all glyph sizes
into the same texture using a technique suggested by Keith Packard.
PineView:
885/856-> 1150/1110 kglyph/s (aa/rgb)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Handle rendering textured video onto an extended desktop (>2048) by
using a temporary pixmap. Note that we still cannot handle rendering to
a greater than 2048 destination region, for that we will need to tile.
Hmm, time to request a 2560x1600, 10bpc monitor...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
17:53 < arekm> ickle: i830_dri.c:630:28: error: ‘DrawableRec’ has no member named ‘bpp’
17:53 < arekm> ickle: i830_dri.c:630:57: error: ‘DrawableRec’ has no member named ‘bpp’
* sigh. I need to fix this machine to have the right version of the
* headers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An unredirected window (thanks Michel for the reminder) is backed by the
Screen pixmap, and so uses a reference of that as its front buffer. The
back buffer is a pixmap appropriately sized for the drawable. When the
application requests to swap its buffers, obviously we cannot simply
exchange the front and back buffer as they do not match, but need to copy
the appropriate region from the back to the front.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 44d45d3fa5.
Michel Dänzer pointed out the flaw in using the pixmap size instead of
the drawable size:
Using the backing pixmap dimensions for this is not desirable. In
particular, it means that the DRI2 buffers of non-redirected windows
always have the same size as the screen. But even for redirected windows
it wastes some graphics memory with a re-parenting window manager, that
is if it doesn't break in various ways due to the top left corner of the
DRI2 buffers no longer corresponding to the top left corner of the window.
This avoid using the garbage values stored in the Screen drawable,
instead of the true values which are only maintained in its backing
pixmap. The consequence of using the wrong size was to hand a 1x1
pixmap to metacity/mutter and have it believe it was a full screen
drawable; GPU hangs ensued if using page flipping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Julien Cristau
Carl Worth
Gaetan Nadon
Eric Anholt
Keith Packard
Jesse Barnes