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>
Bump the alloted number of threads to their max. Using more threads than
cores helps hide the stalls due to sampler fetch, math functions and urb
write. Specifying too many threads seems to not incur a performance
regression, suggesting that the hardware scheduler is sane enough not to
overpopulate the EU.
A small but significant boost, peak x11perf -aa10text on an i3-330m is
raised from 1.93Mglyphs/s to 2.35Mglyphs/s.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the front buffer is not attached to the scanout and has not been
reparented, we can simply exchange the underlying bo between the
front/back attachments and inform the compositor of the damage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Implement "tripple-buffering" for windowed SwapBuffers by allowing the
client to submit one extra frame before throttling. That is we emit the
vsync'ed blit and immediately unblock the client so that it renders to
the GPU (which is guaranteed to be executed after the blit so that its
Front/Back buffers are still correct) and requests another SwapBuffers.
The subsequent swapbuffers are appended to the vsync chain with the
blit/unblock then executed on the vblank following the original blit.
That is both the client and xserver render concurrently.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
With the introduction of the third pipe on IvyBridge it is possible to
encounter situations where the combination of the three monitors exceed
the limits of the scanout engine and so prevent them being used at their
native resolutions. (It is conceivable to hit similar issues on earlier
generation, especially gen2/3.) One workaround, this patch, is to extend
the RandR shadow support to break the extended framebuffer into per-crtc
pixmaps.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Following the previous commit, we reset the vbo when it becomes idle
rather than discard it. As such, the assertions to check that we are
discarding the vbo are now bogus.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once we switch to using a vbo, keep it cached (resetting everytime it is
idle) until we expire our caches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Discard the unneeded next parameter to drop a memory reference in a hot
path, and don't wait for a retirement if we are looking in a larger
bucket than suits.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Further testing and the balance of doubt swings in favour of using the
3D pipeline for copies.
For small copies the BLT unit is faster,
2.14M/sec vs 1.71M/sec for comppixwin10
And for large copies the RENDER pipeline is faster,
13000/sec vs 8000/sec for comppixwin500
I think the implication is that we are not efficiently utilising the EU
for small primitives - i.e. something that we might be able to improve.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For whatever reason, this produces a 30% improvement with the fish-demo
(500 -> 660 fps on i7-3730qm at 1024x768). However, it does cause about
a 5% regression in aa10text. We can appear to alleviate that by only
doing the flush when the composite op != PictOpSrc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The original vblank interface only understood 2 pipes (primary and
secondary) and so selecting the third pipe (introduced with IvyBridge)
requires use of the HIGH_CRTC. Using the second pipe where we meant the
third pipe could result in some spurious timings when waiting on the
vblank.
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We use that flag to check whether we need to check whether the bo is
still busy upon destruction, so only clear it if the bo is marked as
idle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the 3D pipeline is quite versatile and we only need to force BLT if
we cannot extract the subregion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The sampler can in fact handler subregions of large pixmaps quite well,
and so we prefer to keep using the 3D pipeline so long as the operation
fits in. If not, then switch to the BLT in order to avoid the temporary
surface dance.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To complete my show of incompetence for the evening, not only do we have
to restore the original source when compositing the mask onto the
destination, we also need to restore the original dst (rather than
composite the mask onto the mask!).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In 64a4bcb8ce, I introduced a WHITE source for the purposes of
accumulating the glyph mask correctly. Unfortunately I neglected to
restore the original source picture for compositing the glyph mask on
the destination, resulting in a use-after-free and then corruption.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may attempt to end up using the GPU bo is the CPU bo is busy, we
need to make sure we have initialised the damage extents first.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Keep the semantic analyser happy by consuming the expected return value
with an assert.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson