On Fri, 2011-12-09 at 14:16 +0900, Carsten Haitzler wrote:
> On Thu, 08 Dec 2011 13:07:34 +0200 Robert Krambovitis <rob...@split.gr> said:
>
> > Ok, so clearing .cache -> no effect
> >
> > Fresh installation of old opensuse -> Fine
> > Dist-upgrade above -> Still fine !!
> >
> > Fresh install of new opensuse -> No OpenGL !!
> > This is using the same kernel, driver, enlightenment rpms as above.
>
> well there is something that is different between a freshly installed
> opensusue
> and an old opensusue gone through a dist-upgrade. hwew is what i'd do. i'd
> list
> every file on the system (except /var/log, /sys, /proc and /home and /opt -
> which is where i assume the only thing installed is e17+efl) and see what is
> different:
>
> for I in `find /var -print | sort`; do echo -n "$I "; stat $I | grep size |
> grep -v blksize | awk '{printf("%s\n", $2);}'; done > /tmp/flog
>
> take the 2 flog files and then put them through diff. of course some files
> will
> be expected to be different - like packaging db's probably, but somewhere in
> this list of files that are different is possibly our cause.
>
> > I can only assume that there is something missing from the system.
> > What could that possibly be ?
>
> see above :)
>
> > On a side note, I noticed than when the compositor is enabled, even when
> > idle, strace shows plenty of activity, whereas without the compositor
>
> you sun strace in a terminal inside your x session? you do knwo that every
> redraw of of the terminal means e wakes up to re-composite the screen.. which
> leads to more strace output.. which leadds to a re-composite.. which leads to
> more strace output... :) you can't monitor a compositor from within itself -
> it's a self-feeding loop. ssh in from a remote host or do it from a text
> console (and log to a file). you'll find e only is waking up and doing things
> when it needs to - ie to poll on cpufreq or temperature or to handle a redraw
> by a client (that blinking cursor in your xterm will cause e to wake up every
> time it blinks on or off and handle as redraw - as will any changes to cpufreq
> dials or the clock gadget etc.)
>
> > enabled, strace shows idle enlightenment when not doing anything.
> > I believe that the comp module is due some tlc, as even on the "working"
> > systems performance is sub-par.
>
> not really. i think you're just doing it wrong. :) see above. e sleeps for
> several seconds at a time in between it having "things to do" when it wakes up
> and does them. the ONLY thing that might be able to be improved is reducing
> redraw areas when using opengl. as such, evas, when it redraws with gl,
> redraws
> the whole canvas, not just the update region. this is necessary since it uses
> swapbuffers. you cannot do swapbuffers and NOT redraw everything. swapping
> buffers means the driver can optimize a swap of a full screen buffer to be
> literally a swap - tat means it just swaps "links" where fb now points to what
> was the back buffer, and what was the frontbuffer nos is the backbuffer. the
> swap itself equates to the cost of changing a pointer (effectively). if your
> driver is not so good - it'll still COPY from back to front buffer anyway.
> also
> swaps mean you can nicely and seamlessly do tear-free vsynced rendering
> (copies
> have no guarantee that the copy can be done faster than the screen refresh).
> where evas could do better is if small regions are updated, it could just
> redraw that and copy from back to front (glcopypixels) where the cost of the
> copy is less that the cost of the excess over-draw. the problem here is that
> in
> the past i have found copypixels often not accelerated. that means the CPU
> reads from video mem and writes to other video mem. this can be abhorrently
> slow. if you look in evas's gl_x11 engine u'll even find commented out code to
> do just this. i've found it either to not work or be slow. anyway - that's the
> only thing i know of that can be improved. yes - evas adds overhead for scene
> graph management and other fun things, but not much. if you look at compiz vs
> e17, e17 uses about 20% more cpu (compiz uses about 10%, e17 about 12% cpu)
> when we are doing full screen redraws (eg video player playing full screen).
>
> > ------------------------------------------------------------------------------
> > Cloud Services Checklist: Pricing and Packaging Optimization
> > This white paper is intended to serve as a reference, checklist and point
> > of
> > discussion for anyone considering optimizing the pricing and packaging
> > model
> > of a cloud services business. Read Now!
> > http://www.accelacomm.com/jaw/sfnl/114/51491232/
> > _______________________________________________
> > enlightenment-users mailing list
> > enlightenment-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> >
>
Good Morning,
It seems I was mistaken,
having performed so many different tests, I reported incorrectly.
@wido: No I don't use the easy_e17 script, but I have compared
the ./configure output many times trying to find something different.
@carsten:
Correction:
When upgrading from opensuse 11.4 to 12.1, opengl worked fine and
performance was good when using the precompiled and tar'd /usr/local
from working enlightenment.
I checked and saw that I had not proceeded to install the same rpms.
When I removed the /usr/local and instead installed my rpms, I lost
opengl capability.
So this at least means that I've narrowed down the problem to something
to do with the rpm generation. Note that both the tar'd /usr/local and
the rpms were built on the same working 11.4 system with no extra
configure options.
I'll look into it some more over the weekend and report back.
As for the compositor performance, what you said about the terminal
output causing more compositing makes sense. Once I get this issue
sorted out I will perform more tests and comparisons and let you know
how it goes :)
Thanks
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
