Shader errors when displaying meshes and some volumes

[GoogleCodeExporter]

I just got a new laptop with a hybrid graphics card that I don't really 
understand yet.  So this could be a problem with the card or the driver and not 
visvis.  Anyway:

When I try to plot a mesh (vv.solidTeapot(), for example), the mesh does not 
appear.  Instead I get the error message:

Error compiling shading code: 0:29(36): error: Could not implicitly convert 
operands to relational operator
0:29(18): error: cannot construct `float' from a non-numeric data type

While the mesh is invisible, it does eclipse the rear lines of the axes, so 
something is there.  Unsurprisingly, the first commit to display this problem 
is ab7b8bd0e68b (Made lighting for 3D textures and meshes the same).

volshow() works, so shaders seem to work with this card.  However, if I run 
examples/volumeRenderStyles.py, only the 'mip' and 'ray' styles work.  The 
following errors are also produced:

Error compiling shading code: 0:60(36): error: Could not implicitly convert 
operands to relational operator
0:60(18): error: cannot construct `float' from a non-numeric data type

Error linking shading code: FS compile failed: no register to spill

Error compiling shading code: 0:58(36): error: Could not implicitly convert 
operands to relational operator
0:58(18): error: cannot construct `float' from a non-numeric data type

I'm hoping this means something to you.

openGlVersion.py gives me:
version:     2.1 Mesa 7.11
vendor:      Tungsten Graphics, Inc
renderer:    Mesa DRI Intel(R) Sandybridge Mobile 
extensions:  139 different extensions

The graphics card, from lspci, is
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09)

Original issue reported on code.google.com by rschr...@gmail.com on 12 Jan 2012 at 2:04

[GoogleCodeExporter]

I suspect there is a bug in the shader code, very likely in the lighting 
calculations. There is probably some conversion that the compiler from NVidia 
thinks is ok, but Mesa's think it's not.

With m the mesh, try m.faceShader.fragment.ShowCode(). This will print the 
source code of the shader currently in use. (This stuff needs to be better 
documented in the future.)

Anyway, I tried that and quickly found that this is the problem:
float Nselect = float(dot(N,V) > 0);

I suspect the "0" should be a "0.0". This code is defined on line 112 of 
core/shaders_m.py.

Please let me know whether this fixes your problem!

Original comment by almar.klein@gmail.com on 12 Jan 2012 at 2:27

• Changed state: Started
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Oh, and if this does not help, you can disable the custom shader for meshes by 
using:
m.useNativeShading = True
which will revert to the default OpenGl render pipleline.

Original comment by almar.klein@gmail.com on 12 Jan 2012 at 2:42

[GoogleCodeExporter]

That solves the problem with the meshes.  It appears that Mesa isn't as 
generous with implicit coercion.  I've pushed a fix for this and two 
related problems.

However, I haven't been able to fix the display of the 'edgeray', 
'litray', and 'iso' volume rendering methods.  For each of them, I get 
the error "Error linking shading code: FS compile failed: no register to 
spill", which fails to enlighten me.  In the 'edgeray' method, the 
problem seems to be in the calculation of the normal vector N from the 
colors.  If I put a fake N in by hand, it works (or rather, doesn't 
fail).  But any attempt to use color1 or color2 to assemble N results in 
this error.  In the other two, the problem is somewhere in 
calculateColor(), which seems to be doing similar type things.

Perhaps this is a bug in Mesa....

Original comment by rschr...@gmail.com on 13 Jan 2012 at 2:28

[GoogleCodeExporter]

Oh, I realized now that the bug that you fixed is also in shaders_3.py on line 
548. Still weird that the shown error is so different...

Original comment by almar.klein@gmail.com on 13 Jan 2012 at 9:27

[GoogleCodeExporter]

I saw you submitted a patch. Can we mark this one as fixed?

Original comment by almar.klein@gmail.com on 19 Jan 2012 at 11:29

[GoogleCodeExporter]

I'm afraid my previous comment was confusing.  The problems I describe 
in it exist *after* the application of that revision.  What I don't know 
is if these problems are in visvis or in Mesa.  If you think it's the 
latter, go ahead and close this bug.  Otherwise, please leave it open 
while I play around with it.

Original comment by rschr...@gmail.com on 20 Jan 2012 at 1:57

[GoogleCodeExporter]

Looking at http://en.wikipedia.org/wiki/Register_allocation it seems that 
register spilling has something to do with assigning variables in (fast) 
registers. 

As far as I can tell, this is either a bug (of Mesa), or the shader code 
program is simply too large (uses too many variables?) to run on your hardware. 
In the latter case, the compiler could have given a more useful error message 
though ...

Here's an idea to make the code of edgeray a bit more compact with only a small 
difference in behavior: comment all lines that do something with 'betterColor', 
including line 345. Could you try and see what that does?

Original comment by almar.klein@gmail.com on 20 Jan 2012 at 9:02

[GoogleCodeExporter]

No luck, I'm afraid.  I've noticed that if I change lines 332, 336, and 
340 to "N[{1,2,3}] = 0.5;", it links correctly.  So my initial thought 
is that this isn't a memory issue.  But bizarrely enough, if I comment 
out line 345, I can switch one (and only one) of lines {332, 336, 340} 
back to the length(...) definition.  Commenting out additional 
betterColor lines doesn't let me switch any additional lines back to 
length(...).  This all seems incredibly capricious.

I'm willing to write this off as a problem with the Mesa drivers.  (This 
thread reached that conclusion for a similar error message: 
https://forum.vis.ethz.ch/showthread.php?14991-GLSL-for-loop-condition-Only-allo
wed-if-result-is-known-at-compile-time) 
  I wonder if visvis can handle the error more gracefully, reverting to 
a known-good shader if the linking fails.  If this sounds reasonable to 
you, I'll take a stab at implementing it.

Original comment by rschr...@gmail.com on 20 Jan 2012 at 1:35

[GoogleCodeExporter]

It's no surprise that commenting additional betterColor lines does not help; if 
line 345 is commented, the compiler probably knows it does not need the other 
lines. Similarly, changing one of {332,336,340} to N[{1,2,3}] = 0.5 means that 
the two lines above do not have to be performed, which is quite substantial 
because it has a texture lookup.

The issue described in the link is different I think. I know about that 
limitation (I have a machine with an ATI card that had it). This is one of the 
reasons that the number of lights is specified "hard-coded" instead of via a 
uniform.

But anyway, I think that this is either a memory issue which Mesa reports in a 
bad way, or a bug in the mesa driver caused by complex/large code.

I was looking for your suggestion to handle such error more gracefully and 
ended up implementing it myself. The shader now suggests using a different 
renderstyle (only for 3D textures) and the Texture3D reverts to MIP (and 
telling the user that it does).

Original comment by almar.klein@gmail.com on 21 Jan 2012 at 1:32

[GoogleCodeExporter]

Your explanations for the shader behavior are certainly plausible.  That link 
was obviously a different problem; I just wanted to point out that it was also 
diagnosed as a compiler problem.

The new behavior looks great, thanks!  If I ever figure out how to use the 
discrete half of my graphics system, I'll let you know if how it works.

Original comment by rschr...@gmail.com on 21 Jan 2012 at 4:00

• Changed state: Verified