Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Applications are now open to attend this year's Oculus Connect. Join us October 11–12 and be first in line for an inside look at what’s new and next for VR.
New To The Forum? Click Here To Read The How To Guide. -- Developers Click Here.
Linux SDK with mesa
haagch
Posts: 95
I understand that officially it's experimental and only tested with nvidia.
In fact it does not work with mesa and I am interested why.
Running stuff doesn't show much:
It's clear that this happens because some unsupported opengl functionality is used. But the files in LibOVR/Src/CAPI/GL/ aren't nice to read completely through and I haven't found this anywhere, so a quick question:
What opengl extensions are required to use the sdk and the demos?
Does anyone happen to know which of those are missing in mesa, maybe they can be implemented in a timely manner?
If it's known what the missing functionality is, can the SDK easily be patched for a temporary workaround (e.g. if it is some synchronization, just don't use it)?
In fact it does not work with mesa and I am interested why.
Running stuff doesn't show much:
./OculusWorldDemo_x86_64_Debug Debug: [NetClient] Connected to a server running version 1.1.0 (my version=1.1.0) Debug: GL_VERSION: 3.0 Mesa 10.4.0-devel (git-cfcd190) Debug: GL_VERSION: 3.0 Mesa 10.4.0-devel (git-cfcd190) X Error of failed request: GLXBadDrawable Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 29 (X_GLXGetDrawableAttributes) Serial number of failed request: 56 Current serial number in output stream: 56and looking at it in a debugger and reading some code still doesn't make it obvious what the actual problem is.
It's clear that this happens because some unsupported opengl functionality is used. But the files in LibOVR/Src/CAPI/GL/ aren't nice to read completely through and I haven't found this anywhere, so a quick question:
What opengl extensions are required to use the sdk and the demos?
Does anyone happen to know which of those are missing in mesa, maybe they can be implemented in a timely manner?
If it's known what the missing functionality is, can the SDK easily be patched for a temporary workaround (e.g. if it is some synchronization, just don't use it)?
0
Comments
X11 is asynchronous. You won't get a meaningful break point in the debugger unless you call XSynchronize(dpy, True); first. Some X apps have a special -sync commandline option for this.
The error however tells you exactly which GLX request failed (GetDrawableAttributes), which seems to be part of the GLX_SGIX_pbuffer extension (which as a quick grep shows is indeed used by the oculus SDK): https://www.opengl.org/registry/specs/SGIX/pbuffer.txt
However it doesn't look like a missing extension, but rather an invalid drawable being pased to the request.
webpage - blog - youtube channel
Somehow I didn't manage to google without the GLX prefix...
So you think it's just a mesa bug?
Not necessarily, but it's possible. Can't really tell without deeper examination, and my main development box has an nvidia GPU.
If you manage to break at the point of failure and examine the drawable being passed by the SDK, you might be able to tell if a correct drawable is passed by libovr or not.
webpage - blog - youtube channel
If I break on XError the program gets paused while there is a window frame with transparent content visible. using xwininfo -int on it shows:
xwininfo -int xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 31457282 "Oculus World Demo GL : Oculus Rift DK2" Absolute upper-left X: 0 Absolute upper-left Y: 429 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1100 Height: 618 Depth: 24 Visual: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x1e00001 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+429 -2740+429 -2740-33 +0-33 -geometry 1100x618+-3-30And the Window id: 31457282 is our drawable=31457282.
I don't know mesa and X well, I'm just reading code:
The error seems to happen here: http://cgit.freedesktop.org/mesa/mesa/tree/src/glx/glx_pbuffer.c#n370
but before that:
GetDrawableAttribute does pdraw = GetGLXDRIDrawable(dpy, drawable);
GetGLXDRIDrawable does struct glx_display *priv = __glXInitialize(dpy); and then if (__glxHashLookup(priv->drawHash, drawable, (void *) &pdraw) == 0) is true (0 means found) and pdraw is returned, so this is still working so far.
I can read a bit more code but someone who knows mesa and Xlib and knows where to look and when something looks bad, would probably have success much quicker.
You should probably try the proposed fix and see if it works.
webpage - blog - youtube channel
Reading the several threads about linux there seem to be a lot of issues with the opengl implementation in the SDK that should probably first get fixed...
The callback branch doesn't compile:
/home/chris/build/oculus-rift-sdk-jherico-git/src/OculusSDK/Samples/CommonSrc/Platform/Linux_Platform.cpp: In member function 'virtual ovrRenderAPIConfig OVR::Render::GL::Linux::RenderDevice::Get_ovrRenderAPIConfig() const': /home/chris/build/oculus-rift-sdk-jherico-git/src/OculusSDK/Samples/CommonSrc/Platform/Linux_Platform.cpp:952:13: error: 'ovrGLConfigData' has no member named 'Win' cfg.OGL.Win = Win; ^ /home/chris/build/oculus-rift-sdk-jherico-git/src/OculusSDK/Samples/CommonSrc/Platform/Linux_Platform.cpp:953:13: error: 'ovrGLConfigData' has no member named 'Disp' cfg.OGL.Disp = Disp; ^ Samples/CommonSrc/CMakeFiles/CommonSrc.dir/build.make:261: recipe for target 'Samples/CommonSrc/CMakeFiles/CommonSrc.dir/Platform/Linux_Platform.cpp.o' failedBut removing the two offending lines for now "fixes" that.The BadDrawable XError is gone, now I'm getting the real errors:
This is in the shader source code in LibOVR/Src/CAPI/GL/CAPI_GL_DistortionShaders.h.
I believe "_FS_IN vec4 gl_FragCoord;\n" can just be removed when it is "redeclared".
The textureSize2D function seems to be related to GL_EXT_gpu_shader4 so no surprise there.
It looks like mesa just doesn't have this... https://bugs.freedesktop.org/show_bug.cgi?id=70260#c2
The callback branch SDK samples don't compile. I don't really spend much time working with the Oculus samples as they're very Direct3D focused, and they spend too much effort maintaining state. This in turn masks bugs in the SDK where it does stuff like change state and not restore it. Basically I don't consider the SDK examples a sufficient test for 'this SDK is working' so I simply don't use them.
If you want to try out my callback approach, you can use my corresponding examples callback branch here: https://github.com/jherico/OculusRiftInAction/tree/callback
Co-author of Oculus Rift in Action
Anyway, when I make a release build of OculusRiftInAction/build/output/Example_2_4_HelloRift it just fails with
When I make a debug build it doesn't (wtf?).
The good news is: It opens a window and renders something without crashing. YAY.
http://imgur.com/Y10aRmE
First there is still the problem with OpenGL core contexts in GLEW I think:
Mesa: User error: GL_INVALID_ENUM in glGetString(GL_EXTENSIONS)
It's been an open bug for 4 years or so: http://sourceforge.net/p/glew/bugs/120/
The following problems could of course have been caused by the glew extension string not working.
Then I get
Mesa: User error: GL_INVALID_VALUE in glPixelStore(param)
caused by:
Then
Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
Then: Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2D
And lastly: Mesa: User error: GL_INVALID_OPERATION in glFramebufferRenderbuffer
Anyway, looks like progress is being made. Thanks for all that work you put into it.
This is a known issue.
I'll take a look at the other stuff when I have a chance, but basically it looks mostly like it's issues with my use of OpenGL, not the SDK's use, so that shouldn't be a blocker.
Co-author of Oculus Rift in Action
You should not remove them. They are just conditionally compiled, and you have to define OVR_OS_LINUX.
webpage - blog - youtube channel
The point is he's building my branch of the LibOVR project, which no longer defines Disp and Win in the OpenGL rendering config (regardless of OS). I've updated LibOVR, but not the samples, so the samples will not work at all.
Co-author of Oculus Rift in Action
@ void GlfwApp::onCreate() { // Initialize the OpenGL bindings // For some reason we have to set this experminetal flag to properly // init GLEW if we use a core context. - glewExperimental = GL_TRUE; + //glewExperimental = GL_TRUE; if (0 != glewInit()) { FAIL("Failed to initialize GLEW"); } + printf("Initialized OpenGL version: %s\n", glGetString(GL_VERSION)); glGetError(); #ifdef RIFT_DEBUG GL_CHECK_ERROR;printsInitialized OpenGL version: 3.3 (Core Profile) Mesa 10.4.0-devel (git-971dc2c)
But it segfaults:
So this is the segfault:
OculusRiftInAction/libraries/gl/GlFrameBuffer.h:35 is "glGenFramebuffers(1, &frameBuffer);"
(gdb) print glGenFramebuffers
$1 = {<text variable, no debug info>} 0x7ffff6aff980 <glGenFramebuffersEXT>
So it's not a null pointer. But it's a glGenFramebuffersEXT instead of glGenFramebuffers. Weird. I tried changing this, but it didn't change anything:
This was on intel.
On radeonsi it first segfaults in the same file in GL_CHECK_ERROR. Yes, segfault. Commenting it out results in the same segfault than above.
virtual ~FrameBuffer() { if (frameBuffer) { glDeleteFramebuffers(1, &frameBuffer); //GL_CHECK_ERROR; } }So first question: Is it normal that glGenFramebuffers is <glGenFramebuffersEXT>?