This can happen naturally for 3-pipe config on Ivybridge or if the
outputs are rearranged whilst we slept. Instead of failing to change the
display on the VT, install at least a fb on the CompatOutput so that
hopefully the DE can take over, or give some control to the user.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oops, I thought the 'busy' bit was now used and apparently forgot it is
used to control the periodic flushing...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we submit a batch early (for example if the GPU is idle), then submit
whatever else the client drew immediately upon completion of its
blockhandler. This is required to prevent flashing due to visible delay
between the clear at the start of the cycle and then the overdraw later.
References: https://bugs.freedesktop.org/show_bug.cgi?id=51718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The aim is to improve GPU concurrency by keeping it busy. The possible
complication is that we incur more overhead due to small batches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Previously, before every operation we would look to see if the GPU was
idle and we were running under a DRI compositor. If the GPU was idle, we
would flush the batch in the hope that we reduce the cost of the context
switch and copy from the compositor (by completing the work earlier).
However, we would complete the work far too earlier and as a result
would need to flush the batch before every single operation resulting in
extra overhead and reduced performance. For example, the gtkperf
circles benchmark under gnome-shell/compiz would be 2x slower on
Ivybridge.
Reported-by: Michael Larabel <michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
E.g. that BLT can always write to cacheable memory, inflexible fences
are a thing of the past, etc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This may not be totally safe, but it is a nicer explanation for random
single character corruption.
References: https://bugs.freedesktop.org/show_bug.cgi?id=51422
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In case we need to continue on with the render operation, we need to
preserve the existing state.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=57601
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Slight modification to the proposed API to only pass the simplified
domain tracking now performed by the kernel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The changes tested on g45/gm45 prove to be highly unstable on 965gm,
suggesting a radical difference in the nature of the bugs between the
two generations. In theory, g4x has additional features that could be
exploited over and above gen4 which may prove interesting in the future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson