All SourcePictures are now converted into Drawables, which had been
assumed by the driver backend. However, the code still existed to
attempt to pass procedural pictures onwards and so set pSrcPix to NULL
which was being flagged by the static analyser as a potential NULL
dereference.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It was broken and not flushing damage correctly. With the
improvements made to the kernel, it is no longer a significant advantage
per se and not worth its additional complexity.
Reported-by: Tilman Sauerbeck <tilman@code-monkey.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32547
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With the introduction of GEM, we can continue to submit batch buffers
irrespective of ownership of the console, so do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This commit hooks up all the remaining rendering routines to call into
glamor; the takeover is nearly complete! When tested with the latest
glamor master branch, it passes rendercheck.
One thing need to be pointed out is the picture's handling.
Pictures support many different color formats, but glamor's
texture only support a few color formats. And the most common
scenario is that we create a pixmap with a color depth and
then attach it to a picture which has a specific color format
with the same color depth. But there is no way to change a
texture's internal format after the texture was allocated.
If you do that, the OpenGL will allocate a new texture. And
then the glamor side and UXA side will be inconsitent. So
for all the picture related operations, we can't fallback to
UXA path directly, even it is rather a straight forward
operation. So for the get_image, Addtraps.., we have to add
wrappers function for them to jump into glamor firstly.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
[ickle: prefer access; ok = glamor(); finish; if (!ok) goto fallback; return; ]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Integrate glamor acceleration into UXA framework. Add
necessary flushing at the following points:
1. Flush UXA batch buffer before call into glamor.
2. Flush GL operations after return from a glamor function.
3. The point we need to flush UXA batch buffer, we also
need to flush GL operations, for example, in
intel_flush_callback and couple of places in intel_display.c.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the render operation requires a temporary source Picture and the
operation is large, larger than the maximum permitted bo, then we will
fail to allocate the bo. In this case, we need to fallback and perform
the operation on the CPU rather than dereference a NULL bo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34399
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
uxa_acquire_solid returns NULL under OOM. Thus the value of solid
must be checked before dereferencing it in the uxa_get_offscreen()
call.
Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The region is used to paint onto the backing pixmap (and thus
translated) prior to being passed to the damage layer (wrt to the
drawable). So the local translation needs to be undone first.
Identified by Christopher James Halse Rogers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33650
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
[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>
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>
References:
Bug 28098 Compiz renders shadows wrong, garbage line of pixels along left
and top edge of windows
https://bugs.freedesktop.org/show_bug.cgi?id=28098
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I'm seeing garbage alpha for rendercheck blend:
x8r8g8b8a 10x10 SRC ar8g8b8a
so disable blitting until I work out if we can fast-path it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow us to check whether we can handle the operation using the blitter
prior to doing any work.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the change to prevent blitting between incompatible sources, we also
prevented 1x1R pixmaps from being used for solid fills. Reorder the
sequence of conditions to enable this fast path again.
If we are destined to target an !offscreen drawable, then uploading the
trapezoid mask to a bo is the last thing we actually want to do...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Eric Anholt
Zhigang Gong
Bryce Harrington
Matthias Hopf