To enable DRI we create GEM buffers for the client to render into with
hardware acceleration. In order to maintain coherency between any 2D
render operations with the independent 3D clients (this includes the
reading of 2D rasterisation by the direct rendering client, e.g.
compiz using texture_from_pixmap) we need to replace the shadow pixmap
with the GTT mapping. Therefore 2D rendering to a DRI buffer will be to
uncached memory and thus penalised -- but the direct rendering clients
will have full hardware acceleration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An attempt to workaround the incoherency in gen2 chipsets, we avoid
using dynamic reallocation as much as possible.
The first step is to disable allocation of pixmaps using GEM and simply
create them in system memory without a backing buffer object. This
forces all rendering to use S/W fallbacks.
The second step is to allocate a shadow front buffer and assign that to
the Screen pixmap. This ensure that the front buffer remains in the GTT
and pinned for scanout. The shadow buffer will be rendered to in the
normal fashion via the Screen pixmap, and be marked dirty. In the block
handler, the dirty shadow buffer is then blitted (using the GPU) over
the front buffer. This should completely avoid having to move pages
around in the GTT and avoid incurring the wrath of those early chipsets.
Secondly, performance should be reasonable as we avoid the ping-pong
caused by the small aperture and weak GPU forcing software fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than assert, we should fixup the use of large A1 glyphs. However,
the simplest approach is to simply fallback to s/w.
Fixes:
Bug 29430 - [UXA] Crash due assert (uxa_pixmap_is_offscreen(src_pixmap));
https://bugs.freedesktop.org/show_bug.cgi?id=29430
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This avoids a memory leak on server reset.
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: Added comments from Keith that explain the necessity of
destroying the pixmap ourselves and why chaining up in this instance is
not the correct approach.]
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
planemask is an unsigned long initialised to ~0, on 64-bit this is not equal
to an (unsigned int)-1.
Use the macro provided to do this.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the source is outside the drawable, then CopyArea will fail to
initialise the source correctly. The simplest fix in this case is to
fallback to pixman to generate the source texture.
Fixes:
Bug 28497 - Graphics corruption after opening a specific website
https://bugs.freedesktop.org/show_bug.cgi?id=28497
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A slight confusion in computing the correction image location resulted
in the application of the source offsets to the pixel location in the
target and not in the source as intended.
Fixes the visual corruption of the scrollbar in Chromium, and hopefully
the crash reported by Robert Hooker when starting gdm after plymouth.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Now with streaming uploads and downloads for composite operations in
place, shared memory pixmaps are no longer that dire performance wise.
With careful use these can in fact be the most efficient means of
transfer between a wholly software renderer in the client and a backing
store. For instance, Chromium renders internally to an ARGB32 image
buffer and uses a shared pixmap to composite dirty regions into the
backing store. Thereby using the GPU to either perform the blit or the
format conversion. Enabling shared pixmaps, reduces our CPU overhead
whilst scrolling by a factor of 5 or so.
And this is achieved simply by deleting obsolete code!
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>
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>
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>
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>
As we are in full control of the destination (the temporary glyph mask)
and the source (the glyph cache) we know that there are no clip regions
on either and so can skip computing the composite rectangles. (We trust
the device clipping to prevent compositing outside the target.)
x11perf on PineView:
701/686 -> 881/856 kglyphs/s [aa/rgb]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Until we actual resize the glyph cache dynamically, make it obvious to
the reader and the compiler that the size is fixed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Store the cache position directly on the glyph using a devPrivate rather
than an through auxiliary hash table.
x11perf on PineView:
650/638 kglyphs/s -> 701/686 kglyphs/s [aa/rgb]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[xserver-1.8] The damage layer doesn't wrap CompositeRects, so we need to
manually append the damaged region ourselves. This works for
miCompsiteRects since that translates the call into multiple invocations
of either PolyFillRectangle or Composite, which themselves cause damage.
Fixes:
Bug 28120 - Tint2's tooltip borders end up at 0,0 and do not disappear
https://bugs.freedesktop.org/show_bug.cgi?id=28120
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since we have at most 8 bits of alpha, we treat >= 0xff00 as opaque.
However, being paranoid we should set the alpha value to 0xfff in case
something unexpected happens when converting from the xRenderColor to
the pixel value.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Due to the relocation overhead, using a single composite with many
rectangles outperforms many solid blits.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the destination cannot fit into the 3D pipeline when we need to
composite, we fallback to doing the operation on the CPU. This is very
slow, and quite easy to trigger on i915 by plugging in an external
display.
An alternative is to extract the extents of the operation from the
destination using the blitter which can usually handle much larger
operations. This gives us a temporary target that can fit into the 3D
pipeline and thus be accelerated, before copying back into the larger
real destination.
For x11perf this boosts glyph rendering on PineView, from 38kglyphs/s to
480kglyphs/s. Just a little shy of the native performance of 601kglyphs/s
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Without using a mask and compositing directly onto the destination,
takes us from 580 kglyphs/s to 850 kglyphs/s on i945 [x11perf -aa10text].
However, the extra intersection check almost entirely cancels out the
speed up and we discover that the glyphs in x11perf are always
overlapping. Nothing is ever easy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When compositing, we need to convert the box into a rect and so the
advantages of using REGION_TRANSLATE are lost.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use composite rather than solid blits in order to bring performance on
a par with the CPU when using GEM and relocations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Set the correct offset for the gradients patterns after rendering to a
local Picture.
Fixes cairo/test/huge-radial and friends
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the source may not cover the extents, we need to represent those
areas as transparent in the fallback picture, ergo we need an alpha
channel. We could be smarter and force a format conversion when
necessary, and we could let the backend choose the most appropriate
format.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Matthias Hopf
Keith Packard
Fernando Carrijo
Dave Airlie
Eric Anholt