As demonstrated by the all-important trap300, using the BLT is 2x faster
than the RENDER ring for the simple case of solid fills. (Though note
that performing the relocations costs 3x as much CPU for 2x GPU
performance.) One case that may regress from this change is copywinpix
which should benefit from the batching in the RENDER commands, and might
warrant revisiting in the future (with realistic and synthetic
benchmarks in hand!)
However, due to the forced stall when switching rings, we still want to
perform RENDER copies on behalf of DRI clients and before page-flips.
Checking against cairo-perf-trace indicated no major impact -- I had
worried that setting the BLT flag for some clears might have had a
knock-on effect causing too many operations that could be pipelined on
the RENDER ring to be sent to the BLT ring instead.
Reported-by: Michael Larabel <Michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If either of the edges are degenerate on the sample grid, then the trap
has zero height and must be skipped. (Otherwise if just one edge becomes
degenerate than the polygon becomes unbalanced and the rasteriser will
implode.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Oops, a silly cut'n'paste from caused us to allocate an A1 pixmap for
mono traps instead of the A8 pixmap that we tried to write to; mayhem
ensued.
Reported-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to retain the GTT space without keeping hold of the memory used
for the upload buffer, we have to create a new bo and copy the relevant
details across.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
They do not appear to have been leaked per-se, but we end up
accumulating the unused buffers. A more complicated solution would be to
reallocate the handle for retained buffers so that the GTT region can be
reused.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39184
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Similar to the previous commit, check that the Screen Pixmap is bound to
a bo before proceeding.
[Note that in this case, the absence of the bo would have been picked
up much later after doing all of the setup...]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Take of the advantage of the faster mask computation available using the
imprecise tor scan converter for chipsets non yet supporting spans.
In doing so, limit the ability to full step only for vertical only rows
as the small sample grid reduces the benefits of the computationally
more expensive full-step.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Note this also revealed a subtle bug in the handling of degenerate
trapezoids after shrinking to the raster grid.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The single pixel case is usually assocated with synchronisation of perf
clients and so we do not want to incur extra complication along that
path. Also the cost of tracking a single pixel of non-damage outweighs
its benefit.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Or in the case where a second command is received prior to the batch
being flushed, the vertex data is not flushed and leads to the a
miscompution of the number of vertices emitted.
Reported-by: Elias Probst <mail@eliasprobst.eu>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40332
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Under certain circumstances the shadow can be destroy after being
allocated but before being created. The pixmap is a NULL pointer at that
time, but we know that its value should be data, so just use the data
pointer instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we use the stale value when rendering CA glyphs directly to
the front-buffer and subsequent rendering have a tendency to become
invisible. (Rendering via a temporary glyph mask has a fortunate
side-effect of reseting sufficient state to force the re-emission of the
blend state.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When clipping the sample region to the edge of the texture we can also
allow the GPU to use CLAMP_TO_EDGE (as well as CLAMP_TO_BORDER) to
emulate the RepeatPad mode of the parent texture. (Only the
RepeatNormal, RepeatReflect need special treatment with regard to tiling
that is not yet handled.)
This fixes the recent performance regression due to a slight change in
the fish benchmark that caused it to sample outside of the texture atlas
for one of its little fish.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Return early from adding new damage regions if we know that we have
already marked it as all-damaged.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In reality, Mesa will be treating it as W-tiling, only we have no way of
communicating that requirement to the kernel (as not only does the
kernel not understand W-tiling, but also the GTT is incapable of fencing
a W-tiled region.).
Ported from Chad Versace's 3e55f3e88.
Signed-off-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>
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>
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>
Chris Wilson