[EXA PATCH] prefer intermediate surface for triangle/trapezoid/addtraps when destination is offscreen
linuxhippy at gmail.com
Fri Nov 21 01:58:23 PST 2008
I agree that the patch is probably quite useful if a mask is re-used
on NUMA systems.
A typical use-patter would be: 1. Clear Mask ; 2. Add traps; 3. Composite
As far as I know 1. is done on offscreen, 2. is forced to read back
because of 1. and 3. downloads the contents again.
Things like that caused me a lot of troubles, currently rendering a
single diagonal line with EXA pretty much destroys performance -
althouhg with a temporary mask and an additional composite operation
it could be done without readbacks.
However I don't know whats the situation on UMA systems, which have
direct access to vram as far as I know if the driver supports it.
The problem is pretty much the same for gradients - for now they cause
A simple work-arround is to copy the gradient to a temporary pixmap -
however at the expense of UMA gpus.
Hmm, I wonder wether the driver could tell EXA wether
framebuffer-access is direct, and EXA could decide which way to go?
2008/9/20 Maarten Maathuis <madman2003 at gmail.com>:
> On Sat, Sep 20, 2008 at 11:28 AM, Maarten Maathuis <madman2003 at gmail.com> wrote:
>> On Sat, Sep 20, 2008 at 11:25 AM, Michel Dänzer
>> <michel at tungstengraphics.com> wrote:
>>> On Fri, 2008-09-19 at 22:47 +0200, Maarten Maathuis wrote:
>>>> On Fri, Sep 19, 2008 at 10:41 PM, Maarten Maathuis <madman2003 at gmail.com> wrote:
>>>> > In my experience UploadToScreen is faster than DownloadFromScreen, so
>>>> > it seems prudent to give this software rendered operation a reasonable
>>>> > chance should someone use an existing (offscreen) mask.
>>>> > Let me know what you think.
>>>> > Maarten.
>>>> After posting i noticed a rather big mistake (one of the offsets to
>>>> fbAddTraps was wrong).
>>>> So here is a new version.
>>> Do you have any before/after numbers for this?
>>> Earthling Michel Dänzer | http://tungstengraphics.com
>>> Libre software enthusiast | Debian, X and DRI developer
> That empty message was unintentional.
> This patch was made when i was under the impression that someone was
> hitting this problem. Now i realize it is something else that is
> causing serious issues. I still stand by the patch, because i do
> believe an additional composite operation is far cheaper than falling
> back. That said, i'll try putting together a testcase in the
> forseeable future.
> xorg mailing list
> xorg at lists.freedesktop.org
More information about the xorg