This reverts commit 6d50553e8f.
Now we have taught the fallback path not to infinitely recurse,
re-enable the accelerated path for ShmPutImage and friends.
Often, for example in the fallback for ShmPutImage, we will attempt to
use uxa_copy_area() copying to a normal pixmap from a memory buffer.
This triggers a fallback, and maps the destination pixmap back into the
GTT. The accelerated put_image path will attempt to stream a blit to the
destination pixmap if it is currently active, avoiding the stall.
Do not try to fixup the alpha in the ff/shaders as this has the
side-effect of overriding the alpha value of the border color, causing
images to be padded with black rather than transparent. This can
generate large and obnoxious visual artefacts.
Fixes:
Bug 17933 - x8r8g8b8 doesn't sample alpha=0 outside surface bounds
http://bugs.freedesktop.org/show_bug.cgi?id=17933
and many related cairo test suite failures.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code was using uint32_t where an XID (currently an unsigned long)
was specified in the prototype. Use XID to avoid both the warning and
any potential problem.
In separating the boolean logic out into a separate function, dc6522dd,
I reversed the sense of one particular test:
src->format == dst->format
The OVER optimisation is only valid if the src and dst formats match,
but not always.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On failing to extract the pixel value for an alpha-only solid we
actually triggered a fallback. Since this path is commonly hitting
whilst fading in images, for example cairo_paint_with_alpha(), the
fallback was detected during the Moblin boot sequence where it was
adding a second to the overall boot time.
See
fallback intel: Moblin startup is hitting a composite fallback, costing
a ton of performance
https://bugs.freedesktop.org/show_bug.cgi?id=26189
Based on the initial patch by Arjan van de Van.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The prototype says this function returns a Bool and not just an int, so
be pedantic and return TRUE/FALSE.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One of the convoluted if branches dereferenced Drawable when it is
potentially NULL. Avoid this by explicitly handling the NULL Drawable
cases earlier, and enabling solid fills for solid sources.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I added a jump if there was no src or mask Drawable, but we do actually
need to check for useless src repeats even if we have a source-only
mask.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The fallback log for http://bugs.freedesktop.org/show_bug.cgi?id=26189
does not actually state the reason why we actually fallback. This is
possibly because we need to fallback for reasons other than the
operation cannot be performed in hardware -- such as using an alpha map
or the screen is swapped out, so add this information to the fallback
log.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 3f11bbec42.
For unknown reasons, enabling tiling for the glyph cache is causing
glyph corruption both across suspend and resume and VT switching, on a
wide range of chipsets (reports include both i8xx and gm45)
This strongly suggests that we are handling tiling, or updates to tiled
buffers, incorrectly across i915_gem_idle(). However, until we can find
the root cause, we want to fix this regression before the next stable
release, so simply revert this patch. :(
Fixes:
[Bug 25406] fonts garbled after resuming from suspend since 6729b508http://bugs.freedesktop.org/show_bug.cgi?id=25406
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Maintain a small cache of pixmaps to hold SolidFill pictures. Currently
we create a pixmap the size of the damaged region and fill that using
pixman before downloading it to the GPU and compositing. Needless to say
this is extremely expensive compared to simply emitting the solid
colour. To mitigate this cost, we maintain a small cache of 1x1R
pictures which is recognised by the driver as being a solid, but at the
very least is maintained as a GPU ready pixmap.
This gives a good boost to cairo-xcb (which uses solid fills) on a gm45:
Before:
gnome-terminal-vim: 41.9s
After:
gnome-terminal-vim: 31.7s
Compare with using a cache of 1x1R pixmaps in cairo-xcb:
gnome-terminal-vim: 31.6s
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Around a call to uxa_put_image() it is possible to mix both accelerated
and fallback paths, with the fallback code making the presumed
optimisation of only trying to call uxa_prepare_access() once. This
fails if the accelerated path also uses prepare/finish access on the
same drawable and then later fallback to the fallback path. This can
happen currently if an error is reported whilst attempting to accelerate
PutImage.
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:162
#1 0x00007ffff43ce4bd in fbBlt (srcLine=<value optimized out>, srcStride=40, srcX=<value optimized out>, dstLine=0xffffffffffffffff, dstStride=64, dstX=0, width=<value optimized out>, height=8, alu=3, pm=4294967295, bpp=8, reverse=0, upsidedown=0) at fbblt.c:93
#2 0x00007ffff43ce740 in fbBltStip (src=0xffffffffffffffff, srcStride=156555204, srcX=34, dst=0xfffffffc, dstStride=64, dstX=40, width=304, height=8, alu=3, pm=4294967295, bpp=8) at fbblt.c:944
#3 0x00007ffff4c32c53 in uxa_do_put_image (pDrawable=0x246aa410, pGC=0x2c0a4f0, depth=8, x=0, y=0, w=38, h=8, leftPad=0, format=2, bits=0x954d7c4 "") at uxa-accel.c:196 #4 uxa_do_shm_put_image (pDrawable=0x246aa410, pGC=0x2c0a4f0, depth=8, x=0, y=0, w=38, h=8, leftPad=0, format=2, bits=0x954d7c4 "") at uxa-accel.c:223
#5 uxa_put_image (pDrawable=0x246aa410, pGC=0x2c0a4f0, depth=8, x=0, y=0, w=38, h=8, leftPad=0, format=2, bits=0x954d7c4 "") at uxa-accel.c:289
#6 0x00000000004d574f in damagePutImage (pDrawable=0x246aa410, pGC=0x2c0a4f0, depth=8, x=0, y=0, w=38, h=8, leftPad=0, format=2, pImage=0x954d7c4 "") at damage.c:905
#7 0x00000000004287db in ProcPutImage (client=0x47ca72d0) at dispatch.c:2073
#8 0x000000000042bd94 in Dispatch () at dispatch.c:445
#9 0x000000000042513a in main (argc=4, argv=0x7fffffffe2a8, envp=<value optimized out>) at main.c:285
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid mapping the glyph cache back to the cpu by allocating temporary
buffer objects to store the glyph pixmap and blit to the cache.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Particularly noting to route alpha to the green channel when blending
with a8 destinations.
Fixes:
rendercheck/repeat/triangles regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25047
introduced with commit 14109a.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the case of x8r8g8b8 and similar where the alpha channel is ignored,
but should be interpreted as being 1, then it is convenient if those bits
are set appropriately in the colour. In order to do so for these formats,
where PIXMAN_FORMAT_A() returns 0 we need to compute the alpha channel
width as the remaining bits instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This avoids a crash when an XRenderComposite call is made with a
-1 value for width/height, (which apparently compiz's gtk-window-
decorator likes to do). Fixes bug:
X crashes in uxa_acquire_pattern when logging in (gdm)
http://bugs.freedesktop.org/show_bug.cgi?id=24724
Signed-off-by: Albert Damen <albrt@gmx.net>
Reviewed-by: Carl Worth <cworth@cworth.org>
Pull the common methods for creating a Picture given a pixman format
into its own method, and tidy the surrounding code. The benefit is that
we can now composite directly to the Picture and so save an intermediate
copy when creating patterns for gradients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We've talked about doing this since the start of the project, putting it off
until "some convenient time". Just after removing a third of the driver seems
like a convenient time, when backporting's probably not happening much anyway.
Carl Worth did the hard work in identifying that the regression in
cairo between X.org 1.6 and 1.7 was caused by cairo sending an a1
mask to the server in 1.7 whereas in 1.6 cairo used local fallbacks
(as the source was using RepeatPad, which triggers cairo's
'buggy_pad_reflect' fallback for X.org 1.6). This was causing the driver
to do a fallback to handle the a1 mask instead, which due to the GPU
pipeline stall is much more expensive than the equivalent fallback in
cairo.
Reference:
cairo's performance downgrades 4X with server master than server-1.6.
https://bugs.freedesktop.org/show_bug.cgi?id=23184
The fix is a relatively simple extension of the current
uxa_picture_from_pixman_image() to use CompositePicture() instead of
CopyArea() when we need to convert to a new format.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently when asked to composite using a gradient source or mask, we
fallback to using fbComposite(). This has the side-effect of causing a
readback on the destination surface, stalling the GPU pipeline. Instead,
like uxa_trapezoids(), we can use pixman to fill a scratch pixmap and then
copy that to an offscreen pixmap for use with uxa_composite().
Speedups on i915:
firefox-talos-svg: 710378.14 -> 549262.96: 1.29x speedup
No slowdowns.
Thanks to Søeren Sandmann Pedersen for spotting the missing
ValidatePicture().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This lets the driver allocate a nice idle buffer object instead of a
busy one, reducing runtime of firefox-20090601 on my G45 from 50.7 (+/- .41%)
to 48.4 (+/- 1.1%).
This was needed when we were doing the mask computations in this pixmap,
but now they're done in a temporary and then uploaded later.
This reduces runtime of firefox-20090601 from 52.6 (+/- .96%) to 50.7
(+/- .41%) seconds on my G45.
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers
need to include dpmsconst.h if xextproto 7.1 is available.
SHM is now shm.h instead of shmstr. Requires definition of ShmFuncs that's
not exported by the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't do it, treat this the same as every other prepare access call in uxa.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Owain Ainsworth <zerooa@googlemail.com>
Since we're only doing software rasterization right now, anyway, it
makes more sense to just rasterize to system memory and then upload
to a pixmap once complete. This avoids expensive read-modify-write
cycles.
This results in a 2.4x speedup for a real-world test case that's
heavy on trapezoids, which is swfdec running on the following file:
http://michalevy.com/wp-content/uploads/Giant%20Steps%202007.swf
Many thanks to Chris Wilson for his cairo-traces repository and
cairo-perf-trace tool which makes it so easy to measure things
like this.
With glyphs sitting in per-glyph pixmaps, there's no reason to use the CPU
to move them to the cache pixmap, and lots of reasons to use the accelerator.
Signed-off-by: Keith Packard <keithp@keithp.com>
Chris Wilson
Eric Anholt
Gaetan Nadon
Carl Worth
Rémi Cardona
Albert Damen
Keith Packard
Peter Hutterer
Owain Ainsworth
Alan Coopersmith