This reduces the amount of dancing required to call into the span
functions as we can pass the arguments in both the integer and floating
point registers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sandybdrige requires an elaborate dance to flush caches without
hanging the gpu. See public docs Vol2Part1 1.7.4.1 PIPE_CONTROL
or the corrensponding code in mesa/kernel.
This (together with the corresponding patch for the kernel) seems to
fix the hangs in cairo-perf-traces I'm seeing on my snb machine.
v2: Incorporate review from Chris Wilson. For paranoia keep all three
PIPE_CONTROL cmds in the same batchbuffer to avoid upsetting the gpu.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We attempt to skip upload a source pixmap to the GPU in the event it is
used only once (for example during image upload by firefox). However, if
we continue to use the CPU source pixmap then it obviously was worth
uploading to the GPU. So if we use the CPU pixmap a second time, do the
upload and then blit.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Using spans has a tremendous effect (~100x) on x11perf, some good but
mostly bad. However, in reality operations are mixed and so preventing
migration on alternate opertaions is a win. In the x11perf slowdowns, it
appears to be CPU bound and so it seems like there should be plenty of
scope for recovering the lost performance.
However, for the time being, just go back to the old fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Previously we ignored updating the scanout in place, and so we were not
amoritizing the shadow cost of common core rendering operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the span code does not yet handle plane masks or stippling, it is
disadvantageous to convert to spans only to fallback.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is actually tricker than it looks since miPolyArc() sometimes uses
an intermediate bitmap which performs worse than the fbPolyArc() fallback.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the beginning, I did perform a retire after ever batch. Then I
decided that it was too much CPU overhead for too little gain. On
reflection, i.e. further benchmarking, we do see a performance
improvement for recycling active buffers faster.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The actual bug is a little involved as we don't damage the temporary
glyph mask correctly presuming that we only hit GPU paths. However,
should we fail to prepare the composite operation that paints the mask
on to the destination, things fail horribly.
One particular example is that wine like to create its own temporary a1
buffer for the glyphs (which we render to via another temporary mask...)
which triggers the delayed fallback and then sw compositing with a random
buffer.
Reported-by: Roman Jarosz <kedgedev@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41165
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I mistakenly set GEN7_PS_MAX_THREAD_SHIFT to 23; it's actually 24 on
Ivybridge. Not only did this halve our thread count, it caused us to
write 1 into a bit 23, which is marked as MBZ (must be zero).
Furthermore, it made us write an even number into this field, which is
apparently not allowed. Apparently we were just lucky it worked.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Would be preferrable to duplicate the tiling logic. Leave the task of
reimplementing XAA to another day!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Daniel Vetter
Kenneth Graunke