Even if page-flipping itself is disabled, we still want to allow the
client to schedule wakeups for some future vblank which requires
listening to the kernel vblank notifications.
Reported-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51699
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As an alternative to vmap, we can use the kernel for all memory
management through bo, which is much preferred for its simplicity (i.e.
avoiding introducing even more vm complexity).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now treat CPU all-damaged as a special case for deciding when and
where to migrate, look out for that condition after adding damage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Be consistent and avoid the confusion when mixing operations on the
region boxes and the original boxes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just to avoid the warnings after fallback to comparing the d_name to
the list of known interfaces.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Again, to avoid the forced ping-pong as we upload the damage after
nearly every operation, simply prefer to use the GPU in such cases.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A nasty habit of applications is to fill an area, only to read it back
with GetImage, render locally and replace with PutImage. This causes a
readback of an active bo everytime, so let's try to mitigate that by
preferring not to use the GPU after a forced readback.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Micro-optimisation to overhead extra checks and to make sure an
unflushed bo doesn't prevent us from submitting more work before
sleeping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As this is a pure write operation (though we will write the edge pixels
twice) we can perform this operation inplace and incur a slightly slower
trap creation at the benefit of avoiding the later copy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The overhead of reading the hpet() on every block handler (more or less)
is exorbitant, so trust that we update currentTime frequently enough to
be a good approximation - the side effect is that we will wakeup
slightly to earlier from using an old value for the current time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the kernel is inconsistent in enforcing this across generations,
handle the synchronisation of the pageflip explicity. Ultimately this
should be replaced with a tripple buffer mechanism.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The damage boxes are in framebuffer (source) space, so we need to apply
the offset for the boxes in crtc (destination) space.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On gen4+, the scanout offset into a tiled surface is specified through
the DSPTILEOFF register and limited to 12bits of precision. So if we
have a CRTC positioned in that nether-region, we need to allocate a
separate per-crtc pixmap for it and perform shadowing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if we are obviously turning the crtc off, it still complains if the
number of connectors is non-zero. So make it so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Regression from 1e9319d (sna: extend RandR to support super sized
monitor configurations) which tried to take into account the need to
flush the shadow CRTC bo in addition to the normal scanout bo. In the
refactoring of the need_flush(), the double negative was missed.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The unwanted ';' caused is_cpu() to always return false if a GPU bo was
attached. Not necessary a bad thing, just misses the potential
optimisation where having chosen to prefer to use the CPU path we then
have to migrate to the GPU even though the bo is undamaged or idle.
Spotted-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The server manages FakeFront following a flip, but it the client
optimises a swap by replacing it with a CopyRegion, it is expected to
also update the FakeFront itself. Replicate that behaviour so that the
timings for the test case are consistent with mesa.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oh my, I just once again rediscovered the copy on every flip due to the
requirement for keeping FakeFront uptodate for reads after a SwapBuffers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Similarly to UXA, this papers over inconsistent behaviour in the kernel
in handling the DPMS upon a modeswitch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This were there as a debugging aide to see if we ever hit unreachable
code paths - mainly along corruption inducing GPU wedged recovery paths.
They are superfluous and just scare the reader.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Tom Hughes