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>
Chris Wilson
Zou Nan hai
Xiang, Haihao