Hi, On Wed, 2008-11-12 at 18:32 +0900, Carsten Haitzler wrote: > On Tue, 11 Nov 2008 14:50:46 +0000 Matthew Allum <[EMAIL PROTECTED]> > babbled: > > > Hi; > > > > On Tue, 2008-11-11 at 06:25 -0800, Ian Lawrence wrote: > > > > > > Others are looking at performance issues too > > > http://lists.o-hand.com/clutter/1209.html > > > and it seems loading images into GL textures is an expensive process > > > which can only realistically be achieved with extra hardware and/or > > > some future caching system . This cost needs to be taken into > > > consideration when other solutions like EFL already exist and have > > > been proven to work well in this space. > > > > Uuhhh - if your saying you take a hit in moving image data from system > > to texture memory then yes of course you will on certain hardware > > setups. How much this hit is and how relevant that is to the real world > > is debatable *but* this is a dumb argument anyway Clutter on GPU will > > outperform many 100x in terms of rendering operations (and more) > > compared to software only options. If it did not, GPU's would not exist. > > hmmm i would have to say "many 100x" is going to be a major leap. we > actually have benchmarks. gl vs software. sure.some things are a lot faster in > gl (5-10x). others.. software beats gl. in fact the averags fps i get on a > normal desktop (2x core core2 3ghz) vs an nvidia 8600gt - evas. gl vs > software_x11 - over all tests in expedite (which is a fair few) gl gets an > average of about 1100fps (from memory) and software is pushing 800fps or so... > got real numbers. that's from memory - but on my current laptop. > > nvidia 8600m (mobile) vs core2 due 2.3ghz mobile: > 868fps vs 671fps (for all tests)
This clearly isn't a fair test - it's apples to apples, but Clutter isn't an apple, it's more like a 10-course banquet. Also, comparing a dual-core 3ghz machine vs 8600GT probably isn't of the same order as, say, an Atom 1.6ghz vs. a GM965-based GPU either. You don't mention anything about RAM or video RAM either, which are two important factors, given that a lot of your tests will probably be restricted by how fast memory can be read/written. Also, Matthew's '100x' comment was clearly meant to just give the general impression 'much faster'. Even if it were just, say, 10x faster, that still means it can do something 10 times that you could do only once in software in the same time, and it can do it without lumbering the CPU too. That aside, I'm a little suspicious of the numbers too; > let me quote some "interesting results". > > 1. alpha blending a whole bunch of non-scaled images (1:1) gl ONLY managed to > be 4x faster than software... not 100's of times. I outright just don't believe this. Alpha-blending is inherently a slow operation and you'd definitely see a larger speed up doing this in hardware, unless your test is very limited, or you're taking some quality-affecting or constraining short-cuts. Could you elaborate on what this test actually does? Perhaps you only see a 4x speed up if you blit alpha-blended rectangles, one at a time, per rectangle... Try alpha-blending 20 reasonable-sized (say 256x256) textures, on a reasonable-sized (say 1024x768) buffer, with varying alpha over a background image. I'd be hard-pushed to believe, even with your skewed setup, that you'd only see a 4x speed-up. > 2. at BEST when doing "smooth scaling" (that means for GL GL_LINEAR vs full > super/sub sampling in software (which is much higher quality especially on > down-scale) gl manages at BEST to be 30x faster than software. different > algorithms here so software is at a major disadvantage due to its higher > quality. Well, 30x is quite a lot, I'm not sure why you say it as if it isn't a big deal - if you're doing basic UI things, why do you even need something better than bi-linear filtering? Saying software is at a disadvantage because it's higher quality is silly. Either compare it with anisotropic filtering, or write a fast bilinear software filter. I think you'll find that the hardware does this a lot better. > 3. apples vs apples... scaling an image with "GL_NEAREST" in software and > gl... > gl is 5.8times faster. Yes, but scaling a 2d, axis-aligned texture using nearest-neighbour scaling looks AWFUL and you'd never do this. This test is pointless. > 4. software is actually FASTER for alpha blending a whole bunch of rectangles > - > 25% faster. gl uses just a quad. software is at an advantage - it's smarter > adn > can calculate deltas better I can believe this, for your setup, but only because you have a very powerful CPU and probably have very fast memory. Do you still get a 25% faster result if you count the time it takes to copy the buffer from system memory to video memory though? Also, 25% faster than what, a microsecond? I'd contend that alpha blending rectangles isn't that common an operation, vs. say scaling, rotation, or alpha-blending a texture, and it happens so fast using either method, that quoting a 25% speed gain isn't actually as big a deal as it sounds. > 5. gl shos overhead on having to upload ARGB pixels textures - software > manages > to do the argb data change test about 25% faster than gl (that includes also > drawing the image to the screen after upload of new data). I'm not sure what this test is? If you mean it takes longer to upload ARGB data to video memory than it does to system memory, I'm surprised the result is only that much faster. I guess that's a good thing though, it's always good to find out that system->video memory bandwidth isn't as big an issue as you think it is :) > i'm just saying this above as i believe that there are bogus facts being > floated about (efl starves your cpu - incorrect. it uses just as little/much > as > clutter would.. if you use the gl engine or any other accelerated back end - > xrender (an the acceleration is working) etc.) and the numbers on "gl is 100x > faster" i would say is entirely bogus. i am pitting a very very very fast gpu > against a very fast laptop cpu. and the cpu is doing a stellar job of keeping > up... considering. and both engines can be optimised - i know just what i > could > do to improve them, and i don't see that your numbers will change so > drastically if i did it on both ends. :) Yes, if you use EFL's GL engine you might get the same performance as Clutter, at the expense of an API that doesn't integrate as well with the rest of the Moblin libraries, and is arguably not as nice to use (but then, I would say this being a GTK and Clutter hacker, so take this with a bowl of salt). I'd be interested in some clarifications on those tests. Cheers, --Chris _______________________________________________ Moblin dev Mailing List [email protected] To manage or unsubscribe from this mailing list visit: https://lists.moblin.org/mailman/listinfo/dev or your user account on http://moblin.org once logged in. For more information on the Moblin Developer Mailing lists visit: http://moblin.org/community/mailing-lists
