On 10/10/2016 08:42 AM, Carsten Haitzler (The Rasterman) wrote: > On Sun, 9 Oct 2016 17:58:05 -0700 Eric <eri...@cox.net> said: > >> On 10/09/2016 04:22 PM, Carsten Haitzler (The Rasterman) wrote: >>> On Sun, 9 Oct 2016 13:24:34 -0700 Eric <eri...@cox.net> said: >>> >>>> On 10/08/2016 05:06 PM, Carsten Haitzler (The Rasterman) wrote: >>>>> On Sat, 8 Oct 2016 09:59:27 -0700 Eric <eri...@cox.net> said: >>>>> >>>>>> On 10/08/2016 02:33 AM, Simon Lees wrote: >>>>>>> >>>>>>> >>>>>>> On 10/08/2016 06:25 PM, Eric wrote: >>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Thank you Simon, >>>>>>>> >>>>>>>> I was able to get it working using the repository. I did find out that >>>>>>>> the problem was with the new NVIDIA driver that I have to choose >>>>>>>> software rendering instead of OpenGL. With OpenGL I just get the mouse >>>>>>>> cursor icon displaying with nothing else. Using software rendering >>>>>>>> makes my desktop a little sluggish on this machine. >>>>>>>> >>>>>>>> I am going to see if I can role back the NVIDIA update somehow. My >>>>>>>> google search has not led me with the right info on how to do that yet >>>>>>>> on openSUSE. >>>>>>>> >>>>>>>> Eric Meddleton >>>>>>>> >>>>>>> >>>>>>> Updates should remain available, so if you go to yast search for NVIDIA >>>>>>> in the software manager, there should be a version tab that you can use >>>>>>> to roll back. >>>>>>> >>>>>>> >>>>>> >>>>>> Unfortunately, the previous version for NVIDIA is not available in yast, >>>>>> just the version I have installed and the i586 version. (But that is >>>>>> getting into openSUSE territory and not really applicable to e-users >>>>>> discussion.) >>>>>> >>>>>> Now that I remember, I had a similar situation on a different machine >>>>>> with Arch linux a year or so ago. That machine had a NVIDIA GeForce >>>>>> GTX570 card. I have just lived with the software rendering on that >>>>>> machine without any noticeable difference maybe due to it having an >>>>>> intel i7 processor. No updates on NVIDIA or enlightenment and the ELF >>>>>> libraries has helped since then and the downgrade would have meant >>>>>> also downgrading the kernel so I just let it go. It may just need to be >>>>>> re-installed to get it all sorted out and I just have not wanted to try >>>>>> that yet. :-) >>>>>> >>>>>> The machine in question now only has an AMD Athlon(tm) 64 X2 Dual Core >>>>>> Processor 5600+ and is getting a little old. I will try updating >>>>>> openSUSE to the next version to see how that goes. >>>>>> >>>>>> Thank you very much for your help. >>>>> >>>>> hmmm i wonder if it's the shader cache? try >>>>> >>>>> rm -rf ~/.cache/evas* >>>>> >>>>> >>>> >>>> Wow, >>>> >>>> This was what was wrong with my Arch linux install all along. I deleted >>>> the .cache files and now I have openGL working again on that system. >>>> >>>> Thank you very much, >>>> >>>> Eric Meddleton >>> >>> interesting. what gpu/driver? we use the string info from the gl driver >>> (vendor, renderer and version), and this should lead to a different file in >>> in the cache directory if these strings change. also we use the efl version >>> there too. so any upgrade of efl will result in a new shader cache being >>> generated as will any change from the driver. we kind of expect the gl >>> driver to change its renderer/vendor/version strings should anything change >>> in the driver that would affect the binary shaders we cache. if the driver >>> doesn't do this i'd be inclined to file a bug report with the driver >>> author/maintainer as i really don't know of another mechanism to know that >>> the cached binary shaders are still usable. the efl version changes because >>> we may change shaders between versions (the source) so this should handle >>> that. the only case that will possibly be an issue is "during development" >>> when we are working on git master >>> - if a shader changes indeed our version will not have changed and you want >>> to nuke the shader cache manually. this is only relevant for developers or >>> those tracking git master. we are geared to producing a clean release so >>> things can be a bit dirty during development. >>> >>> for example here are some of the files in 2 of my shader caches locally: >>> >>> 8:13AM ~ > ls ~/.cache/evas_gl_common_caches >>> total 24K >>> 4.0K 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX >>> 970PCIeSSE2::v-1.18.0::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0 >>> NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.0::surface_cap.eet' 4.0K >>> 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX >>> 970PCIeSSE2::v-1.18.99::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0 >>> NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.99::surface_cap.eet' 4.0K >>> 'NVIDIA Corporation::4.5.0 NVIDIA 370.28::GeForce GTX >>> 970PCIeSSE2::v-1.18.99::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0 >>> NVIDIA 370.28::GeForce GTX 970PCIeSSE2::v-1.18.99::surface_cap.eet' >>> >>> @ 8:20AM ~ > ls ~/.cache/evas_gl_common_caches >>> >>> total 52K >>> 4.0K 'Intel Open Source Technology Center::3.0 Mesa 11.0.5::Mesa DRI Intel >>> (R) Haswell Mobile ::v-1.16.99::surface_cap.eet' 4.0K 'Intel Open Source >>> Technology Center::3.0 Mesa 11.1.1::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.17.0::binary_shader.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 11.1.1::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.17.99::binary_shader.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 11.1.2::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.17.99::binary_shader.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 11.1.2::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.17.99::surface_cap.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 11.2.2::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.17.99::binary_shader.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 11.2.2::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.18.0::binary_shader.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 11.2.2::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.18.0::surface_cap.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 12.0.1::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.18.0::binary_shader.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 12.0.1::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.18.0::surface_cap.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 12.0.1::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.18.99::binary_shader.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 12.0.1::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.18.99::surface_cap.eet' 4.0K 'Intel Open Source Technology >>> Center::3.0 Mesa 12.0.3::Mesa DRI Intel(R) Haswell >>> Mobile ::v-1.18.99::binary_shader.eet' >>> >>> the ::'s are the delimiters between string fields used. we do sanitize the >>> strings coming from the driver strings and remove the / char if there. :) >>> we could remove more, but haven't seen a need to yet. >>> >>> also note - these caches exist for good reasons. compiling shaders is not >>> that cheap if you have to do it every time your process starts. also >>> querying surface info isn't that cheap either, s that is why we cache it as >>> its far cheaper to load and decompress a pre compiled etc. shader than it >>> is to recompile them. >>> >> >> I am using the NVIDIA GeForce GTX-570 card. It is a PCIe/SSE2 type. >> The driver is NVIDIA version 370.28 using the arch linux repositories. >> >> The version seems a little weird after looking at NVIDIA's website as >> they show the latest version at 367.44 unless I am looking at it wrong. >> >> Now I just have two files in my ~/.cache/evas_gl_common_caches >> directory. They are: >> >> NVIDIA Corporaton::4.5.0 NVIDIA 370.28::GeForce GTX >> 570PCleSSE2::v-1.18.0::binary_shader.eet >> and >> >> NVIDIA Corporaton::4.5.0 NVIDIA 370.28::GeForce GTX >> 570PCleSSE2::v-1.18.0::surface_cap.eet >> >> I don't remember what the old files were but there was about 6 - 8 files >> with some as old as June 2016 if I remember correctly. >> >> Kind regards, >> >> Eric Meddleton > > very very odd. nvidia version their strings pretty well, as does mesa... i > really am not sure why this would be a problem? hmmm. > >
It is probably an operator error of some kind. ;-) I am still learning a lot about Arch Linux. I do enjoy using enlightenment desktop and do not want to use something different so I try to get it running on any machines that I may have to use. Kind regards, Eric Meddleton ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
