Device sections without a Driver property would lead to a server
segfault because of a NULL pointer's being passed as the second
argument of xf86nameCompare().
Debian bug #677206 <http://bugs.debian.org/677206>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Copy the current framebuffer for smooth wayland->gdm handoff.
This has been hanging around in Fedora for too long now, and we've
dropped the feature a few times, and yes I know the Simpsons did it^W^W^W
SNA does it.
I've updated the code to have some of the better fixes from nouveau.
I've no idea who wrote this code either, krh or ajax. [ickle: The
earliest version I've found had krh's fingerprints on it, though it may
still have been a joint effort.]
Signed-off-by: Dave Airlie <airlied@redhat.com>
[ickle: improve error handling, only copy the fb during initial takeover]
Looks to be unused by the core, just a solitary invocation in an obscure
extension it seems. However the implementation looks trivial so
incorporate it until it is finally removed, just in case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The export wrappers for the glyph cache constructor/destructor existed
in case there was a need to add more routines. Since that never
happened, remove the extra step of indirection.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Prior to finalizing the defaults I changed my mind and realised that the
default had to reflect the current behaviour of someone enabling SNA for
the first time, and not the previous behaviour of --enable-sna to
override UXA. This is so that distro's could offer an SNA enabled DDX
for the brave whilst not affecting their typical no-xorg.conf users.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the user specifies no options, assume automatic selection. Then
double check we found a valid backend and so avoid later breaking the
build.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since these require non-upstream patches to other components, we don't
want it enabled by default and randomly breaking builds.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An inconsistency highlighted by 7c51cabaec revealed that we had a
mismatch between the check in move_to_gpu() and how we created the
pixmap. This mismatch resulted in us creating and uploading tiled
pixmaps for single shot textures, and the increase aperture pressure was
causing a regression in firefox-fishbowl on pnv, for example.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As ErrorF/fprintf is not re-entrant due to its mutex we can not use DBG
from code that could be called by a signal handler. X's SIGIO handler
attempts to move the cursor from within the handler (eek!) and so we
need to be careful not to take any locks, such in as the aforementioned
fprintf, along the cursor paths.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=50744
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even with a 1nm process, I doubt we will see 4+GiB cache sizes ;-)
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
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>
If the intel_pixmap was NULL we should have failed to create the DRI2
buffer, so we can safely assert here to keep the analyser quiet.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Chris Wilson
Cyril Brulebois
Dave Airlie
Dave Airlie