[Development] QOpenGLContext::currentContext()->functions()->glCreateShader(GL_VERTEX_SHADER) returns 0

[Agocs Laszlo]

Do "set QT_LOGGING_RULES=qt.qpa.gl=true" in the command prompt before launching the app. Then check the debug output with DebugView. During application startup a bunch of lines starting with qt.qpa.gl: ... will be printed. This will tell you which OpenGL implementation is in use. Alternatively, if using Creator, set the environment variable under the Run settings. The logs will then show up in the Application Output tab.


Real OpenGL is not an option since you will be left with OpenGL 1.1. ANGLE should work, as long as Direct3D is functional over RDP in your setup. You might want to try with some Qt examples first. For example try the Qt Quick examples under qtdeclarative/examples/quick. These all require OpenGL 2.0.


BR,

Laszlo



________________________________
From: development-bounces+laszlo.agocs=theqtcompany.com at qt-project.org <development-bounces+laszlo.agocs=theqtcompany.com at qt-project.org> on behalf of Dov Grobgeld <dov.grobgeld at gmail.com>
Sent: Saturday, January 24, 2015 5:34 PM
To: development at qt-project.org
Subject: [Development] QOpenGLContext::currentContext()->functions()->glCreateShader(GL_VERTEX_SHADER) returns 0

I'm trying to write a cross platform OpenGL application. It is currently working both on Linux and on Windows when I'm working at the actual computer, but it fails when trying to run the application under the remote desktop rdp protocol from Windows to Linux. I traced down the failure to the fact that:

QOpenGLContext::currentContext()->functions()
  ->glCreateShader(GL_VERTEX_SHADER)

returns 0, which indicates that the current context was not able to create a shader. But according to the blog entry at:

http://blog.qt.digia.com/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/

the following fallback chain should fallback all the way to a software renderer if no OpenGL or DirectX (through ANGLE) is supported:


  1.  Try opengl32 and check if OpenGL 2.0 functions are available.
  2.  If this fails, try ANGLE.
  3.  If initialization fails either due to missing ANGLE libraries or some other reason, try opengl32sw.dll. In practice this will be a software rasterizer based implementation. To make it easy to get started, a pre-built version of Mesa llvmpipe<http://www.mesa3d.org/llvmpipe.html> is bundled with the binary packages of Qt 5.4.

I tried the above program with both the OpenGL and the non-open gl prebuild Qt-5.4 binary packages, but returned 0 under the remote desktop.

Am I mistaken to assume that an OpenGL program will work (albeit slow!) under remote desktop? If not how can I trace down the failure?

The above blog entry also discusses logging for tracing failures. But there is no explanation for where this logging is collected, how it is read, and interpreted.

Thankful for any help, as it will save me the need to physically access a windows machine for my Qt OpenGL development!

Regards,

Dov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150124/59b83073/attachment.html>