Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-19 10:47:11



Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
World not rezing fully 
Author Message

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Mogsington wrote:
Well now you've seen it!
As far as possible this is a very "untweaked" Linux install, using the distro's kernel and recommended Nvidia drivers. I have no problems with the graphics on any game or 3D program I can think of, and I'm not actually complaining about the graphics in this instance either.
So I'm not sure what to comment on that. None of the other SL clients I use seem to log the shader information the same way that CoolVL does, so it seems impossible to compare, except to say they only mention shaders 3 or 4 times in the entire log.

No I wasn't editing an object with media on it, or even trying to access a media prim.

As far as reproduction steps are concerned, I gave you a method that causes the fault for me. Obviously you will run your client and say it doesn't happen to you. It clearly isn't specific to a particular sim, or mesh, or texture. Sometimes its the chairs that won't fully load, sometimes it's a ladder, sometimes it's mainly textures. So asking me to provide a reproduction beyond the one I've already supplied seems a little .. tricky to resolve. I stated "when I go back home" in the earlier message to point out that a location that initially loaded fine, will then stop loading fine later in the same session. Not as in "It always happens here". It happens all over SL.

I guess here we shrug and call it a problem with my "fishy", "suspicious" usage, and assume it's a "probably badly configured" computer then. Although it clearly isn't as far as I can tell. All other viewers work fine. Dozens of games run fine. I can't think of any network or graphics problems in any other program that I use except CoolVL. So obviously. My set up must be to blame.

I'm sorry to have troubled you.

Your stubbornness to consider that your system is fine (and that the shader issue is not one, while it is), when you are the only, among hundreds of users, to experience that issue, your refusal to give even a location where I could try and reproduce your issue, are indeed troubling...


2017-01-26 21:00:16
Profile WWW

Joined: 2016-11-29 13:50:37
Posts: 17
Reply with quote
Perhaps you could point me at any test I might try on the GL shaders configuration on my system? I'm afraid I don't know of any I can run. I can tell you though that I have no graphics problems in CoolVL, any other SL viewer I use, multiple Wine programs (as an example which I know can be demanding on GL shaders), my entire Steam library, and about the weirdest "test" I can think of would be running Minecraft with GLSL shaders .. all of which work with no issues.

Perhaps it's a problem with how CoolVL deals with shaders in Linux?
As far as I'm aware, it is not an issue (outside of CoolVL logging it multiple times).

And for the sake of it, here are two example locations I've used to observe CoolVL failing to load textures and meshes.
http://maps.secondlife.com/secondlife/T ... 122/197/21
&
http://maps.secondlife.com/secondlife/D ... 2/194/3335


2017-01-26 21:56:36
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Mogsington wrote:
Perhaps you could point me at any test I might try on the GL shaders configuration on my system? I'm afraid I don't know of any I can run. I can tell you though that I have no graphics problems in CoolVL, any other SL viewer I use, multiple Wine programs (as an example which I know can be demanding on GL shaders), my entire Steam library, and about the weirdest "test" I can think of would be running Minecraft with GLSL shaders .. all of which work with no issues.

Perhaps it's a problem with how CoolVL deals with shaders in Linux?
No. The Cool VL Viewer is developed, tested and debugged under Linux. I made it for Linux and using it myself exclusively under Linux. I've been developing it for 10 years now, so I got a pretty intimate knowledge of its code and how it works, what should happen and what should not: obviously, even if it finally succeeds to compile the shaders on your machine, it has much trouble doing so, meaning your drivers are probably at fault.

I'm using NVIDIA cards myself (GTX 460, 660 and 970) with the proprietary NVIDIA drivers (because the Open Sources drivers just can't compete in term of speed and features), and I never, ever encountered such an issue.

