On Thu, 28 Aug 2003 03:30:18 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(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> >
(B> > cool. though 0.7 vs 2.3 for imlib2 still isn't that good. i'd expect
(B> > hardware to be a factor of 10 or more faster these days. from having used
(B> > opengl in evas (as opposed to imlib2 in the older code engine) on a geforce1
(B> > i was getting easily 20 times speedups for such ops.
(B>
(B> The hardware I am working with is not famous for being fast, and it uses
(B> a shared framebuffer architecture. I stopped dreaming about miracles a
(B> long time ago. (I think that was when I found out that drawing
(B> trapezoids using the engine is slower than doing it by the CPU)
(B
(Baaaaah shared framebuffer. ok. then i can understand some of the "hurt" :)
(B
(B> What values do you get on your hardware? (Unscaled only, the rest is
(B> entirely depending on the CPU)
(B
(Bfor the benchmarker:
(B*** ROUND 1 ***
(B---------------------------------------------------------------
(BTest: Test Xrender doing non-scaled Over blends
(BTime: 12.445 sec.
(B---------------------------------------------------------------
(BTest: Test Xrender (offscreen) doing non-scaled Over blends
(BTime: 10.056 sec.
(B---------------------------------------------------------------
(BTest: Test Imlib2 doing non-scaled Over blends
(BTime: 0.332 sec.
(B
(B(xrender doesnt have accel turned on there. if i turn it on it bats imlib 2 by
(B3-4 times. i cant get to that box right now... thanks to my isp being screwed)
(B:)
(B
(Bi dont have the old code working anymore for the gl engine i had - i just
(Bremember getting full screen 1600x1200 composities and scales going from
(Bsomewhere like 2 to 50+ fps once opengl got slid under the bonnet.
(B
(B> > basically - avoid copying the pixel data aroudn or changing its format if
(B> > you
(B>
(B> Yey, thanks for enlighting me :)
(B
(Bok... yes it was obvious - but i remember one driver would copy the pixeldata
(Btoa texture on EACH composite, THEN composite. :)
(B
(B> > can (ie if you put it through the 3d engine you may have to reformat the
(B> > pixels due to in-memory texture formats being "strange"). so i'd try and
(B> > keep the pixels wherever they were last in the format they were in last -
(B> > all the time, so a blend or scaled composite/blend is literally 1 hardware
(B> > op and not much more.
(B>
(B> I need to copy the texture to video RAM once, unless somebody tells me
(B> it already is there (I could use the 2D accelerator for this, too, then.
(B> In this case I just wonder why the mga driver doesn't do it this way.).
(B
(Bis this per composite? or just the first time it (the pixmap lets say) is
(Bcreated?
(B
(B> Since the accelerator does not sync after initiating the command, using
(B> the provided memory area is unsecure. The app might reuse it for
(B> something else before the command is actually executed. Syncing after
(B> the command is insane (because it could take forever, depending on the
(B> amount of commands already in the queue - and this queue is BIG)
(B
(Bhmmm do you have a way of knowing where the accelerator is up to? ie interrupts
(Betc? or every time you put somehting on the end of the pipeline query where its
(Bup to? so then the next gfx op you do you know if that memory region is
(Bvalid/invalid and you can happily do other things with it...
(B
(B> > i don't actually know how you are doing it currently, so i'm just saying
(B> > this as a general thing - but somehow i'd still expect hardware to be more
(B> > than 3.3 times faster than the cpu :)
(B>
(B> It's a fast CPU with fast RAM, and a slow GPU with memory shared with
(B> the CPU. More can't be expected, I guess.
(B
(B2.3 seconds for a blend doesnt smell like a fast cpu :) my 1.7ghz athlon gets
(Bthe 1:1 blends done in 0.3 secs or so. so technically my desktop cpu (ram/bus
(Betc.) is still double the speed of your sis gfx chips :)
(B
(B> Text drawing (x11perf -aa24text) went from 25000 to 105000, which is
(B> more than factor 4. I am satisfied. (Now, if I just could find out why
(B> the accelerator functions are not being called on my 4.3 system...)
(B
(Bthats good :) though i still like to compare x performance against external code
(B(ie like imlib2 - or use gdk-pixbuf, or anything else) and always try to at
(Bleast equal your "software rivals" :) i really want to see x accelerating where
(Bhardware can and beating the PANTS off any software code :)
(B
(B> >>Since the hardware I' dealing with supports stretched bitblits, I'll
(B> >>look if that could be made of any use.
(B> >
(B> > ich freue mich schon darauf :)
(B>
(B> You live in Australia, have a german sounding name, speak German... any
(B> special reason for
(B> using this icky JP font?
(B
$BF|K\8l(B $B$o$+$j$^$9!#(B [EMAIL PROTECTED](B $B$o$?$7(B $B$N(B $B%a!<%k(B
$B%/%j%(%s%H(B $B$O(B $BF|K\8l(B $B$*(B $B$7$^$9!#(B
(B
(B(ok i'ts not very good japanese - but i'm learning) :)
(B
(Bi am learning japanese too and on occasion read/write japanese e-mails :)
(B
(B> >>Is it correct to assume, that the image I see over a rainbow-like
(B> >>background is the result of RENDER, and over a grey-shaded background
(B> >>from imlib?
(B> >
(B> >
(B> > check the .png's in the directory.
(B> >
(B> > tst_opaque.png
(B> > is set as the background to the window before doing any compositing
(B> > and testing. this is done for both xrender and imlib2. it' sjust a
(B> > "test background".
(B>
(B> Hm, the background never looks like that gfx during render tests. I just
(B> see a rainbow-like gradient from top/left to bottom/right... (no matter
(B> whether with or without the accleration)
(B
(Breally? before anything is blended to the window (many copies of the gold "e"
(Blogo) you shoudl get the opaque image that has the gray gradient background and
(Bthose coloured gradient rectangles in it. it did that for me under xrender...
(B(4.3.0, nvidia driver). thats just what the imlbi2 code does too:
(B
(Bim_win = imlib_load_image("tst_opaque.png");
(B
(Bie imlib2's "window" (im_win) is simply that image loaded from disk.
(Bthre render equivalent makes a 320x320 xrender picture and then populates it
(Bform the image (creating a set of pixels pre-multiplied by alpha). that should
(Bsimply display the image... unless i've done something horridly wrong... ? have
(Bi? i hope not!
(B
(B> > you will notice for about 2 seconds after each imlib2 test completes
(B> > it displays its work on the screen in the window. this is just to let
(B> > you know that imlib2 did the right thing.
(B>
(B> I changed these delays to check if the rendering is ok. It actually is,
(B> it looks EXACTLY like the imlib result. :)
(B
(Bcool- well i know it's not a perfect correctness suite - but for most people it
(Bprobably should let u see if ti looks right - and it could always be a driver
(Boption to turn on/off if users are picky about exactness/correctness and some
(Bcalcs have a few rounding errors and slight color variations. :)
(B
(B> > the code is fairly straight-forward and modular too if you want to
(B> > fiddle with it, disable tests for now etc.
(B>
(B> Been there, seen that, done that. :)
(B
(Bexcellent. - well if i did anything wrong, tell me. theres precious little
(Bxrender code out there to use as examples... so a lot of that benchmark was me
(Brecycling whatever knowledge i may have had and a lot of poking at it till it
(Bworked :)
(B
(B> > good... and scaled woudl be lurvely! :)
(B>
(B> That could be a problem. So far, I haven't found a suitable hook for
(B> this (and replacing the entire composite function seems a bit far
(B> fetched at the moment)
(B
(Bhmmm but likely you would be better wrapping it. special case the 1:1 (as
(Bcurrently) on a per call basis (do it within the call) and detect certain
(Btransforms (ie non rotation/skew ones) since scaling blitters often only do
(Bsimple pixel scaling - not full matrix transforms. (tho my knowledge of this may
(Bbe waaay out of date by now), and pump them through the acclerator :)
(B
(Bwell i hope it works out well. :)
(B
(B> Thomas
(B>
(B> --
(B> Thomas Winischhofer
(B> Vienna/Austria
(B> thomas AT winischhofer DOT net http://www.winischhofer.net/
(B> twini AT xfree86 DOT org
(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
