Welcome to Fractal Forums

Fractal Software => Fragmentarium => Topic started by: Patryk Kizny on July 10, 2015, 12:38:33 PM




Title: inverse OpenGL issue on OSX
Post by: Patryk Kizny on July 10, 2015, 12:38:33 PM
I'm trying to run Fragmentarium 1.0.7 build on an OSX. Runs nicely, but I have a problem getting my frags to work properly.
Particularly, I have the following problem:

In my code there is:

Code:
vec3 opTranslate(vec3 p, vec3 d){
mat4 m = translate(d);
vec4 p1 = inverse(m) * vec4(p.x, p.y, p.z,1.);
return p1.xyz;
}

vec3 opRotate(vec3 p, vec3 v, float angle){
mat4 m = rotationMatrix(normalize(v),angle);
vec3 p1 = inverse(m) * vec4(p.x, p.y, p.z,1.);
return p1.xyz;
}

According to OpenGL specs, matrix inverse is available starting from V4.
https://www.opengl.org/sdk/docs/man/html/inverse.xhtml

My system is a Mavericks OSX running on a late 2014 iMac Retina and AMD Radeon R9 M295X 4096 MB
In theory it supports OpenGL 4.1

Running tests confirms that:
https://www.dropbox.com/s/cfi7lu1pyv75wrg/Screenshot%202015-07-10%2012.05.20.png?dl=0

My frags won't compile due to use of inverse(m).
Code:
Could not create fragment shader: ERROR: 0:1505: Invalid call of undeclared identifier 'inverse'
ERROR: 0:1506: Use of undeclared identifier 'p1'
ERROR: 0:1511: Invalid call of undeclared identifier 'inverse'
ERROR: 0:1512: Use of undeclared identifier 'p1'

I suspected types mismatch and issues with vec4 vs vec3, but it does not seem to matter here.
The same code runs nicely on Win7 x64 / R9280X

Any ideas on what am I doing wrong or how to troubleshoot that?



Title: Re: inverse OpenGL issue on OSX
Post by: Syntopia on July 10, 2015, 02:28:06 PM
Per default the GLSL version is always 1.10. If you need higher, try to put something like "#version 140" as the very first line in the script. Notice, that this may trigger more warnings.
But on Mac OS X, I think you are actually stuck with OpenGL 2.1 (GLSL version 1.2), when running in core compatibility mode (which Fragmentarium is), see: https://developer.apple.com/opengl/capabilities/GLInfo_1090.html

However, in your case you shouldn't use 'inverse', which is very slow. A rotation matrix is orthogonal, which means its inverse equals its transposed.
Which means you can just multiply on the right hand side: vec3 p1 =  vec4(p.x, p.y, p.z,1.)*m;


Title: Re: inverse OpenGL issue on OSX
Post by: Patryk Kizny on July 10, 2015, 02:42:01 PM
Thanks,

- Can you give me slightly more insight into how "#version 140" relates to GLSL version and OpenGL version?
- An you shine some light on "running in core compatibility mode"?
- The doc you mentioned does not contain my GPU and I guess it is outdated. Both Apple specs and a test app report I should have 4.1 avail.

Thanks for the note on inverse being slow. Any guides on how to learn what is slow and how to optimize the code? Or there's no other way than years of experience?




Title: Re: inverse OpenGL issue on OSX
Post by: Syntopia on July 10, 2015, 03:21:24 PM
- Can you give me slightly more insight into how "#version 140" relates to GLSL version and OpenGL version?
This table will show you the mapping: https://en.wikipedia.org/wiki/OpenGL_Shading_Language#Versions

Quote
- An you shine some light on "running in core compatibility mode"?
- The doc you mentioned does not contain my GPU and I guess it is outdated. Both Apple specs and a test app report I should have 4.1 avail.

The OpenGL standard uses a concept called OpenGL contexts. These contexts defines what OpenGL features are available. Fragmentarium use some older features (such as immediate mode rendering, glBegin(...) and glEnd(...)), which means it needs a compatibility context. Nearly all OpenGL driver vendors supply compatibility mode for all of their contexts. However, Apple is an exception. Here you either get a
- Core profile, typically with OpenGL 4.1 features, or
- A compatibility profile (which they call 'legacy') with OpenGL 2.1 (GLSL 1.2) features.

So when running Fragmentarium on a Mac, I think you have only access to OpenGL 2.1 features.

Quote
Thanks for the note on inverse being slow. Any guides on how to learn what is slow and how to optimize the code? Or there's no other way than years of experience?

Calculating the inverse of a general 4x4 matrix is surely costly, since it will use a lot of instructions. Other than that, optimizing GLSL is difficult, and the best strategy is just to try different versions.


Title: Re: inverse OpenGL issue on OSX
Post by: Patryk Kizny on July 10, 2015, 03:34:56 PM
Huge thanks for all your help!


Title: Re: inverse OpenGL issue on OSX
Post by: 3dickulus on July 11, 2015, 01:45:34 AM
wrt the files from my website...
the nV version I supply is for GL 4.1 and uses the class as in...
Code:
class DisplayWidget : public QGLWidget, protected QOpenGLFunctions_4_1_Core {
the other one is "Legacy"? and is like...
Code:
class DisplayWidget : public QGLWidget, protected QOpenGLFunctions {

the nV one is specifically for newer nVidia cards, enables GLSL Asm dump, while the other should work on any GL capable card, the nV version should also work on newer cards but if nVidia is not detected it will not enable the (GLSL Asm dump) menu item. that's the only real difference between the two exe files, re: the OSX 1.0.7 from visual.bermarte I am not sure if he made both versions or enabled the nV feature, if so, it may have trouble with GL stuff < 4.1 as it's using 4_1_Core instead of 4_1_Compatibility. I will ask visual.bermarte if he can compile both for v1.0.8, coming soon I hope.:)