On Sun, 20 Mar 2011 11:44:36 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> said:
small correction. the sony x505 i mentioned was using the... basic vesa driver.. with shadowfb on. which of course added yet more overhead and copies. as a compositor effectively acts as a shadowfb anyway there is no point, so disabling shadowfb.. on a basic vesafb driver on a 600mhz pentium-m gets me a good 40fps. the video in question is actually 50fps so no - it's not keeping up completely, but its amazingly good considering everything that is actually going on. :) > On Sun, 20 Mar 2011 13:00:14 +1100 Jochen Schröder <cycoma...@gmail.com> said: > > well software compositing involves readback from video memory - copying with > the cpu back to mem in the compositor, rendering there, then writing that all > back to video memory after compositing. it will suffer unless you have > mountains of bandwidth BOTH ways (read and write) and a very fast cpu. "gnome" > will use "compiz" most likely and thats using opengl - acclerated compositing. > as i already explained in emails, evas requires a GLSL shader. its baseline of > support is opengl2 featuresets (opengl-es2). you need ACCELERATED GLSL shader > support. without this you end up wither with no GL engine at all (it fails to > init and comp falls back to software instantly - it doesnt tell you when it > does), or with GL emulating the fragment shader in software (thus hyper-slow. > much much much much slower than software compositing). compiz doesn't require > shaders. it can live on a much lesser opengl 1.x featureset. evas uses shaders > because there was a choice of maintainability and full-featured acceleration > to be addressed. opengl-es2 does NOT have a fixed pipeline. it ONLY does > shaders. you cannot support opengl-es2 WITHOUT doing shaders. also evas uses > sahaders for yuv->rgb, and inf act is gaining more and more shaders for > things like filters, clipping and more. if your driver+gpu can't do > accelerated GLSL shaders, you're out of luck with evas's GL engine. as i said > before - nvidia cards did this as of the geforce 6xxx series (i remember that > as of then shaders ran fast as opposed to dog-slow). you will ALSO need > decent drivers. t_unix found that the normal radeon drivers simply didn't do > GLSL shaders on his ATI, but gallium drivers did. so driver problem. for > intel graphics - can't say, but the 945gm (4500mhd) on my desk here, which is > a few years old by now, happily does shaders in hardware and supports GLSL > just fine. > > so likely you have a gl compositor in gnome (compiz) using > texture-from-pixmap. that's why it's fast. e17's compositor is perfectly > capable of being just as fast and smooth - if your gl drivers do GLSL shaders > and hardware does too and you enable texture-from-pixmap. it's silky smooth > on my desktops, laptops and this intel gpu system here. it's silky smooth on > embedded cpu's that do opengl-es2 properly(s5pc110) even at 480x800. > > as for video playback... on my desk here i have an old sony x505 - its a 1ghz > pentium-m that i keep clocked down to 600mhz because it overheats if it runs > at 1ghz. passive cooling only. intl i855 graphics... so basically no GL at > all. totally software rendering. screen runs 1024x768@32bpp. i can use > mplayer here to play a video: > > VO: [x11] 752x416 => 752x416 Planar YV12 > > and i manage a good steady 30FPS in the compositor. and that's clocked at > 600mhz. of course it starts to throttle itself to T1 and T2 states after a > while due to overheating and so things slow down, but even at 600mhz software > compositor is happily coping at 30fps. yes the cpu is 100% utilised and xorg > actually chews most of it (uploading pixels from mplayer than grabbing them > back to comp almost certainly). software compositing is perfectly capable of > working well. MAYBE it's your cpufreq that is jumping up and down cpuclocks > often. changing cpuclock actually takes some time for the cpu to do, and this > can lead to stuttering and non-smooth performance. lock it in at the top > clockrate or the bottom one or a middle one and see. > > > This discussion actually reminds of something I have been meaning to > > report for quite a while. I have a desktop system with a low end radeon > > card, and a laptop with integrated intel card. On both systems I'm using > > software engine for composite, because it's significantly faster than > > GL, however when I watch videos (either through vlc/totem or flash) in > > full-screen they become jerky, not terribly but just enough to notice > > (I'd say a frame rate of ~15-17). Checking composite full-screen does > > not make any difference at all. The videos run fine in Gnome with > > composition enabled. Any ideas? > > > > Cheers > > Jochen > > > > > > > > On 19/03/11 22:15, Carsten Haitzler (The Rasterman) wrote: > > > On Sat, 19 Mar 2011 17:31:04 +0800 P Purkayastha<ppu...@gmail.com> said: > > > > > >> It seems to depend on the type of nvidia card you have. I had a T61 with > > >> nvidia card NVS140m with 128M video ram. Composite would be decently fast > > >> for a while, but gradually get very slow after a couple of hours. The > > >> slow-down could be hastened if I dared to run any video via vdpau, or > > >> restart e. ecomorph used to run fine for a while, but eventually get slow > > >> too (in about a day). > > >> > > >> I now have a different laptop with nvidia 310M with 1G video ram. > > >> composite is really fast in this. The card seems able to run without any > > >> slowness, tested for over a week. Restarts of e or playing videos via > > >> vdpau has no slow-down effect. > > >> > > >> The difference between the above two systems was so stark that I believe > > >> my earlier graphics card (or the driver) was just not up to the mark. > > >> Also, probably composite is more taxing and unforgiving on your gpu than > > >> ecomorph/compiz (raster can confirm perhaps?). Eventually, the nvs140m > > >> graphics card died suddenly in the middle of playing a video (the > > >> infamous nvidia hardware problem). This also leads me to believe that > > >> the hardware was not up to the mark. > > >> > > >> raster has always claimed that composite was smooth on his system (that > > >> too with a dual screen setup at high resolution). I presume he has a > > >> powerful enough and recent graphics card. > > > > > > actually have a whole range off them. my desktop has the lowest end > > > nvidia - 8600GTS with only 256m ram. laptop actually is the highest end > > > (gt-330m, 1gb vid ram). > > > > > > as such this slowdown issue is almost certainly some nvidia driver > > > resource leak. you will find that no matter how many times you restart the > > > enlightenment process, it will remain slow until an Xorg restart. > > > > > > evas is the rendering engine for e17's comp module. that means it needs > > > what evas needs. evas needs a GLSL capable GPU. old GPU's just don't cut > > > it and drivers that don't support GLSL (properly and efficiently) will be > > > poor. As such a good driver that supports GLSL will perform equally well > > > as compiz. just the baseline support requirement for evas's rendering is > > > higher than compiz (needs newer card and decent drivers). As such all > > > nvidia cards have done full hardware shaders that are GLSL capable since > > > the GF6xxx series. there will be no difference between GLSL and fixed > > > function on these level of cards and up as all the fixed pipeline is > > > implemented as shaders anyway. apparently the open radeon drivers don't > > > (properly) support GLSL shaders, so with ati you're screwed unless you > > > use the gallium drivers i understand. they can do shaders right. fglrx > > > (closed drivers) do do shaders right, but fglrx just cant properly handle > > > direct rendering + compositing, so texture-from-pixmap exhibits bugs. > > > nvidia handles this just fine. the intel drivers do shaders just fine on > > > the 945GM i have and work just fine with e17's comp and speed is good. no > > > resource leak issues. > > > > > > you may want to try the newest nvidia drivers and combinations to see if > > > issues went away. jeffdammeth also suspects loose binding of textures may > > > trigger it, though compiz also can use loose binding (loose binding is a > > > good speedup for nvidia - or was). it might be interesting to disable > > > loose bindings on nvidia (see evas_x_main.c in the gl_x11 engine where it > > > does gw->detected.loose_binding = 1 when detecting nvidia). > > > > > >> On Sat, Mar 19, 2011 at 7:44 AM, Jeff > > >> Hoogland<jeffhoogl...@linux.com>wrote: > > >> > > >>> Howdy There, > > >>> > > >>> So I finally got Evas/Ecore to build with OpenGL support - so my > > >>> compositing > > >>> is now running in OpenGL mode (instead of software) and much to my > > >>> dismay everything still runs horridly slow on my nvidia graphics card! > > >>> Ecomorph/other three-d run just fine, but E's built in compositing is > > >>> just a > > >>> dog. It is lessthan smooth when changing desktops and it cuts the FPS I > > >>> see when gaming down to 1/3 of what it normally is. Is this normal or is > > >>> something wrong with my setup? > > >>> > > >>> ~Jeff Hoogland > > >>> > > >>> ------------------------------------------------------------------------------ > > >>> Colocation vs. Managed Hosting > > >>> A question and answer guide to determining the best fit > > >>> for your organization - today and in the future. > > >>> http://p.sf.net/sfu/internap-sfd2d > > >>> _______________________________________________ > > >>> enlightenment-users mailing list > > >>> enlightenment-users@lists.sourceforge.net > > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > >>> > > >> ------------------------------------------------------------------------------ > > >> Colocation vs. Managed Hosting > > >> A question and answer guide to determining the best fit > > >> for your organization - today and in the future. > > >> http://p.sf.net/sfu/internap-sfd2d > > >> _______________________________________________ > > >> enlightenment-users mailing list > > >> enlightenment-users@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > >> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Colocation vs. Managed Hosting > > A question and answer guide to determining the best fit > > for your organization - today and in the future. > > http://p.sf.net/sfu/internap-sfd2d > > _______________________________________________ > > enlightenment-users mailing list > > enlightenment-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
