[Mesa-dev] Speed regression(?) in Vega state tracker
olvaffe at gmail.com
Sat Jan 29 03:42:39 PST 2011
On Sat, Jan 22, 2011 at 5:31 PM, Krzysztof Smiechowicz <deadwood at wp.pl> wrote:
> I'm the maintainer of Mesa port for AROS (www.aros.org). I recently
> backported Mesa 7.10 and noticed a considerable speed regression. After some
> testing I narrowed the problem down to commit:
> 859106f196ade77f59f8787b071739901cd1a843, st/vega: Fix pipe blend state for
> various blend modes.
> My test case is lion demo:
> softpipe, debug, without commit: ~7 FPS
> softpipe, debug, with commit: ~0.13 FPS
> nouveau, release, without commit: ~150 FPS
> nouveau, release with commit: ~9FPS
Sorry for the slow response. I was in the recovery from a surgery.
OpenVG blending modes cannot be mapped gallium (GPU) blend functions
directly, because the former expects the souce and destination colors
to be in pre-multiplied alpha (let me know if I am wrong). To blend
correctly, the contents of the color buffer must be copied to a
temporary texture and a fragment shader must be used. This is what
the commit does and where the serious performance hit from.
However, there are several optimization opportunities. Firstly, when
the source or destination color have alpha==1 everywhere, the blending
formula can be simplified: either no blending is required or GPU blend
functions can be used. Since the lion demo uses a solid color paint
with alpha==1, this optimization can eliminate the performance hit
completely. Another change that should be made is in how the color
buffer is copied to the temporary texture. The routine copies the
whole color buffer right now. It should copy only the bounding box of
the path. I will see if I can finish two optimizations by Monday.
> Best regards,
> PS. I'm not filling a bug report, since AROS port is not official and the
> problem still might be down to something wrong with the port itself.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
olv at LunarG.com
More information about the mesa-dev