Quote:
And for the sake of it, here are two example locations I've used to observe CoolVL failing to load textures and meshes.
http://maps.secondlife.com/secondlife/T ... 122/197/21
&
http://maps.secondlife.com/secondlife/D ... 2/194/3335
Went there (I made at least 10 TPs between the two sims, each time waiting for everything to rez, wandering around, flying about). I did not encounter any issue. Sure, there's a load of meshes over there, so it may take up to 3 minutes for everything to rez on first TP and 1.5 minute or so on next TPs, but everything rezzes and rezzes fine... I even made a video capture of it, if you wish (but it's 567Mb big, because it lasts for 23 minutes, so it's a bit too large for my site remaining quota)...

One thing you could also try, is to start with fresh debug settings, in case you'd have accidentally messed up one that would cause this disaster: simply log off, delete (or rename) ~/.secondlife/user_settings/settings_coolvlviewer_12620.xml, and restart the viewer, and see if it makes a difference with the default settings.


2017-01-26 23:42:00
Profile WWW

Joined: 2016-11-29 13:50:37
Posts: 17
Reply with quote
I will try erasing the settings file and let you know how it goes.
I'm running a few long compiles in the background at the moment though, so it perhaps wouldn't be a fair test until they finish.

While I'm here, I'm puzzled.
You say the shaders are loading 64 times? I don't see that in the logs. There's a long section where it loads up all the individual shaders, but it only does that once and doesn't report any errors. Which bit of the log are you looking at?

But, while I was there, I spotted this:
T18:55:33Z INFO: LLViewerTextureList::updateMaxResidentTexMem: Total Video Memory set to: 1024 MB

When my card has 2048MB ?


2017-01-27 00:09:59
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Mogsington wrote:
While I'm here, I'm puzzled.
You say the shaders are loading 64 times? I don't see that in the logs. There's a long section where it loads up all the individual shaders, but it only does that once and doesn't report any errors. Which bit of the log are you looking at?
At the first log you posted:
Code:
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
.../... (128 lines in total for materialF.glsl and materialV.glsl shaders alone = 64 loadings per shader !)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialV.glsl (Want class 1)
T18:55:53Z INFO: LLShaderMgr::loadShaderFile: Loading file: shaders/class1/deferred/materialF.glsl (Want class 1)


Quote:
But, while I was there, I spotted this:
T18:55:33Z INFO: LLViewerTextureList::updateMaxResidentTexMem: Total Video Memory set to: 1024 MB
When my card has 2048MB ?
Normal: this is the texture memory (and not even counting the bound GL textures and raw textures: you can get a split of these in the texture console, on its first line). Your graphics card VRAM is also used for frame buffers, vertex buffers, shaders, etc...


2017-01-27 00:18:43
Profile WWW

Joined: 2016-11-29 13:50:37
Posts: 17
Reply with quote
Ah. Didn't spot the duplicates. Just quickly scrolled through it.
Not at all sure why it would do that, except it seems Singularity (the only other viewer I can find that logs the same information), does the same thing.
I'm not even sure if it's an error condition since Singularity seems to run perfectly for hours.

I'm using Nvidia-375.26 as it's the marked "Stable" version. Which version are you running? I might try up/downgrading the drivers and see if that makes a difference. I'm still not convinced it's an error though. More a peculiarity.

But .... none of the problem I was commenting on: "World not rezing fully"(sic) seems to be related to the graphics card anyway. Aside from Singularity and CoolVL logs reporting multiple attempts to load the same shaders, I've not seen any behaviour to suggest there's a problem. Graphics acceleration appears smooth with no artefacts.


2017-01-27 01:10:21
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Mogsington wrote:
I'm using Nvidia-375.26 as it's the marked "Stable" version. Which version are you running?
Same.

I noticed another potential issue however:
Code:
2017-01-26T18:12:20Z INFO: LLAppViewer::init: LLCore::Http initialized. libcurl version is: libcurl/7.52.1 OpenSSL/1.0.2j zlib/1.2.8 libidn2/0.11 libssh2/1.7.0 librtmp/2.3
Is that a viewer binary you compiled yourself (purely academic question: the answer being obviously yes) ?

