Raster, Maybe it was a corrupted file?
Maybe use EET features to verify that by signing or compressing or even some checksum? On Mon, Oct 10, 2016 at 7:43 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Mon, 10 Oct 2016 12:30:31 -0700 Eric <eri...@cox.net> said: > >> 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 > > well iam really curious as to why this happened as at least we tried > versioning > everything correctly so this shouldn't happen UNLESS a version didnt bump when > shader or binary produced did bump/change. at least thats my first guess and > finding out where/why might not be a bad idea... :/ but not knowing where > won't > help fix anything. :( > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > 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 -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ 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
