| Age | Commit message (Collapse) | Author |
|---|
|
In an interesting twist during teardown, the driver info structure is
freed long before the caches. However, the glyph cache teardown was
checking to see if glamor was enabled to see if it could skip the
teardown. In fact, since we won't have created the glyph caches in that
circumstances it was safe any way.
Reported-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
glamor_glyphs will never fallback. We don't need to keep a
uxa glyphs cache picture here. Thus simply bypass the
corresponding operations.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To complete my show of incompetence for the evening, not only do we have
to restore the original source when compositing the mask onto the
destination, we also need to restore the original dst (rather than
composite the mask onto the mask!).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In 64a4bcb8cefff, I introduced a WHITE source for the purposes of
accumulating the glyph mask correctly. Unfortunately I neglected to
restore the original source picture for compositing the glyph mask on
the destination, resulting in a use-after-free and then corruption.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
An earlier version was buggy and introduced corruption as it failed to
fallback gracefully with ComponentAlpha glpyhs. This is a much simpler
implementation that composites each glyph individually, leaving it to the
backend to optimise away state changes. It should still be many times
faster than incurring the fallback...
Reported-by: Oleksandr Natalenko <pfactum@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50508
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As pointed out by Soren Sandmann and Behdad Esfahbod, it is essential to
use white IN glyph when adding to the mask so that the channel expansion
is correctly performed when adding to an incompatible mask format.
For example, loading alpha as the source results in the value 000a being
added to the rgba glyph mask (for mixed subpixel rendering with
grayscale glyphs), whereas the desired value is aaaa.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
This ports the legacy and uxa driver to the new server API.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This looks to be unused.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The compat-api.h takes care of old/new servers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The compat header takes care of the old server vs new server.
this commit was autogenerated from util/modular/x-driver-screen-scrn-conv.sh
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
==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>
|
|
|
