On Wed, 27 Aug 2003 10:24:40 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(B> > please please please PLEASE! accelerate everythig you can :)
(B> >
(B> > http://www.rasterman.com/files/render_bench.tar.gz
(B> > http://www.rasterman.com/files/imlib2-1.1.0.tar.gz
(B> > this might be handy for you as a way of 1. measuring correctness (well so it
(B> > "looks right" - imlib2's algorithms are intended to do the right thing and
(B> > look right - not follow a strict formula - so ymmv here, but its better than
(B> > nothing). and 2. - especially useful, measuring speed vs. what can be done
(B> > in software on the client-side.
(B>
(B> I already use this for testing as it was the only benchmark for Xrender
(B> that I found.
(B
(Byay! :)
(B
(B> The non-scaled onscreen XRender went from 9.7 to 0.7 seconds... :)
(B> (imlib is at 2.3 seconds). The scaled versions are not accelerated, and
(B> they all are much slower than Xrender...
(B
(Bcool. though 0.7 vs 2.3 for imlib2 still isn't that good. i'd expect hardware to
(Bbe a factor of 10 or more faster these days. from having used opengl in evas (as
(Bopposed to imlib2 in the older code engine) on a geforce1 i was getting easily
(B20 times speedups for such ops.
(B
(Bbasically - avoid copying the pixel data aroudn or changing its format if you
(Bcan (ie if you put it through the 3d engine you may have to reformat the pixels
(Bdue to in-memory texture formats being "strange"). so i'd try and keep the
(Bpixels wherever they were last in the format they were in last - all the time,
(Bso a blend or scaled composite/blend is literally 1 hardware op and not much
(Bmore.
(B
(Bi don't actually know how you are doing it currently, so i'm just saying this as
(Ba general thing - but somehow i'd still expect hardware to be more than 3.3
(Btimes faster than the cpu :) maybe locality is affecting it (video ram vs agp
(Bmapped ram...)? could be many things. it may just be the blend hardware simply
(Bisn't that fast... not sure.
(B
(B> > if xrender can't beat client side rendering with the cpu either 1. the gfx
(B> > card simply is too slow and the driver probably should test its own xrender
(B> > software routines vs. hardware ones on init and chose the faster for the
(B> > situation and also if using software routines try and force source and
(B> > destination into system memory, not keep them in video ram. also accounting
(B> > for coimbinations of ops, sizes of source and dest etc.
(B>
(B> Since the hardware I' dealing with supports stretched bitblits, I'll
(B> look if that could be made of any use.
(B
(Bich freue mich schon darauf :)
(B
(B
(B--
(B--------------- Codito, ergo sum - "I code, therefore I am" --------------------
(BThe Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
$B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
