Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2025-07-23 13:06:53



Reply to topic  [ 12 posts ]  Go to page 1, 2  Next
Unable to enter into Deferred Rendering (ALM) 
Author Message

Joined: 2018-12-09 20:51:20
Posts: 8
Reply with quote
Recently returned to Cool VL Viewer for its ability to toggle amongst PBR, ALM, and forward rendering however I am finding I cannot enter ALM. When attempting to enable ALM I see the small pop-up dialog indicating it is compiling shaders but nothing changes. This is the result after attempting to enable through both the Preferences > Graphics pane and the Advanced > Rendering > Deferred Rendering options.

My noticification that ALM is not being entered is seeing the yellow ALM tag in the menu bar.

Forward rendering and PBR seems to be working normally. When in PBR mode the ALM tag in the menu bar appears green.

While logic dictates I just remain in PBR rendering, having a GPU with only 8 GB VRAM means that while hosting events attended by 70 or more avatars, my textures become ultra blurry, even with a draw distance of 32m. Being able to drop into ALM would be ideal though I am making do with simple forward rendering... for now.


Attachments:
CoolVLViewer.zip [38.79 KiB]
Downloaded 102 times
About Cool VL Viewer.txt [1.49 KiB]
Downloaded 102 times
2025-02-19 21:22:23
Profile

Joined: 2009-03-17 18:42:51
Posts: 6019
Reply with quote
Can you at all use ALM on your system with other non-PBR viewers (e.g. with Firestorm v6.6) ?

There are strange shader compilation errors in your logs, that should not happen:
Code:
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 2 - File: windlight/sunDiscV.glsl
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 2 - File: windlight/sunDiscF.glsl
2025-02-19 21:08:44Z WARNING: LLShaderMgr::linkProgramObject: GLSL linker error:
2025-02-19 21:08:44Z WARNING: LLShaderMgr::dumpObjectLog: error: fragment shader input `vertex_color' has no matching output in the previous stage
2025-02-19 21:08:44Z WARNING: LLGLSLShader::createShader: Failed to map uniforms for: Windlight Sun program
2025-02-19 21:08:44Z WARNING: LLGLSLShader::createShader: Failed to link using shader level 2 trying again using shader level 1
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 1 - File: windlight/sunDiscV.glsl
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 1 - File: windlight/sunDiscF.glsl
While this shader does not make any use of vertex_color (and is the same for PBR, and for EE level 1 shader which does compile fine)... This could be the sign of a bogus OpenGL driver version.

And:
Code:
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 2 - File: deferred/terrainV.glsl
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 2 - File: deferred/terrainF.glsl
2025-02-19 21:09:17Z WARNING: LLShaderMgr::linkProgramObject: GLSL linker error:
2025-02-19 21:09:17Z WARNING: LLShaderMgr::dumpObjectLog: error: unresolved reference to function `getPositionEye'
2025-02-19 21:09:17Z WARNING: LLGLSLShader::createShader: Failed to map uniforms for: Deferred terrain underwater shader
2025-02-19 21:09:17Z WARNING: LLGLSLShader::createShader: Failed to link using shader level 2 trying again using shader level 1
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 1 - File: deferred/terrainV.glsl
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 1 - File: deferred/terrainF.glsl
2025-02-19 21:09:17Z WARNING: LLShaderMgr::linkProgramObject: GLSL linker error:
2025-02-19 21:09:17Z WARNING: LLShaderMgr::dumpObjectLog: error: unresolved reference to function `getPositionEye'
While getPositionEye() is indeed defined, since it is part of the basic shaders (windlight/atmosphericsVarsWaterV.glsl) and the log does report a success loading them earlier:
Code:
2025-02-19 21:09:16Z INFO: LLViewerShaderMgr::loadBasicShaders: Basic shaders loaded.


The above hints for either a bogus OpenGL driver, or some unsuitable debug setting ("RenderShaderLightingMaxLevel", maybe, which should be 3 ?).

To allow a proper diagnosis/resolution, proceed as follow:
  • Uninstall the viewer entirely (making sure the installation directory is fully removed) and reinstall it; this would fix missing, extraneous (from old install), corrupted or unreadable shader files.
  • Move away all ~/.secondlife/user_settings/settings_coolvlviewer_*.xml files: this would fix bogus settings, or settings picked up from old installs.
  • Launch the viewer and see if it works. If it still does not work, try adding VARYING vec4 vertex_color; to app_settings/shaders/ee/class1/deferred/sunDiscV.glsl and app_settings/shaders/ee/class1/windlight/sunDiscV.glsl, to read:
    Code:
    ATTRIBUTE vec3 position;
    ATTRIBUTE vec2 texcoord0;

    VARYING vec4 vertex_color;
    VARYING vec2 vary_texcoord0;
    VARYING float sun_fade;
  • Try again to toggle ALM on, and see if it solves the first issue (i.e. if the warning about windlight/sunDiscV.glsl is not happening any more).
  • If ALM still fails, restart the viewer in forward rendering mode, log in, check the "ShaderLoading" box in the floater opened via "Advanced" -> "Consoles" -> "Debug tags", toggle ALM on, log off, and post the log here.


2025-02-20 11:53:04
Profile WWW

Joined: 2018-12-09 20:51:20
Posts: 8
Reply with quote
Thank you for the reply and the housekeeping in moving my post to the appropriate topic. I was unsure which to post in and chose incorrectly. I apologize.

Henri Beauchamp wrote:
Can you at all use ALM on your system with other non-PBR viewers (e.g. with Firestorm v6.6) ?


Firestorm v6.6.17 did indeed use ALM as expected. Shadows and materials were rendered as I expected them to be.

Henri Beauchamp wrote:
There are strange shader compilation errors in your logs, that should not happen:
Code:
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 2 - File: windlight/sunDiscV.glsl
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 2 - File: windlight/sunDiscF.glsl
2025-02-19 21:08:44Z WARNING: LLShaderMgr::linkProgramObject: GLSL linker error:
2025-02-19 21:08:44Z WARNING: LLShaderMgr::dumpObjectLog: error: fragment shader input `vertex_color' has no matching output in the previous stage
2025-02-19 21:08:44Z WARNING: LLGLSLShader::createShader: Failed to map uniforms for: Windlight Sun program
2025-02-19 21:08:44Z WARNING: LLGLSLShader::createShader: Failed to link using shader level 2 trying again using shader level 1
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 1 - File: windlight/sunDiscV.glsl
2025-02-19 21:08:44Z INFO: LLGLSLShader::createShader: Creating shader: Windlight Sun program - Level: 1 - File: windlight/sunDiscF.glsl
While this shader does not make any use of vertex_color (and is the same for PBR, and for EE level 1 shader which does compile fine)... This could be the sign of a bogus OpenGL driver version.

