Re: [e-users] E Built in Compositing Performance is Poor

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Sun, 20 Mar 2011 13:00:14 +1100 Jochen Schröder <cyc...@gm...> 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<pp...@gm...>  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<Jef...@li...>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
> >>> enl...@li...
> >>> 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
> >> enl...@li...
> >> 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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> 

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...