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>
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>
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>
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>
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>
gen6+ platform has a BLT engine with seperate
command streamer to support BLT commands.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
[ickle: merge trivial conflict]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After splitting out the i810 driver into its own legacy directory, we
can identify the common routines not as i830 but as intel. This
clarifies the code which *is* i830 specific.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>