Re: Better gradient handling (migration/fallbacks)
On Thu, 2008-11-13 at 11:16 -0800, Eric Anholt wrote: > We just need to accelerate gradients, and is where any effort in > software should occur. It's on our schedule, but not for quite a while. > Setting up the X Server to allow drivers to request gradients was easy > last time I did it, though I've misplaced the branch it looks like. > Then someone would just have to write the shader for it, and for > 915-class hardware that shouldn't be hard. One pleasant side effect of shatter is that the acceleration layer should be able to catch rendering from source-only pictures and magically transform them into pixel-backed pictures if it thinks that'll be a win. So even for hardware without the cojones to do gradients, we should be able to do slightly better than pure software. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Better gradient handling (migration/fallbacks)
We tried to use gradients to skin our application, but performance was so bad we soon gave up (on i855GM). Oprofile showed the majority of time was spent in memcpy. It would be great if these problems could be resolved in the upcoming xserver release. Great to hear code has already been written! thx Joel _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Better gradient handling (migration/fallbacks)
Hi, Do you think there is any chance of getting the gradient hooks into 1.6? Would not be too bad if no driver is able to accalerate it for now, but at least users would not need xserver 1.7 to get accalerated gradients. Distributors usually tend to update drivers, but they almost never switch to a new xorg major version. - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Better gradient handling (migration/fallbacks)
> We just need to accelerate gradients, and is where any effort in > software should occur. It's on our schedule, but not for quite a while. > Setting up the X Server to allow drivers to request gradients was easy > last time I did it, though I've misplaced the branch it looks like. > Then someone would just have to write the shader for it, and for > 915-class hardware that shouldn't be hard. Glad to know its on your schedule. Of course accalerated gradients would be even better :) Thanks for your reply, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Better gradient handling (migration/fallbacks)
On Thu, 2008-11-13 at 14:30 +0100, Clemens Eisserer wrote: > Hi, > > I've experienced some performance problems with gradients when working > on the xrender/java2d backend. > > A typical problematic case is when mask and desitation picture were in > VRAM, and a gradient is used as source. > As far as I understand this causes mask and dst to be moved out into > sysmem, the composition is done by pixman and at the next accalerated > operation the whole thing is moved back. > In profiles I saw that about 35% of total cycles where spent in > moveIn/moveOut and 5% in gradient generation itself, for a rather > boring UI like the following: > http://picasaweb.google.com/linuxhippy/LinuxhippySBlog?authkey=tXfo8RSnq4s#5224085419010972994 > > What I did to work arround the problem was to use a temporary pixmap, > copy the gradient to the pixmap and use that pixpap later for > composition. > This means only moveIn's and enhanced performance a lot, about 3-4x > for the UI workload mentioned above. > > This seems to be an acceptable workarround but causes an unnescessary > burden for UMA architectures like Intel+GEM, so doing this be default > should be up to the driver. > Would it be possible to pass gradients down to the driver, to allow > the driver to decide what to do with the gradient, or even provide > accaleration for it. > How complex would it be to provide the nescessary hooks? > As far as I know two-stop gradients often can be accalerated with some > texture-mapping tricks, and everything more complex still could be > done with shaders. > > I am no xorg/exa expert, so maybe I just do not understand things and > draw wrong conclusions. We just need to accelerate gradients, and is where any effort in software should occur. It's on our schedule, but not for quite a while. Setting up the X Server to allow drivers to request gradients was easy last time I did it, though I've misplaced the branch it looks like. Then someone would just have to write the shader for it, and for 915-class hardware that shouldn't be hard. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
