As we know the maximum length of the string, we can replace our single
usage of XNFprintf with snprintf.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I failed my reading comprehension and didn't spot that the help strings
pointed to two separate downstream packages.
Thanks to Carl Worth for pointing out my mistake.
This reverts commit ebb7aca667.
[Modified version of U. Artie Eoff's commit to remove the duplicated
string. The paraphrased commit message is repeated below for clarity.]
xorg-macros is often package under an unusual name, so provide some
clues as to what name to try on the user's distribution. Installing
build-deps would be just too easy...
Also include a check for the existence of the XORG_DRIVER_CHECK_EXT
macro, otherwise configure might continue in spite of the missing macro
and cause obtuse syntax errors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Added m4 check for XORG_DRIVER_CHECK_EXT macro definition. Updated m4 fatal messages to give better hint on how to resolve error when xorg macros are missing. Previously, configure would continue in spite of the missing macros and the build would fail for syntax errors.
Implements a consistency check on returned vblank
count values of pageflip completion. Impossible
values are detected, a x-warning is logged and
returned (msc,ust) values are marked invalid,
so clients could perform error handling. Such
a warning would indicate bugs in the pageflip
completion routine of future kms drivers or the
ddx and thereby aid driver debugging.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When a drawable is page-flipped on multiple crtc's (fullscreen
drawable on mirror-mode or multi-head x-screen), only one pageflip
event is finally delivered, after the last participating crtc signals
flip completion, this to avoid visual corruption.
Old code returned vblank count and timestamps of flip completion
of this last crtc, instead of the values of the "master crtc", the
one that was used for initially scheduling/triggering the pagflip
via vblank events. (master = I830DRI2DrawablePipe(drawable))
This patch makes sure that the pageflip completion values of the
"master" crtc are returned, otherwise client applications will
get confused by the random (msc, ust) values returned by whichever
crtc was the last to complete its flip. Without this, the returned
values change randomly and jump forward and backward in time and
count.
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 03e8351179.
* sigh.
This was only meant to be a temporary debugging hack, not for public
consumption (or embarrassment).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This should prevent any lag when waiting upon user input, for example
whilst logging in with gdm.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Something is wrong, we should be tracking when to invalidate the caches
as appropriate, yet I can not finding the missing flush to replace the
implicit one of DRAW_RECTANGLE.
Fixes cacomposite.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is known to lock up the GPU even with the workaround in place.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31773
Signed-off-by: Matthias Hopf <mhopf@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As a corollary to filling one vertex array and beginning a new one is
remembering to emit the old one before overwriting...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There was a reason why we need to check at the start of every composite
operation to see if we have enough space in the array to fit the
vertices, which I promptly forgot when moving the code around to make
it look pretty.
* sigh.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This pair of chipsets seem broken beyond repair, specifically the
erratum that causes the wrong PTE entry to be invalidated, so disable
our incorrect attempts to use the BLT on those devices.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel always turns monitors on when doing mode setting, and so no
further DPMS action is required. Note this in the mode setting code by
marking the updated DPMS mode and restoring any saved backlight level.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Allow fenced allocations even for small pixmaps if the kernel supports
relaxing fencing (where only the used pages are allocated).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the kernel controls the relocation of state buffers, we should not
hard code the maximum permissible value for them.
Fixes an eventual hang with full-gtt.
Reported-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A perennial problem we have is the accursed WAIT_FOR_EVENT hangs, which
occur when we switch the framebuffer before the WAIT_FOR_EVENT completes
and upsets the GPU.
We have tried more subtle approaches to detected these and fix them up in
the kernel, to no avail. What we need to do is to delay the framebuffer
flip until the WAIT completes, which is quite tricky in the kernel
without new ioctls and round-trips. Instead, apply the big hammer from
userspace and synchronise all rendering before changing the framebuffer.
I expect this not to cause noticeable latency on switching modes (far
less than the actual modeswitch) and should stop these hangs once and
for all.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31401 (...)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We emitted this message as an error even though we fallback and attempt
to allocate a non-tiled framebuffer before failing (with an appropriate
error message).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we attempt to emit BLT batches without kernel support, we just end up
with EINVAL and no rendering. Prevent this, and avoid uncached
rendering, by restoring the shadow fallback paths if there is no BLT
support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a holdover from early GEM work when we weren't syncing on the
DRI client side. It would keep clients from getting too far ahead and
killing their interactivity, by bringing everyone to a halt when
anyone was too far ahead.
Now, GL clients throttle themselves to avoid the problem, and it turns
out that in the case that they don't (long rendering to buffers with
no swap), this actually reduces X Server interactivity: instead of
lagging of X rendering behind input, you get no response for seconds
at a time, then a burst of rendering, then nothing again.
Reported by ajax. Tested with moving a window while running
cairo-perf-trace on the GL backend (improvement) and X backend (no
significant change in responsiveness).
It is weird that some rendercheck cases only work fine with headerless write.
Need to update intel-gen4asm to support headerless write
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Chris Wilson
U. Artie Eoff
Mario Kleiner
Matthias Hopf
Keith Packard
Carl Worth
Eric Anholt
Xiang, Haihao