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 <[EMAIL PROTECTED]>: > On Sat, Sep 20, 2008 at 11:28 AM, Maarten Maathuis <[EMAIL PROTECTED]> wrote: >> On Sat, Sep 20, 2008 at 11:25 AM, Michel Dänzer >> <[EMAIL PROTECTED]> wrote: >>> On Fri, 2008-09-19 at 22:47 +0200, Maarten Maathuis wrote: >>>> On Fri, Sep 19, 2008 at 10:41 PM, Maarten Maathuis <[EMAIL PROTECTED]> >>>> 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg