[EXA PATCH] prefer intermediate surface for triangle/trapezoid/addtraps when destination is offscreen

[Clemens Eisserer]

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
ping-pong migration.
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?

- Clemens

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
> http://lists.freedesktop.org/mailman/listinfo/xorg
>