And:
Code:
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 2 - File: deferred/terrainV.glsl
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 2 - File: deferred/terrainF.glsl
2025-02-19 21:09:17Z WARNING: LLShaderMgr::linkProgramObject: GLSL linker error:
2025-02-19 21:09:17Z WARNING: LLShaderMgr::dumpObjectLog: error: unresolved reference to function `getPositionEye'
2025-02-19 21:09:17Z WARNING: LLGLSLShader::createShader: Failed to map uniforms for: Deferred terrain underwater shader
2025-02-19 21:09:17Z WARNING: LLGLSLShader::createShader: Failed to link using shader level 2 trying again using shader level 1
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 1 - File: deferred/terrainV.glsl
2025-02-19 21:09:17Z INFO: LLGLSLShader::createShader: Creating shader: Deferred terrain underwater shader - Level: 1 - File: deferred/terrainF.glsl
2025-02-19 21:09:17Z WARNING: LLShaderMgr::linkProgramObject: GLSL linker error:
2025-02-19 21:09:17Z WARNING: LLShaderMgr::dumpObjectLog: error: unresolved reference to function `getPositionEye'
While getPositionEye() is indeed defined, since it is part of the basic shaders (windlight/atmosphericsVarsWaterV.glsl) and the log does report a success loading them earlier:
Code:
2025-02-19 21:09:16Z INFO: LLViewerShaderMgr::loadBasicShaders: Basic shaders loaded.


The above hints for either a bogus OpenGL driver, or some unsuitable debug setting ("RenderShaderLightingMaxLevel", maybe, which should be 3 ?).


Indeed, "RenderShaderLightingMaxLevel" was set to a "3". As to the "bogus OpenGL driver" it is Mesa 24.3.3 running in an X11 native environment courtesy of the OpenMadriva Rome distribution. I have no knowledge as to how they package these software bits and drivers up; whether they use strict upstream or make modifications to code or compiler settings per their policies and objectives.

Henri Beauchamp wrote:
To allow a proper diagnosis/resolution, proceed as follow:
  • Uninstall the viewer entirely (making sure the installation directory is fully removed) and reinstall it; this would fix missing, extraneous (from old install), corrupted or unreadable shader files.
  • Move away all ~/.secondlife/user_settings/settings_coolvlviewer_*.xml files: this would fix bogus settings, or settings picked up from old installs.
  • Launch the viewer and see if it works. If it still does not work, try adding VARYING vec4 vertex_color; to app_settings/shaders/ee/class1/deferred/sunDiscV.glsl and app_settings/shaders/ee/class1/windlight/sunDiscV.glsl, to read:
    Code:
    ATTRIBUTE vec3 position;
    ATTRIBUTE vec2 texcoord0;

    VARYING vec4 vertex_color;
    VARYING vec2 vary_texcoord0;
    VARYING float sun_fade;
  • Try again to toggle ALM on, and see if it solves the first issue (i.e. if the warning about windlight/sunDiscV.glsl is not happening any more).
  • If ALM still fails, restart the viewer in forward rendering mode, log in, check the "ShaderLoading" box in the floater opened via "Advanced" -> "Consoles" -> "Debug tags", toggle ALM on, log off, and post the log here.


Per your suggested diagnosis:
  • The installation was a first-time reinstallation but for sake of completeness was purged as requested. So to was the .installjammer directory as well. Reinstallation via the Setup package was done.
  • The entire .secondlife directory was purged as Cool VL Viewer is the only viewer using it.
  • Launched the viewer, saw that ALM was not working, logged off the viewer and captured this "1st Run" log to the ZIP archive attached.
  • Made the suggested edits to the two files indicated and restarted the viewer. The viewer's window came up split between solid black half and solid white half. The window controls (close, maximize, minimize, etc.) were non-responsive so a sig15 termination was sent to the executable via CLI. Apparently behind the frozen window the viewer was running so the "vec4" log is attached in its own ZIP archive.
  • Backed out the vec4 edits, restarted the viewer, and captured the Shader Loading, as requested. I am having difficulty attaching that ZIP file as the compressed archive is 90KiB, exceeding this fora's limit of 64KiB. Am attempting to find another means of super-squashing that log into a smaller size (suggestions on how are welcomed).

If I were to suppose this is all due to how OpenMandriva packages up X11/Mesa, what would a suitable distribution be? I tried using Ubuntu 24.04 LTS but its Mesa was almost obsoleted before that distro went live. I did install the official AMD Radeon software but it, too, uses a customized version of Mesa. They no more include their own OpenGL drivers. Also, I could not get Cool VL Viewer to run at all on Ubuntu for it kept crashing right away after execution (I do not have files or logs from those terminated attempts).

Thanks again for your response.


Attachments:
About_CoolVLViewer_ShaderLoadDebugRun.zip [1.15 KiB]
Downloaded 91 times
CoolVLViewer_vec4Edits_sig15Terminate.zip [11.71 KiB]
Downloaded 105 times
CoolVLViewer_1stBoot_ShaderErrorsPresent.zip [54.98 KiB]
Downloaded 109 times
2025-02-20 18:17:23
Profile

Joined: 2018-12-09 20:51:20
Posts: 8
Reply with quote
Follow up post to my recent reply. I was able to get the archive file for the ShaderLoad run smaller and attached:


Attachments:
CoolVLViewer_ShaderLoadDebug.log.bz2 [58.58 KiB]
Downloaded 105 times
2025-02-20 18:46:19
Profile

Joined: 2009-03-17 18:42:51
Posts: 6019
Reply with quote
I sent you a PM with a link to a beta version of the viewer. Try it and report if it works for you or not. If it does not, please post the log you get with "ShadersLoading" enabled.

As for Ubuntu 24 crashes, I'd bet it's because you started the viewer under a Wayland session (Ubuntu 24 is very hostile towards X11 and must be specially configured to use it)...


2025-02-20 20:30:22
Profile WWW

Joined: 2018-12-09 20:51:20
Posts: 8
Reply with quote
Thank you for the response. :)

Henri Beauchamp wrote:
I sent you a PM with a link to a beta version of the viewer. Try it and report if it works for you or not. If it does not, please post the log you get with "ShadersLoading" enabled.


I performed a clean install (removing previous version and moving aside the user settings XML) but the results were the same. The archived log with ShadersLoading is attached.

At this point I can use the viewer in either forward rendering or PBR mode. Not having ALM is not a deal-breaker as both of the other rendering processes work for what I need them to do: PBR to show all the shiny and forward rendering when dealing with a lot of avatars in one place. Unless others are having problems with this I do not mind if it becomes more of a curiosity... a mystery to be explored. I can still use the viewer, as is.


Attachments:
CoolVLViewer.log.bz2 [55.89 KiB]
Downloaded 87 times
2025-02-20 21:43:51
Profile

Joined: 2009-03-17 18:42:51
Posts: 6019
Reply with quote
The log shows that the underwater terrain shader now compiles fine for you.

There is another error, but I might have found a way to fix it. Will send you a PM with another test viewer, please have a try with it and report/provide log in the same way.


2025-02-20 21:57:46
Profile WWW

Joined: 2018-12-09 20:51:20
Posts: 8
Reply with quote
Henri Beauchamp wrote:
The log shows that the underwater terrain shader now compiles fine for you.

There is another error, but I might have found a way to fix it. Will send you a PM with another test viewer, please have a try with it and report/provide log in the same way.


Thank you Henri, it worked! ALM enables and remains enabled over the course of a relog. Thank you!

Because I can not help myself at this point, I have attached a ShaderLoading log archive showing the results of going from forward rendering to ALM. Let me know if there is more you wish me to test but for my original issue, ALM is working. :)


Attachments:
CoolVLViewer.zip [47.64 KiB]
Downloaded 111 times
2025-02-21 04:54:58
Profile

Joined: 2009-03-17 18:42:51
Posts: 6019
Reply with quote
DilliDallagio wrote:
Thank you Henri, it worked! ALM enables and remains enabled over the course of a relog. Thank you!
Well, glad it did. What I find amazing is that no one encountered this issue so far.

FYI it stems from a (wrong, obviously) optimization I backported now well over a year ago from Alchemy (it was in the pre-PBR era), and which "broke silently" (1) these shaders with most GPUs/drivers combinations (meaning ALM still works just fine with them), but appears truly broken with yours.

Anyway, this bug is fixed for Saturday's release.

DilliDallagio wrote:
Because I can not help myself at this point, I have attached a ShaderLoading log archive showing the results of going from forward rendering to ALM. Let me know if there is more you wish me to test but for my original issue, ALM is working. :)
There is still the vertex_color issue with the "Windlight Sun program" at level 2, but this one is most likely a driver (Mesa) bug (2), and since the program still compiles at level 1, it does not prevent you from enjoying ALM anyway...


(1) Not truly broken: they still work, likely because most shader compilers silently reuse already compiled functions, instead of reporting an error, when a new shader is compiled and the utility shader defining this function is not explicitly linked to it.
(2) A false positive error detection in the shader compiler: Mesa is likely being too zealous and flagging an error when an utility shader (a library of utility functions) is linked to a program and one of its library functions, not used by the program, lacks a variable declaration. This is exactly what the second error ("unresolved reference to function `getAdditiveColor') was about in beta1. Yet, I could not find what that vertex_color reference comes from (i.e. which utility shader would use it without defining it).


2025-02-21 08:34:37
Profile WWW

Joined: 2018-12-09 20:51:20
Posts: 8
Reply with quote
Again, thank you for the time you put into correcting this.

Given the linux kernel, all of the supporting OS software libraries and utilities, and device drivers and firmware are in a constant ebb and flow of design philosophies and builds, which allow those creating distributions to fit their design needs and use cases, it must be a challenge for application developers who would like to see their creations work across as many of those distributions as possible. Combined with all the possible ways users and hardware designers mix and match device combinations, it is truly amazing to me that applications even come close to working at the level they do in the general linux desktop worlds.

Thank you for your drive and persistence in making your application, the Cool VL Viewer, work as well as it does. :)


2025-02-21 17:21:37
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 12 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest


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.