OpenSubdiv
OpenSubdiv copied to clipboard
PixarAnimationStudios
glViewer 'Failed to open window'
OS - archlinux 64-bit glfw-3.0.4-2 , glew-1.11.0-1 opensubdiv compiled successfully
bin git:master ❯ sudo lshw -short | grep -i --color display
/0/100/1/0 display GK107M [GeForce GT 755M]
/0/100/2 display 4th Gen Core Processor Integrated Graphics Controller
bin git:master ❯ ldd glViewer
linux-vdso.so.1 (0x00007fffb7ffc000)
libpng16.so.16 => /usr/lib64/lib64/libpng16.so.16 (0x00007f23b954b000)
libz.so.1 => /usr/lib64/lib64/libz.so.1 (0x00007f23b9335000)
libosdCPU.so.3.0.0.alpha => /home/robo/github/opensubdiv/build/lib/libosdCPU.so.3.0.0.alpha (0x00007f23b9043000)
libosdGPU.so.3.0.0.alpha => /home/robo/github/opensubdiv/build/lib/libosdGPU.so.3.0.0.alpha (0x00007f23b8dff000)
libGLU.so.1 => /usr/lib64/lib64/libGLU.so.1 (0x00007f23b8b7e000)
libGL.so.1 => /usr/lib64/lib64/libGL.so.1 (0x00007f23b890e000)
libSM.so.6 => /usr/lib64/lib64/libSM.so.6 (0x00007f23b8706000)
libICE.so.6 => /usr/lib64/lib64/libICE.so.6 (0x00007f23b84e9000)
libX11.so.6 => /usr/lib64/lib64/libX11.so.6 (0x00007f23b81a7000)
libXext.so.6 => /usr/lib64/lib64/libXext.so.6 (0x00007f23b7f95000)
libglfw.so.3 => /usr/lib64/lib64/libglfw.so.3 (0x00007f23b7d82000)
libXrandr.so.2 => /usr/lib64/lib64/libXrandr.so.2 (0x00007f23b7b78000)
libXxf86vm.so.1 => /usr/lib64/lib64/libXxf86vm.so.1 (0x00007f23b7972000)
libXcursor.so.1 => /usr/lib64/lib64/libXcursor.so.1 (0x00007f23b7767000)
librt.so.1 => /usr/lib64/lib64/librt.so.1 (0x00007f23b755f000)
libGLEW.so.1.11 => /usr/lib64/lib64/libGLEW.so.1.11 (0x00007f23b72ce000)
libgomp.so.1 => /usr/lib64/lib64/libgomp.so.1 (0x00007f23b70b8000)
libstdc++.so.6 => /usr/lib64/lib64/libstdc++.so.6 (0x00007f23b6da9000)
libm.so.6 => /usr/lib64/lib64/libm.so.6 (0x00007f23b6aa4000)
libgcc_s.so.1 => /usr/lib64/lib64/libgcc_s.so.1 (0x00007f23b688e000)
libpthread.so.0 => /usr/lib64/lib64/libpthread.so.0 (0x00007f23b6672000)
libc.so.6 => /usr/lib64/lib64/libc.so.6 (0x00007f23b62cf000)
libglapi.so.0 => /usr/lib64/lib64/libglapi.so.0 (0x00007f23b60a6000)
libXdamage.so.1 => /usr/lib64/lib64/libXdamage.so.1 (0x00007f23b5ea3000)
libXfixes.so.3 => /usr/lib64/lib64/libXfixes.so.3 (0x00007f23b5c9d000)
libX11-xcb.so.1 => /usr/lib64/lib64/libX11-xcb.so.1 (0x00007f23b5a9b000)
libxcb-glx.so.0 => /usr/lib64/lib64/libxcb-glx.so.0 (0x00007f23b5881000)
libxcb-dri2.so.0 => /usr/lib64/lib64/libxcb-dri2.so.0 (0x00007f23b567c000)
libxcb-dri3.so.0 => /usr/lib64/lib64/libxcb-dri3.so.0 (0x00007f23b5479000)
libxcb-present.so.0 => /usr/lib64/lib64/libxcb-present.so.0 (0x00007f23b5276000)
libxcb-randr.so.0 => /usr/lib64/lib64/libxcb-randr.so.0 (0x00007f23b5068000)
libxcb-xfixes.so.0 => /usr/lib64/lib64/libxcb-xfixes.so.0 (0x00007f23b4e60000)
libxcb-render.so.0 => /usr/lib64/lib64/libxcb-render.so.0 (0x00007f23b4c56000)
libxcb-shape.so.0 => /usr/lib64/lib64/libxcb-shape.so.0 (0x00007f23b4a52000)
libxcb-sync.so.1 => /usr/lib64/lib64/libxcb-sync.so.1 (0x00007f23b484b000)
libxcb.so.1 => /usr/lib64/lib64/libxcb.so.1 (0x00007f23b4629000)
libxshmfence.so.1 => /usr/lib64/lib64/libxshmfence.so.1 (0x00007f23b4426000)
libdrm.so.2 => /usr/lib64/lib64/libdrm.so.2 (0x00007f23b4219000)
libdl.so.2 => /usr/lib64/lib64/libdl.so.2 (0x00007f23b4015000)
libuuid.so.1 => /usr/lib64/lib64/libuuid.so.1 (0x00007f23b3e10000)
libXi.so.6 => /usr/lib64/lib64/libXi.so.6 (0x00007f23b3bff000)
libXrender.so.1 => /usr/lib64/lib64/libXrender.so.1 (0x00007f23b39f5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f23b9781000)
libXau.so.6 => /usr/lib64/lib64/libXau.so.6 (0x00007f23b37f1000)
libXdmcp.so.6 => /usr/lib64/lib64/libXdmcp.so.6 (0x00007f23b35eb000)
bin git:master ❯ glViewer ⏎
Failed to open window.
am i missing something ?
Nothing obvious jumps at me.
I'll have to borrow a MacBook to test the build. Can you try checking out the dev branch and see if it bails the same way too ?
We have had problems in the past with GL core profile on OSX (sometimes our fault, sometimes because of the drivers). There is some #ifdef logic in the glViewer code that could be bad (although i don't recall any recent changes) - you can try playing with that to see if it solves the problem (or at least opens a window...)
Yup even the dev branch bails out the same way.. I will try looking into the glViewer code
I came across similar problem on both OS X and Linux where the hardware is not very recent.
On OS X, depending on the driver version, GLSL shader requires and extra "\n". There was a pull request but you can see the working version diff here https://github.com/nyue/OpenSubdiv/commit/7348f9f278836824cf20359d7021bf34a6c29bbd
On Linux, again depending on hardware capability of the GPU, you may need to change the hard coded value in setGLCoreProfile() because if those are not matching, GLFW will fail to create the window too.
The above are the changes I needed to make, YMMV.
Let us know if it works for you too.
Cheers
The GPU is a Kepler gen and GLFW bailing usually happens when it tries to initialize the GL context, usually because of the GL_CORE_PROFILE hints that we pass (logic below).
Try switching GL version to 4.1.0 and see if you can get a window.
static void
setGLCoreProfile()
{
#define glfwOpenWindowHint glfwWindowHint
#define GLFW_OPENGL_VERSION_MAJOR GLFW_CONTEXT_VERSION_MAJOR
#define GLFW_OPENGL_VERSION_MINOR GLFW_CONTEXT_VERSION_MINOR
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
#if not defined(__APPLE__)
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 4);
#ifdef OPENSUBDIV_HAS_GLSL_COMPUTE
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 3);
#else
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 2);
#endif
#else
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 2);
#endif
glfwOpenWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
}
@manuelk and @nyue thanks for the tip but this is what i changed based on my glfw version but still on the same error, am i doing it correctly ?
static void
setGLCoreProfile()
{
#define glfwOpenWindowHint glfwWindowHint
#define GLFW_OPENGL_VERSION_MAJOR GLFW_CONTEXT_VERSION_MAJOR
#define GLFW_OPENGL_VERSION_MINOR GLFW_CONTEXT_VERSION_MINOR
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
#if not defined(__APPLE__)
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3);
#ifdef OPENSUBDIV_HAS_GLSL_COMPUTE
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 0);
#else
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 0);
#endif
#else
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 0);
#endif
glfwOpenWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
``
Does Archlinux have glxinfo ? You might want to compare the values from glxinfo output to be certain e.g. on my CentOS box I am typing this message, I get
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro FX 4600/PCIe/SSE2
OpenGL version string: 3.3.0 NVIDIA 331.38
Look for the OpenGL version string
Cheers
yup it does
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.8
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 10.2.8
OpenGL shading language version string: 1.30
Hi Deepak,
Lowest shader version supported is 1.50 I am afraid.
Manuel, am I correct ?
Cheers
i think this may be a hint of what the real problem might be: you really don't want to get through MESA (which is antique), but the NVidia/Apple GL driver instead. Do you have MacPorts & MESA installed by any chance ? Something that might be useful would be to paste your cmake config command as well as the ensuing spewage when running cmake. If you followed the docs instructions (http://graphics.pixar.com/opensubdiv/docs/cmake_build.html) you should be using the following path to point CMake to where GL is (and prevent it from finding MESA elsewhere):
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Headers
The other problem i can think of is GLEW point to the wrong place too: you might want to build your own, and make sure it links against Apple's GL framerwork instead of MESA.
I am switching to OS X Yosemite (same old hardware MacBook GeForce 9400M) and retesting.
Please make sure that you pull the latest code from the git 'dev' branch - also please paste the result of the cmake configuration so i can see where GL is being detected.
I did a git checkout -b dev which seems to be the same as master, anyway, I build both the master and dev
My limited testing are generally positive as in, they all have no problem opening window :-)
glEvalLimit : Runs fine glFVarViewer : Runs fine glViewer : Runs sluggishly and kind of take over the machine (possibly GPU/heavy OpenGL) glShareTopology : Runs sluggishly and kind of take over the machine (possibly GPU/heavy OpenGL) vtrViewer : Opens window but I don't see any object being display (the HUD is there) but I also get some GLSL error Error compiling GLSL shader: ERROR: 0:61: ';' : syntax error: syntax error
OS X Yosemite 10.10 MacBook (13-inch, Aluminum, Late 2008) GeForce 9400M 256MB
Hi sorry for freezing this issue, i have moved away from arch and trying get this running on windows 7(x64) machine. here is my cmake config
NO_DOC:BOOL=1
TBB_tbbmalloc_proxy_LIBRARY:FILEPATH=TBB_tbbmalloc_proxy_LIBRARY-NOTFOUND
CUDA_HOST_COMPILER:FILEPATH=$(VCInstallDir)bin
NO_TBB:BOOL=1
CUDA_SDK_ROOT_DIR:PATH=CUDA_SDK_ROOT_DIR-NOTFOUND
NO_OPENCL:BOOL=1
GLFW_LOCATION:BOOL=0
CMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/OpenSubdiv
GLEW_LIBRARY:FILEPATH=GLEW_LIBRARY-NOTFOUND
TBB_tbb_debug_LIBRARY:FILEPATH=TBB_tbb_debug_LIBRARY-NOTFOUND
CUDA_TOOLKIT_ROOT_DIR:PATH=CUDA_TOOLKIT_ROOT_DIR-NOTFOUND
NO_PTEX:BOOL=1
GLEW_INCLUDE_DIR:PATH=D:/glew-1.11.0/include
DXSDK_d3d11_LIBRARY:FILEPATH=C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)/Lib/x86/d3d11.lib
CLEW_LIBRARY:FILEPATH=CLEW_LIBRARY-NOTFOUND
TBB_tbbmalloc_debug_LIBRARY:FILEPATH=TBB_tbbmalloc_debug_LIBRARY-NOTFOUND
OPENCL_LIBRARIES:FILEPATH=OPENCL_LIBRARIES-NOTFOUND
TBB_tbb_preview_debug_LIBRARY:FILEPATH=TBB_tbb_preview_debug_LIBRARY-NOTFOUND
NO_MAYA:BOOL=1
TBB_tbb_LIBRARY:FILEPATH=TBB_tbb_LIBRARY-NOTFOUND
CLEW_INCLUDE_DIR:PATH=CLEW_INCLUDE_DIR-NOTFOUND
GLEW_LOCATION:STRING=D:/glew-1.11.0
NO_REGRESSION:BOOL=1
NO_OMP:BOOL=1
NO_EXAMPLES:BOOL=0
TBB_tbb_preview_LIBRARY:FILEPATH=TBB_tbb_preview_LIBRARY-NOTFOUND
CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo
_OPENCL_CPP_INCLUDE_DIRS:PATH=_OPENCL_CPP_INCLUDE_DIRS-NOTFOUND
NO_LIB:BOOL=1
NO_CUDA:BOOL=1
TBB_tbbmalloc_proxy_debug_LIBRARY:FILEPATH=TBB_tbbmalloc_proxy_debug_LIBRARY-NOTFOUND
NO_CLEW:BOOL=0
NO_TUTORIALS:BOOL=1
TBB_tbbmalloc_LIBRARY:FILEPATH=TBB_tbbmalloc_LIBRARY-NOTFOUND
NO_OPENGL:BOOL=0
and here is the output
Compiling OpenSubdiv version v3_0_0_alpha
Using cmake version 2.8.12.2
Could NOT find GLFW (missing: GLFW_LIBRARIES) (found suitable version "3.0.4", minimum required is "3.0.0")
CMake Error at C:/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
Could NOT find GLEW (missing: GLEW_LIBRARY)
Call Stack (most recent call first):
C:/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
cmake/FindGLEW.cmake:120 (find_package_handle_standard_args)
CMakeLists.txt:339 (find_package)
Configuring incomplete, errors occurred!
i have specified the path to GLEW as mentioned in the readme , can you point out were i am going wrong? thanks
Sorry - this fell a bit through the cracks. Looking at the config & spewage, cmake is having issues locating the library dependencies for both GLFW and GLEW. The headers are found, but not the libs / dlls.
Assuming you just grabbed the GLEW binary and unzipped the file, this should be working (i just updated my Win7 tinderbox to Glew 1.11.0 and FindGLEW.cmake had no problem configuring given the correct GLEW_LOCATION).
The same problem seems to be happening for GLFW, but i don't really know why. This is somewhat hard to debug without having access to your setup (particularly where the files are on your hard drives and where cmake goes wrong...). You can try tracking down the problem by adding message() commands to cmake/FindGLEW.cmake and cmake/FindGLFW.cmake (that's what i am usually doing...).
To be safe, i usually recommend wiping the entire build directory, which includes cmake caches, and reconfigure from scratch instead (which is why the cmake GUI is a pain because you have to re-enter everything by hand...). It is easy to get in a bad state because cmake often only does partial re-discovery when reconfiguring. We highly recommend working with cygwin and using a configuration script for cmake (like the ones we have posted in the documentation)...
Hello everyone. Past weeks I tried to run the aforementioned code on my old equipped with a radeon hd4570 on windows 7 which supports up to opengl 3.3 according to the driver. However the glViewer would not start since by default the code is compiled to use opengl 4.3. I changed the major and minor versions to 3.3 and I got a window however I still did not get any graphics out of it. This was traced to the fact that my graphic card says it support ARB_tessellation_shaders but it is not actually implemented. So I started refactoring the glViewer code to use glew runtime calls instead of glew macros to query if the card supported the needed feature. This was done for the case of Linux and Windows leaving the apple part mostly intact. Also I implemented a couple of functions to query for the opengl version using glGetString(GL_SHADING_LANGUAGE_VERSION) in order to generate the correct shader version headers. This worked good for my laptop and my desktop whose graphics card is a geforce 560ti which support up to opengl 4.4. However this week when I did a git pull to get the latest changes the application stoppend showing the graphics and I got the following error in the application console: 0(407) : error C7548: 'layout(location)' requires "#extension GL_ARB_explicit_attrib_location : enable" before use 0(407) : error C0000: ... or #extension GL_ARB_separate_shader_objects : enable 0(407) : error C0000: ... or #version 330 this was caused because the function I created to get opengl version to use depends on the hinting given to glfw which I had set to: glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3); glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 2); However if I changed the values 3.3 the application showed again the graphics. So my question is how can I determine the highest opengl version to use which doesn't involve macros or I must set it as compile time constants.
Sorry about the delay, the work you are doing sounds great! It would be nice to isolate this type of logic so it can be shared -- perhaps in examples/common/glCommon.{h,cpp}.
I don't know that we need to know the greatest GL version, we just need a few well known fallbacks, right? What I mean is, we would like 4.4 then 4.3, then 4.1, then 3.2.
There is a GLEW function that takes a string argument (no macros), but it seems it seems OK to use macros in this way, no?
I actually had the same problem on my laptop where it only supports OpenGL 4.2 but the way we detect that is not great. I pull requested the fix I have for my laptop, which isn't at all what's fully needed but I decided to pull request it in case it'll help others who only have a machine with 4.2 drivers.
Thanks for working on a general solution to this.
Hello, thanks for your suggestions and feedback, I;ve made a pull request that I think will work on the general case, if anyone is kind to review it I'll be very grateful.
