Since we call kgem_bo_submit() along one path when synchronising a
cached bo (which is known to be inactive) but still want to keep the
assertion on the refcnt, simply rearrange the code to only assert on the
active path.
References: https://bugs.freedesktop.org/show_bug.cgi?id=73406
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One day, just not today, we may make gen4 work correctly, efficiently and
fast. Today, we can barely pick one.
References: https://bugs.freedesktop.org/show_bug.cgi?id=55500
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One path uses the mask channel, the other does not. We cannot rely on
overwriting all reused state in this case, and so we must clear the
composite state prior to use each time.
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74494
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Logic reversal in discarding CPU damage. An old bug revealed by the more
aggressive attempts to discard CPU damage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the CPU bo is wholly damaged, then it makes an ideal candidate for
simply converting into the GPU bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we upload outside of the replaced region to the GPU, we need to
remark the region of operation as dirty.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When considering move-region-to-cpu, we need to take into account that
the region may not replace the whole drawable, in which case we cannot
simply dispose of an active CPU bo.
Reported-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reported-by: Conley Moorhous <conleymoorhous@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74327
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In addition to the UXA texture paths (which in theory support VSync) and
direct overlay support, create a textured video paths that utilize the
glamor acceleration code.
Requested-by: Fabio Pedretti <fabio.ped@libero.it>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74311
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The short-circuit path missed translating the damage from drawable space
into the pixmap (for Composite setups) which may have resulted in
corruption. The path was also failing to consider the impact of reusing
an active CPU bo when it could be discarding the unwanted damage and
reallocating.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Too many users where unhappy that their software was broken. Too bad the
same software is also broken at high bit depths as well.
References: https://bugs.freedesktop.org/show_bug.cgi?id=73877
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A couple bugs ended up with CPU bo gradually accumulating whilst the
overall number of bo vanished.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
commit 3dbf17f00e [2.99.907]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Dec 3 12:10:01 2013 +0000
sna: Mark up an ordinary pixmap for reuse
started to put the frequently allocated pixmaps into the object cache -
but as those frequent allocations themselves did not use the cache, the
cache kept growing.
Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1272338
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This needs to be visible whenever we --enable-debug=memory. Make it so,
and trim it to a single line in the process.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
sna_display.c: In function 'preferred_mode':
sna_display.c:3393:7: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
mode = xf86GetOptValString(output->options, OPTION_PREFERRED_MODE);
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We allocated and own the string, so we can free it!
sna_display.c: In function 'sna_output_get_modes':
sna_display.c:2314:4: warning: passing argument 1 of 'free' discards 'const' qualifier from pointer target type [enabled by default]
free(current->name);
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The backlight_iface is a freeable string, in places we were assigning a
constant string and later freeing it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We keep a pointer to the old funcs when wrapping, this now needs to be const.
sna_accel.c: In function 'sna_gc_move_to_cpu':
sna_accel.c:4008:17: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
sgc->old_funcs = gc->funcs;
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regression from
commit 8b0ebebcab
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jan 28 16:30:47 2014 +0000
sna: Be a little more assertive in retiring after set-domain
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74176
Reported-by: Jan Alexander Steffens <jan.steffens@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can at least check that it is in the right region (i.e. not past
where the current surface has been allocated from).
References: https://bugs.freedesktop.org/show_bug.cgi?id=74176
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Dashed zero-width lines devolve into two passes (first to draw the
foreground dashes, and then to draw the gaps). The code was using the
pixel value to decide which phase was being drawn -- however the color
on the gc is not always bit exact (e.g. alpha channel) with the pixel
value. As a result, we would oft miss drawing anything when rendering
into the scanout.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1059152
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
First try using the blt path for a potential inplace upload for a
simple composite operation copying from a ShmPixmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have not had cause to flush the wait_for_shadow buffer during the
course of the rendering, then we never wrote to the backbuffer and its
contents are still identical to the current frontbuffer. So if the
wait_for_shadow is still flagged as required on the scanout, we know we
can safely discard the redisplay request.
References: https://bugs.freedesktop.org/show_bug.cgi?id=70905
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
set-domain-ioctl should only ever fail for invalid user input, beyond
the normal signal handling. As such if we do find a spurious error
return from the kernel, check for a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After a successful set-domain for writing with the CPU, we know that the
buffer is idle so remove it from our request tracking. (External clients
complicate matters in that they may keep the bo active even after our
set-domain.) On the contrary, because of read-read optimisations a bo
may still be active after a set-domain for reading by the CPU, in which
we need to remain conservative in retiring the bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the kernel reports an error from setting the DPMS property, we need
to undo the local changes and propagate back the error to the caller.
Although the latter is prevented by the RandR API, we can at least
restore the backlight.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to allocate new damage boxes, first try collescing the
existing boxes to free up memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to flush the batch if we run out of space aligning our vertex
buffer - but the test must anticipate the space required for the new
alignment.
Reported-by: Arkadiusz Miskiewicz
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can now check whether the Composite operation will require existing
CPU damage and if not discard it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This bit only exists for gen4+ so avoid setting it on gen2 and gen3,
whilst setting it doesn't seem to cause any harm, there is no reason to
risk it...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Composite operations were presumed to cover their entire width x height
area. However, a few paths submit boxes that do not cover the clip
region and so the optimisation made during prepare to discard completely
overwritten data is incorrect (and leads to corruption - stale data is
seen which the client expected to have been overdrawn). So along these
more unusual paths, we must add a flag to prevent the overzealous
discard. Notably, xfce4 triggers this as it uses a lot of unantialiased
trapezoids in its theme drawing.
References: https://bugs.freedesktop.org/show_bug.cgi?id=69528
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Inspired by (ok, copied from):
xf86-video-ati commit f2a0a5cf6c5a21e2a02280e110a4eb8e6609dace
Author: Michel Dänzer <michel.daenzer@amd.com>
Date: Wed Jan 22 11:04:42 2014 +0900
Don't require the glamoregl module to be pre-loaded with xserver >= 1.15
The issues with loading it on demand have been fixed in xserver 1.15.
Inspired by Jérôme Glisse on IRC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Edward Sheldrake