| Age | Commit message (Collapse) | Author |
|---|
|
==1401== 7,344 bytes in 34 blocks are possibly lost in loss record 570 of 587
==1401== at 0x4027034: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1401== by 0x8BE5150: drm_intel_gem_bo_alloc_internal (intel_bufmgr_gem.c:689)
==1401== by 0x899FC04: intel_uxa_create_pixmap (intel_uxa.c:1077)
==1401== by 0x89C2C41: uxa_glyphs (uxa-glyphs.c:254)
==1401== by 0x21F05E: damageGlyphs (damage.c:647)
==1401== by 0x218E06: ProcRenderCompositeGlyphs (render.c:1434)
==1401== by 0x15AA40: Dispatch (dispatch.c:439)
==1401== by 0x1499E9: main (main.c:287)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Vincent Untz <vuntz@gnome.org>
Reported-by: Robert Bradford <robert.bradford@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48045
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>
|
|
The previous version calls glamor_egl_close_screen and
glamor_egl_free_screen manually which is not align with
standard process. Now glamor change the way to follow
standard method:
glamor layer and glamor egl layer both have their internal
CloseScreens. The correct sequence is after the I830CloseScreen
is registered, then register glamor_egl_close_screen and
the last one is glamor_close_screen. So we move out the
intel_glamor_init from the intel_uxa_init to I830ScreenInit
and just after the registration of I830CloseScreen.
As the glamor interfaces changed, we need to check the
glamor version when load the glamor egl module to make
sure we are loading the right glamor module. If
failed, it will switch back to UXA path.
This depends upon glamor commit 1bc8bf tagged with version 0.3.0.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We have to route all the drawing function to glamor first, when
glamor is enabled. This adds a few more functions that were previously
just falling back to swrast and passes them to glamor instead.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we are using GLAMOR, then a tile pixmap or stipple pixmap
may be pure glamor pixmap and thus UXA will not know how to
render to them, and we need to let glamor do the validation.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
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>
|
|
So that we avoid leaking the region if hooking into glamor.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The danger of the early return when UXA is not using glyphs is evident
in the eventual crash when glamor begins evicting and reusing its glyph
cache slots.
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>
|
|
Fixes regression from e0066e77e026b0dd0daa0c3765473c7d63aa6753
(uxa: Simplify Composite solid acceleration for spans by only clipping
once) [2.15.901]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43649
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This commit only enables two glamor functions for
uxa_fill_spans and uxa_poly_fill_rects.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
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>
|
|
Reported-by: Hans-Peter Budek <peter.budek@gmx.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Uli Schlachter <psychon@znc.in>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31819
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Not ideal, but being slow is a major improvement over losing data.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36860
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The attempt was still ridden with bugs, such as
http://bugs.freedesktop.org/show_bug.cgi?id=28768
http://bugs.freedesktop.org/show_bug.cgi?id=28798
http://bugs.freedesktop.org/show_bug.cgi?id=28908
http://bugs.freedesktop.org/show_bug.cgi?id=29401
A fresh approach was taken with SNA, but in the mean time before that
can be enabled downstream, restore correct behaviour.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Unlike the previous commit removing this style of code, the code in
this one was originally wrong, and would fail to clip in the second
pass of clipping when y was > pbox->y2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37233
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
We were clipping each span against the bounds of the clip, throwing
out the span early if it was all clipped, and then walked the clip box
clipping against each of the cliprects. We would expect spans to
typically be clipped against one box, and not thrown out, so we were
not saving any work there. For multiple cliprects, we were adding
work. Only for many spans clipped entirely out of a complicated clip
region would it have saved work, and it clearly didn't save bugs as
evidenced by the many fix attempts here.
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
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>
|
|
The screen resources are recreated when the screen is rotated as well,
without being finalized. In this case, we do not need to reconstuct the
cache (or if we did, we would need to tear it down first).
Reported-by: Till Matthiesen <entropy@everymail.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33412
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31487
Reported-by: Thomas Fjellstrom <tfjellstrom@shaw.ca>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Signed-off-by: Matthias Hopf <mhopf@suse.de>
|
|
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>
|
|
Fixes:
Bug 29187 - crash in intel_drv
https://bugs.freedesktop.org/show_bug.cgi?id=29187
Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60]
3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x34684) => uxa/uxa-render.c:841
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>
|
|
Signed-off-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
|
|
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Check for the NULL Picture prior to passing it to the backends for
inspection.
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit f429fb9d872950705e11171d0e7407fb7673c786.
An experimental patch I forgot was on my main branch as I was bugfixing.
ARGH!
|
|
Fixes the crash reported in:
Bug 28446 - Garbled Font with Mathematica 7
https://bugs.freedesktop.org/show_bug.cgi?id=28446
pDst=0x3d663c0, src_x=0, src_y=0, xDst=142, yDst=112, nlist=0,
list=0x7fffea026580, glyphs=0x7fffea025d88, extents=0x0)
at uxa-glyphs.c:809
dx = 0
y1 = 101
x2 = 150
x1 = 142
dy = 0
y2 = 112
rects = 0x5491000
this_atlas = 0x2456d00
mask_y = 128
glyph = 0x35933a0
mask_x = 736
priv = 0x39309e0
screen = 0x8d2cc0
uxa_screen = 0x2443eb0
src_pixmap = 0x37c29e0
dst_pixmap = 0x45ddbf0
localSrc = 0x361a450
glyph_atlas = 0x2456d00
x = 142
y = 112
n = 18
nrect = -9975128
box = {x1 = 23152, y1 = -5630, x2 = 32767, y2 = 0}
__PRETTY_FUNCTION__ = "uxa_glyphs_to_dst"
Though the meat of that bug regarding the incorrect remains unsolved.
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 8700673157fdd3a87ad5150f2f30823261fec519.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
|
|
This is quicker and smaller than the old indirect function call to
dixLookupPrivate().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