Please, try using the distributed 64 bits release instead... There could be issues with your distro's libraries (especially if they conflict with viewer pre-built libraries that got no equivalent in your distribution and that therefore must coexist and be compatible with your distro's): I'm thinking about curl, especially (the viewer pre-built curl library got fixes implemented by LL, that could be lacking in your distro's).
When compiling the viewer yourself with the buildlinux.sh script, please avoid using --usesystemlibs (I added this option recently, but it is largely untested, but for on my own computer, which is also used to build the viewer releases), so that only the pre-built and known to be working libraries are used.


2017-01-27 01:50:39
Profile WWW

Joined: 2016-11-29 13:50:37
Posts: 17
Reply with quote
Well I've only had one evening to really give things a decent try since then, and 90% of my time was spent in basically the same location.
I've gone back to "not system libraries" and reset the main preferences, and it does seem to be an improvement.
I'm not entirely convinced yet that curl was the entire problem, because I reached the point of running the system library version after trying the pre-compiled and "regular" compiled versions to solve the problem. It is possible though that once I was using the system library version that none of the settings changes I made were going to help.

(I also tried deleting the ~/.nv shader cache to see if that would change anything in the logs regarding shaders, but it makes no difference to the logs).


2017-01-28 12:01:52
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Mogsington wrote:
I've gone back to "not system libraries" and reset the main preferences, and it does seem to be an improvement.
There are many settings that can hurt the system performance. One such setting (that I might as well remove altogether, like LL did recently in their viewer) is the "Advanced" -> "Rendering" -> "Run multiple threads" which, when disabled, causes all texture/mesh/cache/vfs code to run serialized in the main thread instead of paralleled in separate threads, thus badly hurting performances... But there are others...

Quote:
I'm not entirely convinced yet that curl was the entire problem, because I reached the point of running the system library version after trying the pre-compiled and "regular" compiled versions to solve the problem. It is possible though that once I was using the system library version that none of the settings changes I made were going to help.
Some of LL's pre-built libraries got patches (boost, curl and several others) over what you would find in standard Linux distros. Not using them can cause linking failure at compile time, or crashes, slow down, unexpected behaviour at run time. I tried to eliminate the use of system libraries when using "--usesystemlibs" option of the build script for those which would *obviously* not work (e.g. boost, for which LL is using a custom coroutine patch, incompatible with official boost, or for freetype, which would not allow to display the bundled fonts should the system freetype library be used), but there may be others (curl is extremely critical: I might also prevent this one to be replaced with system lib in next releases). Even OpenSSL could be an issue... Your best bet is simply not to compile with the system libs option (all other viewers are using the pre-built libs anyway, never the system libs)...

Quote:
(I also tried deleting the ~/.nv shader cache to see if that would change anything in the logs regarding shaders, but it makes no difference to the logs).
This is still a mystery for me as well... But there's something fishy on your system, I'm afraid... Perhaps permissions issue on NVIDIA files/directories/devices (you could try and run the viewer as root to see if it happens as well or not) ?


2017-01-28 14:40:03
Profile WWW

Joined: 2016-11-29 13:50:37
Posts: 17
Reply with quote
I think I tracked it down .. not certain yet, because I'd need to try a few times and check it's repeatable .. but it appears to be related to the "Compress textures larger than:" option ... with that off, everything seems fine, with it on things seem to not want to finish rezzing / appearing in world.

As for the Nvidia .. nope. It's not a permissions problem, running as root has the same shader load behaviour. I've also checked all the related nvidia settings provided by the driver install, and they are all un-modified, in the correct places and have the right permissions. Everything according to the relevant wiki guide appears to be correctly set up. As I said, there are very few tweaks like that on this system .. where possible I like to leave things as "stock settings" to avoid issues. About the only area I have tweaked is soundcard module loading to lower latency and set the correct load order in ALSA.

My memory is hazy, but didn't the SL viewers make assumptions on shaders based on a graphics card table or something? Perhaps my card is a variant that doesn't quite fit? Just a thought.

But .. as I said before there's no evidence the shader loading behaviour is an error condition. Everything related to shaders works fine on the system. Both CoolVL and Singularity have error checking in the shader creation process, and neither of them ever report an error.


2017-02-09 20:26:34
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 20 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.