Age | Commit message (Collapse) | Author |
|
As the contents of the pixmap are now rubbish, we need to manually
destroy it rather than pass it to the normal sna_pixmap_destroy()
routines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Verified on real hw, this undocumented (at least in the bspec before me)
bug truly exists.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The fast version of damage checking assumes that the damage has already
been determined to be non-NULL, so make sure it is.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
And keep the asserts that lead to its discovery.
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>
|
|
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>
|
|
When glamor is enabled, a pixmap will not be accessed by UXA's
accelerated functions. Only unaccelerated functions may access those
pixmaps, and before each unaccelerated rendering, it calls
uxa_prepare_access which will do a glFlush. Combined with a flush before
sending to DRI clients, we no longer need to flush after every
operation.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Make the tests for acceptable GPU pixmaps explicit and upfront.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
And accept second-best only if permitted by flags.
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid the repeated multiple indirect dereferences.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
damage
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
valgrind was complaining about an overlapping memcpy on a 64-bit
platform as gcc padded the sna_damage_box to 28 bytes...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For gen3, we may reduce a source into a constant operator and so
dispense with keeping a bo. When duplicated into the mask channel, we
then need to be careful not to dereference the NULL pointer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As this causes a significant regression when benchmarking firefox on SNB
with firefox-planet-gnome if we already have CPU buffers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As reallocation of bo is the most frequent cause of malloc/free.
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit 2934e778f01cdf1307732b248b11a31c0e79e866. The actual
cause of the bug I was seeing on my PNV box turned out to be
a1f585a3d0a, so time to reinvestigate the alignment issues.
|
|
A regression from eb859f644633e left some of the state uninitialised
before uploading to the GPU leading to undefined behaviour.
Reported-by: Alexey Shumitsky <alexey.shumitsky@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44338
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44252
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>
|
|
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>
|
|
The goal is to avoid introducing extra latency in the middle of a
command sequence and to delay it until we have to wait for the clients.
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>
|
|
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>
|
|
If the operation is favoured to be performed using a WC upload, presume
that we will use the uploaded pixmap on the GPU and so prefer to create
a GPU buffer to hold the fresh data.
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>
|
|
Now that the error propagation is actually in place, we may as well use
it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The symbols required for building intel_dri.c are checked during
configure under the DRI2 defines.
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>
|
|
As these will only be created in normal memory and never used.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid the extra composite-in pass for simple clipmask construction.
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>
|