On Mon, 10 Oct 2016 19:56:44 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> Raster, > > Maybe it was a corrupted file? a corrupted file should entirely fail to load. the entires are compressed so if the compressed data got an error the decompress would fail thus load fail. only if it was corrupted in some way that magically kept it a valid decompressable chunk and thus decompressed "funny"... 0it could be the data corrupted in ram before compression. when we read back the shader binaries they were messed up... but we have no way of knowing that. i find it unlikely they'd be corrupted by other code as when we compile shaders, we then save them all pretty much immediately and they dont have time to get messed up really by other code/threads... hmmm. we do rely on the filesystem to not go magically corrupt files. we could crc check etc. etc. but this shouldnt be necessary unless the kernel, filesystem, ram, cpu or actual media don't have serious low-level issues (bits flipping in ram after compress or cpu literally dropping data on copying/moving around, in which case there are major hardware problems on the system). if there are kernel bugs (in fs code or other related code) then thats pretty nasty. > Maybe use EET features to verify that by signing or compressing or > even some checksum? yeah - though this will add overhead if we do this on every load. i kind of considered there to already be enough safeguards like the decompression and the fs/kernel etc. taking care of this... :/ we do have eet file signing but it does require a proper certificate to do it with. we could just have a crc32 checksum somewhere and have a tool be able to sanity check he eet file if requested... > On Mon, Oct 10, 2016 at 7:43 PM, Carsten Haitzler <[email protected]> > wrote: > > On Mon, 10 Oct 2016 12:30:31 -0700 Eric <[email protected]> said: > > > >> On 10/10/2016 08:42 AM, Carsten Haitzler (The Rasterman) wrote: > >> > On Sun, 9 Oct 2016 17:58:05 -0700 Eric <[email protected]> said: > >> > > >> >> On 10/09/2016 04:22 PM, Carsten Haitzler (The Rasterman) wrote: > >> >>> On Sun, 9 Oct 2016 13:24:34 -0700 Eric <[email protected]> said: > >> >>> > >> >>>> On 10/08/2016 05:06 PM, Carsten Haitzler (The Rasterman) wrote: > >> >>>>> On Sat, 8 Oct 2016 09:59:27 -0700 Eric <[email protected]> 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) [email protected] > > > > > > ------------------------------------------------------------------------------ > > 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 > > [email protected] > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
