Have you compared the './configure' outputs? You can use easy_e17 (dont remember if you already are). By default, it generates logs for 'configure' step and 'make' step, for each program (or lib or whatever). Then, you can use something (like komparator) to check for diffs in both installation, maybe you can catch if you have a missing lib or something like that
BTW, have you checked .xsession-errors? I really don't think you'll see the problem here, but it won't hurt if you do =) El 8 de diciembre de 2011 08:07, Robert Krambovitis <rob...@split.gr>escribió: > > On Mon, 2011-12-05 at 12:13 +0900, Carsten Haitzler wrote: > > On Sat, 03 Dec 2011 16:47:39 +0200 robert <rob...@split.gr> said: > > > > > Good morning and thanks for your replies. > > > > > > @Wido : vendor is all nvidia, drivers appear to be working fine > > > > > > @Raster : > > > I am getting excellent performance on the older opensuse 11.4, and also > > > I tried installing Jeff's bodhi linux on which I also have excellent > > > performance. > > > So that at least rules out the possibility of hardware being the > > > culprit. > > > > one thing. have u done: > > rm -rf ~/.cache > > > > ? evas caches shader binaries in there to speed up startup time. it may > be > > possible between driver revisions something caused them to become > dog-slow. > > nuke that and see. > > > > > On my current latest opensuse however the problem remains. > > > I installed a previous version of xorg from source, problem remains. > > > I installed 2 different previous nvidia drivers, problem still remains. > > > I compiled and installed the latest 2.6 vanilla kernel, still problem > > > remains. > > > > > > I also tried recompiling and reinstalling r65800 directly (instead of > > > creating and then installing rpms), and problem persists. > > > > > > I have tried adding / removing / tampering with every option in > > > nvidia-settings, in the enlightenment configuration options, and > > > anything related from nvidia documentation in xorg.conf. > > > > > > I have cross-checked xorg.0.log from all 3 installations and not found > > > something wrong / different. > > > > well this smells like something driver related. same EFL, same hardware, > > different distro means performance goes from good to suck. so obviously > the > > issue is with the thing u changed - the distro. what components matter > here? > > > > kernel > > libc > > other system libs driver may depend on > > xorg > > > > something there somewhere be it a version of a lib, a patch that was or > was not > > applied or some setting that is different, is causing this. generally i'd > > advise you narrow it down, but as such its a WHOLE distro version > difference. > > you cant just upgrade/downgrade specific packages. all i can suggest is > you > > start with the older suse that works then package by package upgrade and > see. > > other than that you can just save time and simply not use that distro > > (version), but i assume you now are simply curious and angry enough to > want to > > know what the hell went wrong. all you can do now is "elimination". try > and > > change all the relevant parts of the os that will interact with nvidia > driver > > and performance . so eg - start with old suse that worked then install > newer > > kernel from newer suse (and i guess then newer nvidia driver too to > match) and > > see. keep going one step at a time until something causes the slowdown. > it'll > > be slow going as u probably are going to want to reboot between each > upgrade > > and test. > > > > > So I'm back at square 1. > > > > > > I found previous posts stating that gles / xcb should not be used and > to > > > let autoconfiguration take place. > > > Is this still the case ? > > > > yes. and its not enabled by default unless you go --enable it, so you're > safe, > > unless you've shot yourself in the foot. :) > > > > > Also I found a similar poor opengl performance thread by Jeff that > > > wasn't eventually resolved. Maybe he can shed some light on whether he > > > solved it in the end or if he is still having the same problems on that > > > particular machine. > > > > > > On a side note, I noticed on all 3 systems that with compositor > enabled, > > > when dragging a windows around (terminal in my case), cpu usage is > high. > > > When using software rendering, it's 60% enlightenment 40% xorg > > > When using openGL it's 85% enlightenment 15% xorg. > > > When compositing is disabled, cpu usage is normal. > > > > > > So I'm still stumped and open to suggestions. > > > > > > Thanks in advance, > > > > > > Robert > > > > > > > > > > ------------------------------------------------------------------------------ > > > All the data continuously generated in your IT infrastructure > > > contains a definitive record of customers, application performance, > > > security threats, fraudulent activity, and more. Splunk takes this > > > data and makes sense of it. IT sense. And common sense. > > > http://p.sf.net/sfu/splunk-novd2d > > > _______________________________________________ > > > enlightenment-users mailing list > > > enlightenment-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > > > > > 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. > > I can only assume that there is something missing from the system. > What could that possibly be ? > > On a side note, I noticed than when the compositor is enabled, even when > idle, strace shows plenty of activity, whereas without the compositor > 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. > > > > ------------------------------------------------------------------------------ > 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 > -- Wido ------------------------------------------------------------------------------ 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
