Otherwise we'd fail saying DRI1 wasn't possible, when that
is exactly what we asked for.
[ickle: The breakage was introduced with
commit bd6ffd1ad2 [2.21.14]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Jul 27 15:33:19 2013 +0100
configure: Print a summary of compilation options
which modified the search to only take place if UMS was enabled, but
missed mollifying the resulting error.]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Using __packed__ as shorthand for ___attribute__(__packed__) confuses
clang as. (I guess to it expands (__packed__) which gcc skips.) As
clang also uses packed in its builtins, we have to find a compromise,
and so tightly_packed wins for being a more verbose description without
the dangerous leading underscores.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst we reserved exec entry slots for the deferred VBO, there were no
relocation spaces reserved. So if we submitted a render command followed
by a multitude of BLT copies, we could then overrun the relocation array
when adding the deferred vbo to the batch.
Reported-by: Danny <moondrake@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67504
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ideally, the method of swapping is something that the applications have
control over, along with how to synchronise to the vertical refresh.
Whilst triple buffering is good to reduce jitter for games (at the cost of
an extra frame of latency, usually considered a good tradeoff), it
prevents the applications from accurately controlling the presentation
of animations. One vocal critique is Owen Taylor, who demands accurate
swap control for smooth animations in gnome-shell. For example,
http://blog.fishsoup.net/2012/11/28/avoiding-jitter-in-composited-frame-display/
In lieu of application control, just apply a quirk for the compositor.
Everyone else will just have to wait for DRI3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we need optimal copy code for the general case, where unlike
swizzling the run lengths are not known before hand, we need to call the
arch specific routines from glibc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
xf86InterpretEDID() doesn't copy the EDID raw data in xf86MonPtr but
just stores the given pointer. The DDX driver needs to make sure that
data stays valid.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
If we allocate the scanout from stolen, we cannot then access it via the
CPU - so prevent the mapping in those cases.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On Iris, we may store the framebuffer in the eLLC/LLC and mark it as
being Write-Through cached. This means that we can treat it as being
cached for read accesses (either by the GPU or CPU), but must be careful
to still not write directly to the scanout with the CPU (only the GPU
writes are cached and coherent with the display).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
GT3 has twice the number of cores and URB as GT2, and so we can use
more threads and URB entries.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst we are force flushing vertexes we are not using the threaded
emitter, so simply hide it from the compiler to prevent it warning about
the unused function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
All the curent reports by gcc are false positives. Instead we have better
static analysis tools at our disposal and valgrind.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Warning about redundant declarations within the xorg headers hides
genuine warnings in our own code - disable them until the headers are
cleaned up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the DRI buffer is stale, the drawable may have been recreated and no
longer be associated with DRI. In this case, the pixmap may not be on
the GPU, so just subsitute the client's old bo and hope the it catches
up and does a GetBuffers in the near future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So do not offset it again when processing the fallback composite
operation.
Regression from commit 6921abd810
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jul 18 16:21:27 2013 +0100
sna: Add a fast path for the most common fallback for CPU-CPU blits
References: https://bugs.freedesktop.org/show_bug.cgi?id=66990
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a first step towards working out what to do with the remaining
used-once PCI IDs, delete the used-never ones.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Typically, PutImage is not a performance critical path since ShmPutImage
uses CopyArea and so PutImage is relegated to small one off transfers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The codename changed midcycle - along more rational lines (all the chips
within the platform are now part of the Baytrail family rather than
different codenames for each).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the macros conflict with another definition on the system, that is
actually a useful warning in this case as it means there exists a typo
somewhere.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When printing out the list of supported chipsets, remove the (many
times) repeated names as they are very confusing and obscure the product
name you may be searching for.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For these parts we do not yet known the correct marketing name, so
replace our use of the codename with the generic term.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we recognise the PCI-ID but do not have a marketing name for it, it
means we are deliberating ignoring it - presumably because it is an
engineering sample. In this case, we do not want to print out a warning
into the logfile so replace the "Unknown chipset" with some info
about the future product.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Dave Airlie
Damien Lespiau
Egbert Eich