I am trying to compile a simple game using SDL2 and OpenGL under Cygwin. When I ran the program, I found that the GPU usage is unusually high. Then I found that VSync was not enabled for the program. More specifically, SDL_GL_SetSwapInterval(1) returned neither 0 (success) nor -1 (failed), but an undocumented value 5. SDL_GetError() returns glXSwapIntervalMESA failed. Any idea on how to fix this?
Update: I tried to call glXSwapIntervalMESA directly, and found that it returned GLX_BAD_CONTEXT. Now it seems that the only way to force VSync is through the display driver settings.
Cygwin/X forces you to operate through an X11 server that runs on top of Windows GDI. The capabilities of that X11 server are very limited and not every optional feature in the book is supported.
If you don't need the parts of X11 other than GLX, then drop it and access the graphics system directly. The same goes for Cygwin and POSIX functions.
I.e. use MinGW to compile your program without Cygwin, and a SDL-2 build that uses the OS native functions for OpenGL context creation and management.
Related
I've installed Qt 5.12 , When i want to compile my project show this
errors:
Errors :
QOpenGLShaderProgram::uniformLocation(qt_Matrix): shader program is not linked
ensureInitialized(141): D3D compiler module not found.
QOpenGLShader::link: D3D compiler module not found.
shader compilation failed:
"D3D compiler module not found.\n"
Welcome to SO!
First of all, let's clarify what the error means.
Qt uses ANGLE on Windows, which is a layer that allows to run OpenGL software on systems where OpenGL is not available, by traslanting the OpenGL calls into DirectX calls. Qt decides whether to go with pure OpenGL or ANGLE depending on the configuration of the machine (video card model, video drivers version, etc).
More details on that are available at https://wiki.qt.io/Qt_5_on_Windows_ANGLE_and_OpenGL.
Even if you are not writing any OpenGL code yourself, the qml runtime surely has a lot of OpenGL calls that again, may go through ANGLE.
That is why the confusing error message (looking for the D3D shader compiler while dealing with OpenGL code!).
Now, the Qt project bugtracker reports the same issue you have https://bugreports.qt.io/browse/QTBUG-71510, although at the time of writing no solution has been provided. I would suggest to have a look at the bugtracker now and then to monitor the progress on this issue.
A couple of workarounds you may try:
Copy the d3dcompiler_xx.dll in the same directory where your exe is;
Force Qt to use OpenGL instead of DirectX, by setting the environment variable QT_OPENGL to desktop (more details on that are at http://doc.qt.io/qt-5/windows-requirements.html)
According to bugreports.qt this issue is now fixed from version QT 5.12.1.
https://bugreports.qt.io/browse/QTBUG-71510
I have the same issue on my older Del laptop. Placing d3dcompiler_43.dll in the exe folder does solve the issue. I found using one of the following commands also works, which I assume avoids ANGLE all together.
//To use pure OpenGL :
QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL);
//Or use software emulated OpenGL :
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
I just include the first pure OpenGL setting in the "int main(int argc, char *argv[])" bracket in main.cpp
I have just upgraded my project to use Qt 5.7, on Mac I am able to load the html pages using Qt Webengine but on Window 7, the pages are not displayed, instead a black screen is shown.
I have also compiled simple browser example and it too only shows a black screen.
I am using the visual studio 2013 build of Qt 5.7
Does anyone know why it is not displaying the pages.
Does Qt 5.7 need any third party libraries for it render correctly on Windows.
We had a similar problem, whenever we started an application with a QWebEngineView it would only show a black screen or even crash on another machine. The problems occured due to wrong versions of api-ms-*.dlls and d3dcompiler_47.dll we had packaged with our app.
We found the correct versions on our developer machine with installed Windows SDK under "C:\Program Files (x86)\Windows Kits\10\Redist".
On a side note: We found that deployement of QWebEngine under windows is quite a hassle.. you also need to include "qtwebengine_locales" from qtbase\translations and "resources" from qtbase as well as "QtWebEngineProcess.exe" from qtbase\bin.
A thing that helped tracking down the problem, was putting "CONFIG += console" in the pro-file. That way the console output with relevant error information is shown on deployement targets.
With help of this comment from peppe
One can use temporary workaround with graphic drivers not supporting DirectX11 but supporting DirectX9
As said here
https://doc.qt.io/qt-5/windows-requirements.html#dynamically-loading-graphics-drivers
Graphics Drivers
For Qt Quick 2 to work, a graphics driver that provides OpenGL 2.1 or higher is required. The default driver from Windows is OpenGL 1.1. Qt includes a version of the ANGLE project which is included from the Windows Qt installers. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 11 or DirectX 9. ANGLE requires that the DirectX SDK is installed when building Qt.
ANGLE chooses the render backend depending on availability. DirectX 11 is usually preferable. However, some graphics cards may not fully support it. For these cases, the environment variable QT_ANGLE_PLATFORM (introduced in Qt 5.4) can be used to control the render backend. Possible values are d3d11, d3d9 and warp.
So this may help
set QT_ANGLE_PLATFORM=d3d9
Or use mesa with
https://www.mesa3d.org/llvmpipe.html
Qt::AA_UseSoftwareOpenGL is special in the sense that it will try to load an OpenGL implementation with a non-standard name. The default name is opengl32sw.dll. This allows shipping a software-only OpenGL implementation, for example a build of Mesa with llvmpipe, under this name. If necessary, the filename can be overridden by setting the QT_OPENGL_DLL environment variable.
Edit 1:
One can use fallback method for one-time login to Dropbox Windows client ( made with QT framework ) for example
Dynamically Loading Graphics Drivers
In addition to the build time configuration, Qt supports choosing and loading the OpenGL implementation at runtime. To use this mode, pass -opengl dynamic to the configure script.
Note: As of Qt 5.5 this is the configuration used by the official, pre-built binary packages of Qt. It is strongly recommended to use it also in custom builds, especially for Qt binaries that are deployed alongside applications.
...
This configuration is the most flexible because no dependencies or assumptions are hardcoded about the OpenGL implementation during build time. It allows robust application deployment. When a given environment fails to provide a proper OpenGL 2.0 implementation, it will fall back automatically to ANGLE. This fallback will be completely transparent to the application, and will allow Qt Quick or other OpenGL code to function by translating to Direct3D. Such a fallback could, for example, take place on a Windows 7 PC with no additional graphics drivers installed. On other machines, where there is sufficient OpenGL support, the normal desktop OpenGL drivers will be used. Additionally, pure software-based OpenGL implementations may be available as additional fallbacks in the future, allowing running Qt Quick applications without a GPU.
When configured with -opengl dynamic, neither Qt nor the applications built using qmake will link to the opengl32 (standard desktop OpenGL) or QtANGLE libraries. Instead, the appropriate library is chosen at runtime. By default, Qt will determine whether the system's opengl32.dll provides OpenGL 2 functions. If these are present, opengl32.dll is used, otherwise the ANGLE libraries (libEGL.dll and libGLESv2.dll) will be used. In case the ANGLE libraries are missing or initialization fails for some reason, an additional fallback is attempted by trying to load opengl32sw.dll. See below for details.
Such a fallback could, for example, take place on a Windows 7 PC with
no additional graphics drivers installed.
To emulate this conditions one can use RDP session with mandatory 8 bpp to Windows machine
I am trying to debug an opengl error that i have and i decided to use Nvidia Linux Graphics Debugger. My laptop has Nvidia Optimus but i manged to fix everything to make things work with dGPU using Fedora 22.
I am new to Linux developing and I tend to use wrappers when it comes to doing something because I started developing the same project in windows and linux at the same time. I find it easyer for some small things to use windows compared to linux but I would like to more and stay there. :D
When i try to capture a frame with Linux Graphics Debugger I get this error.
Detected unsupported operations that may cause errors or a crash during capture.
First seen unsupported operation: glXCreatePbuffer
I did some googleing and i found out what is the operation. I get the same error with all applications that use OpengGl.
My problem is how to disable this. I am using SDL2 GLEW and FreeGlut.
I'm attempting to make a video game in Unreal Engine 4.9. I'm building it for Windows, but I'd like to have it use opengl instead of directx in the executable. However, I've found no options that let you do this. Unreal Engine uses OpenGL when it creates executables for Linux and Mac, but there seems to be no way to use OpenGL with Windows.
Am I missing something? Is there some way to force Unreal Engine to use OpenGL in Windows executables?
EDIT: The reason I want to use OpenGL is because I want this game to run without having to install anything on the end user's computer (DirectX has to be installed to work)
Microsoft doesn't really support OpenGL, they typically go out of their way to make it very difficult to use OpenGL on Windows and strongly encourage people to use DirectX instead.
The simplest way to get a working OpenGL context in windows is sometimes to use ANGLE which is a compatibility layer which translates OpenGL calls to DirectX calls. This is what Chrome and Firefox use to support WebGL on windows. I doubt that Unreal Engine is integrated with this, so you might have a hard time.
Edit:
EDIT: The reason I want to use OpenGL is because I want this game to run without having to install anything on the end user's computer (DirectX has to be installed to work)
One thing you could do is cross-compile the Mesa3D drivers, as described here: https://wiki.qt.io/Cross_compiling_Mesa_for_Windows
But then you won't get hardware acceleration.
I'm currently porting an open-source OpenGL game to OpenGL ES. The target device runs Linux and has a relatively weak CPU (ARM11 family, with FPU). It has an OpenGL ES accelerator but not an OpenGL one.
Initially I want to get the existing OpenGL-GLX-X11 implementation to run, using an accelerated OpenGL instance on another Linux machine - for example, an Athlon X2 with a Radeon X1650 Pro. This will help to verify that there are no serious CPU bottlenecks that need to be sorted out at a high level.
I have managed to set up SSH forwarding of the X11 connection. The glxinfo and glxgears programs run, but the latter has very poor performance (8fps) compared to a locally running glxgears (60fps with vsync). The glxinfo report stated that Direct Rendering is being used, which tells me that the local (to the ARM device) software renderer is being used.
What I want to happen is for OpenGL commands to be sent to the Athlon X2 machine and accelerated using the Radeon. I believe I need to turn on Indirect Rendering for this. However, setting LIBGL_ALWAYS_INDIRECT=1 does not change anything. For example:
arm$ LIBGL_ALWAYS_INDIRECT=1 glxinfo | fgrep rendering
direct rendering: Yes
arm$
The ARM device is running Gentoo Linux. What is the best way to force what I want to happen?
The glxinfo and glxgears programs run, but the latter has very poor performance (8fps) compared to a locally running glxgears (60fps with vsync). The glxinfo report stated that Direct Rendering is being used, which tells me that the local (to the ARM device) software renderer is being used.
I'm a bit puzzled by this. If you see the OpenGL output on the remote display, then this would mean that instead of GLX commands pictures are transmitted. This however would mean, that the libGL.so on your host device is X11 aware for its output, but won't use GLX.
Could you please determine which package contributes the libGL.so on your ARM device. I suggest you install a separate libGL.so with only GLX command generation and LD_PRELOAD that.
Mesa3D can be configured to build GLX command stream generator library.