These are exactly the same as the ones for Sandybridge, but with message
registers translated (hopefully) in the same way as Haihao's new
programs (m1 == g65).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Hanging the machine does indeed prevent video tearing. Just not quite
what the user expected...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39497
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Until now, the stencil buffer was allocated as a Y tiled buffer, because
in several locations the PRM states that it is. However, it is actually
W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section
4.5.2.1 W-Major Format:
W-Major Tile Format is used for separate stencil.
The GTT is incapable of W fencing, so we allocate the stencil buffer with
I915_TILING_NONE and decode the tile's layout in software.
This commit mutually depends on the mesa commit:
intel: Fix stencil buffer to be W tiled
Author: Chad Versace <chad@chad-versace.us>
Date: Mon Jul 18 00:37:45 2011 -0700
Signed-off-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Ian Romanick <ian.romanick@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
This is causing a hard hang with 2.6.39+, we don't know why so play safe
and disable for the time being.
References: https://bugs.freedesktop.org/show_bug.cgi?id=38012
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These are very common when compositing unclipped trapezoids, and the
majority of the overhead is in handling the arbitrary number of boxes
and misses out on the constant folding the compiler can do if it is
known we have just one box.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the glyph is too big to fit into the cache, than ideally we do want
to keep an associated GPU bo around for future use. As it is too large
to fit into the cache, it of reasonable size and there is little wastage
in allocating indiviual GPU bo for each oversized glyph.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we now attempt to always decouple the lists upon freeing the frame
event, we need to initialise them along all code paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By popular demand.
Triple-buffering trade-offs output latency versus jitter. By having a
pre-rendered frame ready to swap in following a pageflip, we avoid the
scenario where the latency between receiving the flip complete signal
from the kernel, waking up the vsynced application, it render the new
frame and then for the server to process the swap request is greater
than the frame interval, causing us to miss the vblank. The result is
that application can become frame-locked to 30fps. Instead, we report to
the application that the first frame swap is immediately completed,
supply a new back buffer (or else the rendering would be blocked on
waiting for the front-buffer to be swapped away from the scanout) and
let them proceed to render the second frame. The second frame is added
to the swap queue, and the client throttled to vrefresh. (If the client
missed the vblank, the swap queue is empty and the client is immediately
woken again, whilst the pageflip is pending.)
Note, for practical reasons this only applies to page-flipping, for
example, calls to glXSwapBuffer() on fullscreen applications.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The Resource database is only designed to store a single value for a
particular type associated with an XID. Due to the asynchronous nature
of the vblank/flip requests, we would often associate multiple frame
events with a particular drawable/client. Upon freeing the resource, we
would not necessarily decouple the right value, leaving a stale pointer
behind. Later when the client disappeared, we would write through that
stale pointer upsetting valgrind and causing memory corruption. MDK.
Instead, we need to implement an extra layer for tracking multiple
frames within a single Resource.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37700
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the width/height in the rectangle is specified as uint16_t, the
result may be larger than is storagable in the int16_t of the box. Of
course it would take a really inane client to do attempt to draw
something much larger than the largest possible surface... Is it strange
that first example I've found to do so is a Java application?
Reported-by: Nicolas Kalkhof <nkalkhof@web.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A little carelessness with passing down the offsets caused us to
incorrectly copy depth=1 bitmaps, as exemplified by gkrellm.
Reported-by: Nicolas Kalkhof <nkalkhof@web.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
My theory that we used nothing that invoked polygon stippling proved
baseless.
Fixes regression from 3b5971bd23
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One cleanup too far causing spurious results after rebooting. We also
need to ensure that the writemask is fully enabled (ie not disabled)
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Trade off extra frames of latency for extra frames of anti-jitter
buffering and loss of completion information; compiz users rejoice.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were underestimating the height of X-tiled surfaces (and less
harmfully overestimating the height of Y-tiled surfaces.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst searching for available space on the active partial buffer list,
if we discover an unreferenced one, reset its used counter to zero.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we allocate a partial buffer and then fallback for the operation, the
buffer would remain on the partial list waiting for another user.
Discard any unused partials at the next batch submission or expiration
point.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One deletion too many, unnoticed until the next reboot. Besides the
failure to disable logic op and enable colour buffer blending which
causes a hang if you subsequently try to enable both, you also need
to request texture caching...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(Note this only applies to 2D pixmaps.)
The rationale, borne out by experimentation with cairo-perf-trace, is
that on the pre-G33 devices we always need a fence region region
for tiled surfaces, i.e. at least .5/1MiB in size, and that combined
with the smaller GTT on those devices, we loose the benefit of tiling to
the excessive GTT thrashing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This was trying to workaround a kernel bug, and instead causes a
performance cliff for textures that *need* to be tiled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the surface is so big that the 2x2 texel sampling will cause a TLB
miss everytime, i.e. the row pitch exceeeds 4096, then we need to
encourage tiling to prevent attrocious performance.
For example, try downscaling a 2560x1600 background image on a gen3
device using I915_TILING_NONE...
Using slideshow-demo /usr/share/backgrounds/cosmos/whirlpool.jpg, on a
PineView netbook, fps goes from under 4 to over 40.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We don't need to warn the user that their hardware does not support the
video overlay plane (but Jesse is working on it!), but merely inform
them that its presence is lacking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is quite trivial to hit given the 2k limits on gen2/gen3. We
compromise on image quality by pre-downscaling the source by a fixed
factor to make it fit into the pipeline in preference to performing the
entire operation on the CPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Kenneth Graunke
Chris Wilson
Chad Versace