glutViewer crashes/segfaults when switching to GLSL kernel

[andrewkww]

Some people are having crashes/segfaults when switching to GLSL kernel. These crashes were mentioned in #68, and they happened in Windows. I was also able to reproduce a similar crash on Linux with a NVIDIA card. I'll try to take a look at the crash that I'm having. Perhaps it'll shed some light on the crashes that others are experiencing on Windows.

[andrewkww]

Well, I think I've found out what my issue is. The GLSL code uses subroutine, which my driver/card doesn't support unfortunately. And instead of reporting error, GL crashes on glLinkProgram. The shader's compile status didn't even report an error. There was a warning, however, in the info log:

warning C7568: #version 400 not fully supported on current GPU target profile

Also, glGet on both GL_MAX_SUBROUTINES and GL_MAX_SUBROUTINE_UNIFORM_LOCATIONS return 0.

Other people who are having the crash should probably check if their cards/drivers support the GLSL code. Perhaps one simple way for others to check is to run the glewinfo that comes with GLEW. On my card, it reports that the extension itself is missing. So it's not supported, even though the functions do exist. The relevant snippet from my glewinfo is:

GL_ARB_shader_subroutine:                                      OK [MISSING]
-------------------------
  glGetActiveSubroutineName:                                   OK
  glGetActiveSubroutineUniformName:                            OK
  glGetActiveSubroutineUniformiv:                              OK
  glGetProgramStageiv:                                         OK
  glGetSubroutineIndex:                                        OK
  glGetSubroutineUniformLocation:                              OK
  glGetUniformSubroutineuiv:                                   OK
  glUniformSubroutinesuiv:                                     OK

[andrewkww]

Here's a patch to print out some errors if the user tries to use GLSL kernel on a system that doesn't support shader subroutine: andrewkww@9263a7a8835947d759901507ad7ece1da6f76fe8

[drakeguan]

I'm wondering if we can make use of cmake cooped with glewinfo or something similar to solve this issue. The current FindGLEW can't handle this.

[andrewkww]

Even if the host machine doesn't support GLSL, as long as the dependencies are present, I think it could still be useful to compile with GLSL. For example, that allows us to compile on one machine that may not have GLSL support, but still be able to run the binaries on another machine that does have proper GLSL support.

[manuelk]

This is being worked on : we are refactoring the code to compartmentalize dependencies (in anticipation of DX11 support). Many of the API dependency problems should be much improved with the next release in a few weeks.

[manuelk]

R.C. 1.0 release now separates the libraries into CPU / GPU modules so dependencies are kept separate. Please let us know if the latest version does not resolve these issues.