If the target drawable is too large for the render pipeline, we need to
create a temporary surface. This may fail, so abort if it does.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Static analysers are dumb and presume readers are too.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to prevent a leak of the bo when the chain is eventually
torn-down when the client exits.
Reported-by: Andreas Lampersperger <lampersperger.andreas@heidenhain.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50670
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Time to blt from GTT to LLC 16384 bytes: 125.000µs (snb)
Time to blt from GTT to LLC 16384 bytes: 71.000µs (ivb)
Time to blt from GTT to LLC 1048576 bytes: 1400.000µs (snb)
Time to blt from GTT to LLC 1048576 bytes: 938.000µs (ivb)
Time to copy from GTT to LLC 16384 bytes: 118.000µs (snb)
Time to copy from GTT to LLC 16384 bytes: 134.000µs (ivb)
Time to copy from GTT to LLC 1048576 bytes: 6723.000µs (snb)
Time to copy from GTT to LLC 1048576 bytes: 7424.000µs (ivb)
And conversely,
Time to blt from LLC to GTT 16384 bytes: 10.000µs (snb)
Time to blt from LLC to GTT 16384 bytes: 8.000µs (ivb)
Time to blt from LLC to GTT 1048576 bytes: 217.000µs (snb)
Time to blt from LLC to GTT 1048576 bytes: 135.000µs (ivb)
Time to copy from LLC to GTT 16384 bytes: 4.000µs (snb)
Time to copy from LLC to GTT 16384 bytes: 4.000µs (ivb)
Time to copy from LLC to GTT 1048576 bytes: 270.000µs (snb)
Time to copy from LLC to GTT 1048576 bytes: 179.500µs (ivb)
It seems clear then that even with the extra synchronisation cost
copying from the GTT is much preferable with the GPU than using the
uncached reads by the CPU. Streaming write-combines from the CPU into
the GTT seem about as efficient as we can manage, so continue to use the
mapping unless busy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Regression from commit 3f3bde4f0c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu May 24 11:58:46 2012 +0100
uxa: Only consider an output valid if the kernel reports it attached
When backporting from SNA, a key difference that UXA does not track DPMS
state in its enabled flag and that a DPMS off CRTC is still bound to the
fb. So we do need to rescan the outputs and check that we have a
connector enabled *and* the pipe is running prior to emitting a scanline
wait.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50668
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These went away in the new server API, and really if this
made any measurable difference, I'd be impressed.
Signed-off-by: Dave Airlie <airlied@redhat.com>
We may as well continue the operation on the CPU if already bound to try to
reduce needless migrations (where the cost of the upload will outweigh
further use).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is already checked at the beginning of PutImageTextured, so this
check upon the return value of intel_get_pixmap_bo() should only be
required to keep static analysers happy.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This was written when the RGBA color value was being passed around and
not the pointer to the xRenderColor. As such, the NULL deref check
doesn't gain much and the check for rgba==0 irrelevant in this scenario.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
And assert that the allocation succeeds for good measure. A great big
dollop of graceful failure is missing...
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the static analyser also doesn't like comparing a uint8_t against
~0.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to reduce the volumes of output from static analysers.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code paths are too twisty to be sure otherwise.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Impossible with the current code, the server aborts on failure. However,
this looks to be the simple answer to keep static analysers quiet.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The return from __kgem_throttle_retire() is just a hint as to whether
any forward progress was made. In the case of the error path, though it
is a last ditch effort before aborting, so we do not really care whether
or not it succeeds, we must try again.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This should help the static analyzer pinpoint the blame and make it
quieter.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Dave Airlie