Hi; On Tue, 2008-07-01 at 20:17 -0400, Jason Tackaberry wrote: > On Tue, 2008-07-01 at 23:27 +0100, Matthew Allum wrote: > > I've never noticed high CPU usage with > > clutter_texture_set_from_rgb_data(). Have you tried profiling it to > > check if it really is set_from_rgb_data and if it is, if anything bad is > > happening below in COGL ? > > I had profiled it insofar as commenting out the call to > clutter_texture_set_from_rgb_data(), which when doing so the CPU usage > dropped to zero. > > On my system, the call itself takes about 1700us for a 640x480 image > (and uses about 35% cpu for 60fps), and a 1920x1080 image takes around > 12000us (and uses ~80% cpu). > > I'll do some better profiling inside clutter to figure out what's going > on. Speeds that bad smells like maybe a mesa fallback. I do know that > evas is much faster at updating textures, so there's nothing > intrinsically problematic with my card or driver. > > I've attached a simple test to benchmark this. I wonder how it compares > with other graphics cards / drivers?
Thinking a bit more about this, CPU usage could be happening if the Texture is 'sliced' - i.e the driver cant do NPOTs sized textures so the displayed texture is made up on many smaller POT ones. Could you try adding 'g_object_set (tex, "disable-slicing", TRUE, NULL); to the test and see if that makes any difference for you. Also I kind of assumed your h/w would be able to do NPOTS, so it could be a bug in COGL. The COGL stuff has recently been completely rewritten (for 0.8) and its complex stuff so there is bound to be a few wrinkles. > > > > Path2 should ultimately be fastest and most portable hardware wise. > > Yes, although path 1 is providing immediate gratification (at least for > nvidia), performs very well (it is viable to use for 1080p h264 video), > and has the benefit of not requiring to write custom VOs for the players > we want to support. Yeah understand. > > Unfortunately, it seems clutter_glx_texture_pixmap_new_with_window() > doesn't work on Intel GMA, although the x11 variant does. (I had a > friend test it, and it segfaults.) Might anyone know what's missing in > terms of support from the intel driver and/or mesa for this to work? I think there are bugs in some intel drivers where they claim support tfp but dont and the fallback code is a little broken currently in trunk (there are a couple of bugs open, going to look into fixing today - have been battling tfp mipmaps and no joy :( ) > > As an aside, I started playing with clutter for the first time on > Saturday, and the more I dig into it, the more I am impressed by it. > Very nice code and design, and I appreciate the fact that it provides > lower level hooks at various layers, right down to > cogl_texture_new_from_foreign(). Shows good foresight, as it's quite > frustrating to have your hands tied by an inflexible or immature API. > So kudos to the development team and contributors. > Thank you! Much appreciated :D == Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
