Currently, we require that a batch containing a dirty bo be submitted
before we mark the device as requiring a flush. So if we never submit a
batch between block handlers, we can end up sleeping without ever
flushing either the partial batch or the rendering to the scanout.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36776
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Still need to handle video and gamma correction, but this gets the
display up and running at 30 bit depth if the kernel and display support
it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
As fullscreen swaps were going via a different path to the swapping of
ordinary windows, we were no longer honouring the xorg.conf option to
disable swapbuffer waiting.
This changes the code to only use pageflipping if the Option
"SwapbuffersWait" is set to "TRUE" (default).
Jesse's comment was that this should be superseded by actually
supporting asynchronous page flips. As we are missing kernel and dix level
support for that, in the meantime honour the config option.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Kristian Høgsberg <krh@bitplanet.net>
(Actually around 131, with additional 10% just for safety.)
Reported-by: Modestas Vainius <geromanas@mailas.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36319
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There are still too many unresolved bugs, typically GPU hangs, that are
related to using relaxed fencing (i.e. only allocating the minimal
amount of memory required for a buffer) on older hardware, so turn off
the feature by default for the release.
Reported-and-tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36147
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter pointed out that the automagic flush by the kernel for the
busy-ioctl was only introduced upstream in 2.6.37. So we still need to
manually emit a flush on old kernels.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit d2106384be.
Breaks compiz (but not mutter/gnome-shell) on gen6. Not sure if this is
not seem deep interaction issue with multiple clients sharing the GPU or
just with compiz, but for now we have to revert and suffer the inane
performance hit. It looks suspiciously like another deferred damage
issue...
Bugzilla: 51a27e88b073cff229fff4362cb6ac22835c4044
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than just creating and submitting a batch that simply contains a
flush in order to periodically ensure that rendering reaches the
scanout, we can simply ask the kernel whether the scanout is busy. The
kernel will then submit a flush on our behalf if it is dirty, which
takes advantage of the kernel's dirty state tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel will emit any required flushes between the dri client and the
ddx, and we do not rely on the MI_FLUSH here for scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce the number of relocations emitted by only emitting one relocation
per vertex element per vertex buffer.
References: https://bugs.freedesktop.org/show_bug.cgi?id=35733
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We have seen GPU hangs with:
batchbuffer at 0x0f9b4000:
0x0f9b4000: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b4004: 0x00000300: dword 1
0x0f9b4008: 0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0f9b400c: 0x00000300: dword 1
0x0f9b4010: 0x01820000: MI_WAIT_FOR_EVENT
0x0f9b4014: HEAD 0x02000006: MI_FLUSH
on a 1366x768 display. That according to the specs an invalid command
for the pipe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35576
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If adding either the frame or client resources fails, we need to clean
up afterwards properly.
First, add_frame_event needs to internally clean up after itself by
undoing any partial execution. Second, the callers need to look at the
return value and free the swap/flip info structure when necessary.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
A modest boost to throughput and reduction in CPU overhead from
not flushing the batch on every transition from BLT to RENDER.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the frame_event is about to be freed, there's no point in cleaning
up references to the drawable and client.
Signed-off-by: Keith Packard <keithp@keithp.com>
A pending swap or flip holds references to drawables and clients which
become invalid when destroyed. Add suitable resources to the database
to track those lifetimes and clean up the pending data structure then.
Later, when the pending swap or flip occurs, handle a missing drawable
by just discarding the flip or swap. Handle a missing client by not
sending an event or reply.
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of using void * for all of the flip_info and swap_info
pointers, just make the underlying structure a public data type and
use that.
Signed-off-by: Keith Packard <keithp@keithp.com>
In the case of a singular clip box and rendering onto the front buffer
larger than 2048, the clip extents were being ignored. Here we can
simply reduce the size of the indirect pixmap to the clip extents.
Reported-by: Michael Chang <mchang@novell.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35346
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Keith Packard pointed out a loophole that could cause the DDX to end up
with a tiled scanout even if the user required a linear framebuffer;
that is by using page-flipping we could replace the scanout pixmap with
another of our choosing, and not necessarily tiled.
Close that loophole by only allowing an exchange of buffers between
identical tiling modes. For the common case, this is fine since they
will indeed be allocated with the same tiling. For the linear
framebuffer case with mesa using a tiled pixmap, we force it to blit
onto the scanout instead.
Reported-by: Keith Packard <keith.packard@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that you can indeed allocate a linear framebuffer if you so desire
without breaking mesa.
Adds:
Section "Driver"
Option "LinearFramebuffer" "False|True" # default false
EndSection
to xorg.conf
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I have no clue as to how such an alien drawable reached us, but we have
the evidence of a segfault to say it can happen.
Reported-by: Bernie Innocenti <bernie@codewiz.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34787
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Certain error situations can result in the following printed to
Xorg.0.log at a high enough rate to make log file size a problem.
(WW) intel(0): I830DRI2GetMSC:1062 get vblank counter failed: Invalid argument
(WW) intel(0): I830DRI2ScheduleWaitMSC:1118 get vblank counter failed: Invalid argument
Following in the tradition of commit 0ad6d6e1, limit the warnings to be
output 5 times, then quell the remainder.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34322
Ref.: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/710594
Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since, with GPU-on-package, it's hard to talk about a model number for
a specific chipset like 855GM, just use the platform names.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the render operation requires a temporary source Picture and the
operation is large, larger than the maximum permitted bo, then we will
fail to allocate the bo. In this case, we need to fallback and perform
the operation on the CPU rather than dereference a NULL bo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34399
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
WRONG.
The hardware was never limited to 0x1000000 and the kernel can quite
rightly place objects above that limit. Specifying such had no relation
to reality, so why did we do it? TWICE!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34017
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
uxa_acquire_solid returns NULL under OOM. Thus the value of solid
must be checked before dereferencing it in the uxa_get_offscreen()
call.
Signed-off-by: Bryce Harrington <bryce@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The region is used to paint onto the backing pixmap (and thus
translated) prior to being passed to the damage layer (wrt to the
drawable). So the local translation needs to be undone first.
Identified by Christopher James Halse Rogers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33650
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Paul Menzel
Jesse Barnes
Daniel Vetter
Keith Packard
Bryce Harrington
Adam Jackson
Javier Jardón