Yes, writing 3 channels is slower than writing 4. But it's okay we
simply ignore the alpha value anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Although the original precison need only 16-bits to store the offsets,
after projecting on to the sample grid we need a few more bits of
precision and so need a larger integer type to avoid overflow and render
glitches.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42680
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The principle behind the opertator reduction of WHITE * maskca is valid,
except that we failed to account for the src/mask transposition when
emitting the vertices - garbage ensued.
Given that we agressively reduce the shader required for WHITE * maskca,
it does not seem worthwhile to special case the primitive emitter as
well.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42676
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to process the union of the PolyLine command if lineWidth!=0 so
we cannot generally feed lineWidth==1 into our special case handler.
Proving the lines do not intersect is as difficult as finding the
intersections and thereby finding the union of the path - so there is no
advantage in adding a check whether a wide line could be special cased.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes misrendering of the wine tabs
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42606
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we end up always doing expensive readbacks where we would
obviously prefer it if we simply used cached memory for the CPU
operation and then upload.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is no point even attempting a BLT operation if we know that it is
an unusual render operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After removing the memset(0), a couple of fields where left
uninitialised, causing potential rendering glitches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This helps to reduce the perceived jerkiness of the redraw.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42413
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal is to remove a spurious wakeup when we have no work outstanding
afterwards and so would end up prematurely disabling the timer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even if it means incurring a context switch, the BLT unit is
significantly faster so long as we do enough fills. And there is the
catch ;-)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are rendering to or from a ShmPixmap, we need to be sure that the
operation is complete prior to sending an XSync response to client in
order to preserve mixed rendering coherency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If an operation overflows from one batch into another, we submit the
complete batch and begin a new. That new batch will not be submitted
unless it is filled or on the next delayed flush update. This can cause
a flicker as a large operation is broken up, such as performing a
CopyArea through a Clipmask. So if we submit a full batch during a flush
interval, immediately flush any partial batch at the next blockhandler.
This stops rude Santa flashing Rudolf in xsnow!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Otherwise we may leave one behind...
A regression from the introduction of sna_poly_rectangles:
40af32a0e9 (sna: Execute blits directly
for PolyRectangle)
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42568
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the pixmap were to be used multiple times within a batch with
mulitple formats, the cache would only return the initial location with
the incorrect format and so cause rendering glitches. For instance, GTK+
uses the same pixmap as an xrgb source and as an argb mask in order to
premultiply and composite in a single pass. Rather than introduce an
overly complication caching (handle, format) mechanism, kiss and remove
the invalid implementation.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40926
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson