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.

-- 
------------- 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

Reply via email to