As we have to upload the dirty data anyway, setting the
alpha-channel to 0xff should be free. Not so for firefox-asteroids on
Atom at least.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are forced to perform a render operation to a bo too large to fit
in the pipeline, copy to an intermediate and split the operation into
tiles rather than fallback.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we do not fill the whole upload buffer, we may be able to reuse a
smaller buffer that is currently bound in the GTT. Ideally, this will
keep our RSS trim.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If, for instance, we reduce the GPU damage to all we know that there can
be no CPU damage even though it may still have a region with a list of
subtractions. Take advantage of this knowledge and cheaply discard that
damage without having to evaluate it.
This should prevent a paranoid assertion that there is no cpu damage
when discarding the CPU bo for an active pixmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The function was semantically equivalent to moving the pixmap to the CPU
for writing, so replace it with a call to the generic function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we can create snoopable bo, we prefer to use those as creating a vmap
forces a new bo creation increasing GTT pressure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we try to use the diffuse/specular and only resort to using a texture
operation for convenience in the rare case of a solid mask.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the new mode can be done either using a logic op or with the blend
unit, prefer the currently enabled unit.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we asked to use the BLT, try to avoid trigging a context switch for
a trivial case where we sample outside of a NONE source and so can
reduce the operation to a clear.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Convert the linear gradient to a texture ramp and compute the texture
coordinates in the standard manner.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For correctness we need to inform GEM of the change of domain for the
buffer so that it knows to invalidate any caches when it is next used by
the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This helps SNB on cairo-traces that utilize lots of temporary uploads
(rasterised sources and masks for instance), but comes at a cost of
regressing others...
In order to counter the regression from increasing the GTT cache size,
the CPU/GTT vma cache are split and accounted separately.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After reducing the used size in the partial buffer, we need to resort
the list to maintain the list in decreasing amount of available space.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow SandyBridge to specialise its clear routine to reduce the number
of ring switches. It may be interesting to specialise the clear routines
even further and use the special render clear commands...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Optimistically we would replace the GPU damage with the new set of
trapezoids. However, if any partial damage remains then the next
operation which is often to composite another layer of trapezoids (for
complex clipmasks) using IN will then stall.
This fixes a regression in firefox-fishbowl (and lesser regressions
throughout the cairo-traces).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The first, and likely only, goal is to support SHMPixmap efficiently
(and without compromising SHMImage!) which we want to preserve as vmaps
and never create a GPU bo. For all other use cases, we will want to
create snoopable CPU bo ala the LLC buffers on SandyBridge.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We trade-off the extra copy in the hope that as we haven't used the GPU
bo before then, we won't need it again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One restriction common to all generations is that samplers access pairs
of rows and so we need to pad the buffer to accommodate access to that
second row. Do so unconditionally along paths that may be used by the
render pipeline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Similar to the action taken into move-to-gpu so that we forgo the
overhead of damage tracking when the initial act of creation is on the
render paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By inlining the swizzling of the alpha-channel we can support BLT copies
from an alpha-less pixmap to an alpha-destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Strange as it may seem... But the principle of doing less work with
greater locality should help everywhere, just not as noticeable when
real work is performed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When the bo is already completely damaged on the CPU, all we need to do
is to sync with the CPU bo.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we spot that the region is wholly contained within the CPU damage
initially, we can conclude that is not in the GPU damage without
reduction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Check if the source and mask are identical pictures and just copy the
source channel to the mask in that case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For the common case (at least with llc bo) where we are immediately
using an uploaded image from its linear buffer, check upfront before
computing the sampled region for transfer to the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For the common case of glyphs, the pixmap is entirely on the GPU which
can be quickly tested before performing the more complex transformations
to determine how much pixel data we need to upload.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Without xserver support for notification of when scratch pixmaps are
reused, we simply cannot attach our privates to them lest we cause
corruption with SHM pixmaps.
This is a recent regression back unto an old, old xserver issue.
Reported-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44503
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson