Feature #1127

Provide users with an easy way to downgrade to --noshaders

Added by Joel Palmius almost 2 years ago. Updated over 1 year ago.

Status:Fix exists, needs testingStart date:02/16/2017
Priority:HighDue date:
Assignee:Joel Palmius% Done:

0%

Category:OpenGL
Target version:MakeHuman 1.1.2

Description

It should be possible to default to a lower common denominator when the user starts MH on a machine with a crappy graphics card.

This would save us a lot of support effort.


Related issues

Related to MakeHuman - Bug #1054: Ubuntu 16.04 and mesa drivers Fix exists, needs testing 09/02/2016
Related to MakeHuman - Bug #154: Investigate and fix rendering issues with intel graphics ... Accepted 02/25/2014
Related to Python 3 - Bug #1170: Opengl issues on Windows in MakeHuman for Python3 New 04/25/2017

History

#1 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #1054: Ubuntu 16.04 and mesa drivers added

#2 Updated by Joel Palmius almost 2 years ago

  • Related to Bug #154: Investigate and fix rendering issues with intel graphics on windows added

#3 Updated by Jonas Hauquier almost 2 years ago

This has even been dropped by game producers in the time when gfx cards announced opengl features while they actually didnt support them.
Doing this would require maintaining an extensive list of all available graphics cards and probably driver combinations, practically infeasable.

#4 Updated by Joel Palmius almost 2 years ago

I was thinking more along the lines of a simple if/else. Does the manufacturer name contain the word "intel"? Default to --noshaders and inform the user with a message box and tell him how to change it.

#5 Updated by Rob Baer almost 2 years ago

It may well be true that Intel cards have given the greatest number of problems, but I have machines with Intel cards that have worked just fine with shaders. Worse, the machine that was the source of my Ubuntu 16.04 shader issue report has only an Intel card, but if I boot that very same machine into Windows the shaders work fine. The problems are typically a combination of hardware age and driver installed.

#6 Updated by Aranuvir # almost 2 years ago

GL.VENDOR:    X.Org
GL.RENDERER:  Gallium 0.4 on AMD PITCAIRN (DRM 2.48.0 / 4.9.0-1-amd64, LLVM 3.9.1)
GL.VERSION:   3.0 Mesa 13.0.4                                                                                                                   
GLSL.VERSION: 1.30                                                                                                                                                    
GL.EXTENSION: GL_ARB_multisample enabled (4x samples)

Still getting the same result as with an Intel iGPU. The simpler solution would be directly default to --noshaders.

#7 Updated by wolgade (Forum User) almost 2 years ago

Is it (technically) possible to switch to -noshaders while MH is running or is this something that has to be done before the graphics stuff gets initialized? Most users aren't familiar with a terminal, but some of them might be able to click a button.

#8 Updated by Rob Baer almost 2 years ago

Ignoring Wolgade's question because I don't know the answer off the top of my head, I'd like to suggest as an alternative that we include a "disable shaders check box" for settings.ini. This could over-ride the absence of a --noshaders command line switch for any user that needs to regularly disable shaders but works from a GUI. Checking such a is well within the capability of even GUI-based users.

At worst it would require a single restart (like switching languages) and should be relatively straight forward to implement. It should minimize inconvenience for users with incompatible graphics cards.

I would leave the box unchecked by default so that the user gets the shader benefit by default.

#9 Updated by Joel Palmius almost 2 years ago

  • Subject changed from Automatically downgrade to --noshaders on chips which are known to be problematic to Provide users with an easy way to downgrade to --noshaders

At the very least we could:

  • Provide a checkbox under settings for whether to always use --noshaders (even if a restart is needed)
  • Pop up an informative message box on first run telling users where to find this checkbox if things look odd

#10 Updated by Jonas Hauquier almost 2 years ago

Joel Palmius wrote:

  • Pop up an informative message box on first run telling users where to find this checkbox if things look odd

The pop up boxes at first run were problematic, and annoying. I'd rather not go back there.
A FAQ that addresses this problem should be enough.

Yes, the option can be added to the settings. It was added as commandline option as a fix for when MH crashes on startup. Not having access to the settings gui because MH crashes, which you need to be able to change a setting to prevent MH from crashing was kind of a chicken-or-egg problem, hence the commandline option.

#11 Updated by Jonas Hauquier almost 2 years ago

But what would really be better, is to spend that time on finally fixing these sodding out-of-spec OpenGL calls, so that MH can be enjoyed with proper shading by everyone.
At this time, there shouldn't be much hardware (or drivers, for that matter) around that is not capable of rendering MH's OpenGL 1.2 shaders.

I think by now those machines not capable of rendering MH's shaders are displayed in musea.

#12 Updated by Rob Baer almost 2 years ago

Delete double post

#13 Updated by Rob Baer almost 2 years ago

Don't know if this gives us any clue, but here is where I'm getting a startup failure of py3 master branch on the Ubuntu 16.04 side (Intel mesa)

Loading material from file data/skins/default.mhmat
Shader: adding built-in uniform b'gl_ModelViewProjectionMatrixTranspose'
Shader: adding built-in uniform b'gl_NormalMatrix'
Exception during event onStart
Traceback (most recent call last):
File "./core/events3d.py", line 211, in callEvent
method(event)
File "./core/mhmain.py", line 807, in onStart
self.startupSequence()
File "./core/mhmain.py", line 729, in startupSequence
self.loadHuman()
File "./core/mhmain.py", line 384, in loadHuman
self.selectedHuman = self.addObject(human.Human(files3d.loadMesh(mh.getSysDataPath("3dobjs/base.obj"), maxFaces = 5)))
File "./apps/human.py", line 82, in init
self.material = material.fromFile(getSysDataPath('skins/default.mhmat'))
File "./shared/material.py", line 1372, in fromFile
mat.fromFile(filename)
File "./shared/material.py", line 476, in fromFile
self.configureShading(diffuse=shaderConfig_diffuse, bump=shaderConfig_bump, normal=shaderConfig_normal, displacement=shaderConfig_displacement, spec=shaderConfig_spec, vertexColors=shaderConfig_vertexColors, transparency=shaderConfig_transparency, ambientOcclusion=shaderConfig_ambientOcclusion)
File "./shared/material.py", line 913, in configureShading
self._updateShaderConfig()
File "./shared/material.py", line 950, in _updateShaderConfig
bump = self._shaderConfig['bump'] and self.supportsBump()
File "./shared/material.py", line 845, in supportsBump
if self.shaderObj and result:
File "./shared/material.py", line 1010, in shaderObj
return self.getShaderObj()
File "./shared/material.py", line 1006, in getShaderObj
return shader.getShader(shaderPath, self.shaderDefines)
File "./lib/shader.py", line 522, in getShader
shader = Shader(path, defines)
File "./lib/shader.py", line 313, in init
self.initShader()
File "./lib/shader.py", line 440, in initShader
self.updateUniforms()
File "./lib/shader.py", line 462, in updateUniforms
for uniform in self.getUniforms():
File "./lib/shader.py", line 456, in getUniforms
uniform.update(self.shaderId)
File "./lib/shader.py", line 137, in update
self.glquery(pgm, self.index, values)
File "/home/rwbaer/anaconda3/envs/python34/lib/python3.4/site-packages/OpenGL/platform/baseplatform.py", line 402, in call
return self( *args, **named )
File "/home/rwbaer/anaconda3/envs/python34/lib/python3.4/site-packages/OpenGL/error.py", line 232, in glCheckError
baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1282,
description = b'invalid operation',
baseOperation = glGetUniformfv,
cArguments = (1, 3, array([ 0.], dtype=float32))
)

#14 Updated by Jonas Hauquier almost 2 years ago

Needs to be checked in opengl spec/reference manual.
Perhaps glGetUniformfv before setting/declaring it?

#15 Updated by Jonas Hauquier almost 2 years ago

So the OpenGL error is:
INVALID_OPERATION in glGetUniformfv()

Might contain the solution:
http://www.alecjacobson.com/weblog/?p=2203

Another possibility, perhaps the uniform index, passed to that function needs to be checked for correctness (defensive handling of errors).

#16 Updated by Jonas Hauquier almost 2 years ago

This call in lib/shader.py is failing, which is trying to obtain the current values of one of the uniforms passed to the shader.

self.glquery(pgm, self.index, values)

Reasons why this could fail are many: the uniform is somehow not declared/set yet, the program (shader) pointer is invalid (perhaps the shader failed to compile? or uniforms were compiled out of the shader due to optimization?).

From the docs: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetUniformLocation.xhtml

GL_INVALID_OPERATION is generated if program is not a program object.
GL_INVALID_OPERATION is generated if program has not been successfully linked.

Perhaps program correctness can be validated first? Using glIsProgram() or glCheckProgram()

First it might be worth checking what uniform exactly (its name) it is trying to access, who knows it might be one of the builtins and perhaps it does not allow read access to those?
In other words: check the value of variable "name" in the line

uniform.update(self.shaderId)

in lib/shader.py getUniforms()
Perhaps check if any errors were returned by glLinkProgram() or glCreateProgram()?

#17 Updated by Jonas Hauquier almost 2 years ago

We know this is happening for a VectorUniform (line number of update()), and from the cArguments reported by the GLError we know it's probably a single value scalar (array([ 0.], dtype=float32))

Obviously, we need to fix something in update() of VectorUniform, the question is whether we can just catch that error and assume some default value (like 0?) or whether we need to do some gl check even before we attempt the query.
I hope this error does not mean that some opengl implementations do not allow you getting the default value declared for a uniform in the shader code, as that was a nice feature... (in that case we'll probably need some custom parsing step of the shader code, as we're already doing for #ifdefs). But need more information first.

#18 Updated by Rob Baer almost 2 years ago

Here's a stackoverflow I read last night that advocates always doing checks, and contains some additional admonitions about openGL version differences. Mostly the advice is beyond my level of current understanding.

#19 Updated by Aranuvir # over 1 year ago

  • Related to Bug #1170: Opengl issues on Windows in MakeHuman for Python3 added

#20 Updated by Aranuvir # over 1 year ago

  • Status changed from New to Fix exists, needs testing

I think this is not necessary any more.

Also available in: Atom