I have managed to build a set of mesa libraries that together with a dummy xserver can run an OpenGL application on a machine with no GPU using openswr without relinking or changing any code in the application on a machine with a pre-existing Xorg installation. I'm using Linux on x64 (centos 7 to be specific)
The mesa build instructions I used are the following:
http://openswr.org/build-linux.html
Now I'm trying to set up a build process for this for machines without XOrg installed to start with for various reasons I won't go into detail on. Since there are some back and forth dependencies between the XOrg build process and mesa it becomes a dance involving building the right XOrg and mesa modules with the right parameters.
I have reached a point where I'm stuck.
It seems like mesa won't build gallium if dri is enabled. I.E if I remove the line --disable-dri from the mesa configure command line from the openswr example it won't work giving the following error.
:configure: error: Xlib-based (Gallium) GLX cannot be built with DRI
enabled
On the Xorg side, using a mesa without dri, building xserver with the --disable-dri flag, the configure script works but the build fails with the following error:
glxdriswrast.c:39:10: fatal error: GL/internal/dri_interface.h: No
such file or directory #include
(suggesting there are parts of xserver still referring to dri headers even if disabling it using --disable-dri).
Anyone have any idea what the right combination of flags to get all of this working? I'm not married to using openswr, llvmpipe is probably good enough for me in case it makes things easier.
Related
I am currently working on a simple c++ OpenGL project on both linux and macos, I have read a ton of guides on Opengl rendering for beginners and on every single guide I have read it's been clearly explained that I NEED Glew (or glad, or glut, etc.) to make sure gl functions are loaded.
However after correctly displaying triangles using OpenGL, I completely removed GLEW from my project and compilation and everything still worked just as fine on both Ubuntu 20.04 and MacOS high sierra,
what am I missing here?
I compile using -lGL -lglfw on linux and pkg-config --libs glfw3 -framework OpenGL on macos
My only includes are <GLFW/glfw3.h> and <GLES3/gl3.h>
My program is running OpenGL version: 4.5 (Core Profile) Mesa 21.2.6
Am I doing something wrong?
Is glfw loading my gl functions?
Am i missing functionalities?
Is GLEW not actually needed for simple OpenGL applications?
I keep reading on running opengl without glew and all I can find are people explaining how manually loading opengl functions is possible but long, tedious, useless and borderline blasphemous, I did not have to do that and yet everything is working fine.
Why ?
Thank you.
I am running Qt 5.4.2 on a Tegra 3 with a Yocto compiled Angstrom image. Unfortunately the Tegra only has proprietary drivers and they are forcing me to use X11 for hardware acceleration. I therefore had to build Qt with XCB instead of EGLFS.
My problem is that I am seeing tearing on some QML 2 animations on the device that are not visible on my PC. I am wondering if there is anything I can do to try and get rid of this tearing? I have read that QT_QPA_EGLFS_FORCEVSYNC might help but unfortunately I can't use EGLFS and doubt if it will be of any use.
EDIT:
I have noticed that "QSGContext::initialize: stencil buffer support missing, expect rendering errors" as well as "Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable." come up when the application is started. Could they be related to the problem?
Running any of the "Sample" projects that come with MonoGame will result in "MonoGameGLException". This occurs in the Texture2D constructor at the following code..
GL.CompressedTexImage2D(TextureTarget.Texture2D, 0, glInternalFormat,
this.width, this.height, 0,
imageSize, IntPtr.Zero);
GraphicsExtensions.CheckGLError(); <-- Error here
The value for "glInternalFormat" is:
OpenTK.Graphics.OpenGL.PixelInternalFormat.CompressedRgbaS3tcDxt3Ext
This occurs on Ubuntu Linux running on an Intel integrated graphics card.
TL;DR
This is an error that is caused because the OpenGL implementation (Mesa) does not contain support for the internal texture format (S3TC). Install the libtxc_dxtn library to add this functionality to Mesa.
The Problem
OpenGL is the graphics API that MonoGame uses to render graphics. Since OpenGL is just an API, you need some implementation of that API in order to have it work on your system. If you had an NVIDIA or ATI card, you could download their proprietary drivers (which include closed-source implementations of the OpenGL API). If you are not using their proprietary drivers (or are using a card like Intel graphics card that has open source drivers), then you are probably running Mesa, which is an open-source implementation of the OpenGL API standard.
OpenGL has a base standard, but it also has many extensions. One of these extensions is EXT_texture_compression_s3tc. This is an extension that allows the user to specify that the textures we are loading into the graphics card should be compressed using a specific algorithm of the S3TC family of algorithms. That is what the "GL.CompressedTexImage2D" line actually does: it requests that we make room for a texture that will be compressed using the DXT3 algorithm.
Mesa does not implement ALL of the OpenGL API and list of extensions. Specifically, they do not implement the S3TC extension (due to legal reasons).
"Invalid Enum" is the error that Mesa is throwing because you are trying to tell Mesa to use an extension (as specified by the enumerated value PixelInternalFormat.CompressedRgbaS3tcDxt3Ext) that Mesa does not support. This is the standard way an OpenGL implementation tells you that you are referring to an unsupported value.
The Solution
So, there are two options to fix this:
First, workaround MonoGame so that it stops using S3TC. This might require changing MonoGame code, or perhaps there is a better way using the ContentPipeline to specify what texture compression algorithm to use.
Second, install the S3TC algorithm. While Mesa does not include S3TC by default, you can include an external library for Mesa. More details on the Mesa Wiki S3TC page. Mesa needed to be built with a specific compiler flag, and then the library needs to be installed. In my Ubuntu install (12.04), I'm assuming that the Mesa package did have this flag enabled when compiling, since installing the library worked well. In Ubuntu, I installed the libtxc-dxtn-s2tc0 package.
sudo apt-get install libtxc-dxtn-s2tc0
After that, all the MonoGame samples were working.
I was using powervr sdk gles 2 libs in linux in gamekit/ogre for building an application. I get the error
"dlopen tries:libGL.so" after which application crashes.
I tried debugging using DDD etc but couldnt isolate much.
How do I fix this in linux(Ubuntu 10.10)?
Does linux refer to some default in built libs while running dlopen?
A library name like libGL.so is only used for linking at compile time. When run-time linking, you should be using the SONAME; something like libGL.so.1. If that library has any dependencies, they must also be available. Try running 'ldd /path/to/libGL.so.1' and see if there are any missing libraries. Also, make sure that you're pointing to the correct libGL; there could be a few versions on your system, each optimized for different graphics cards.
I have a ARM11 based hardware board which runs a Linux kernel ver. 2.6.21.5-cfs-v19. I have my application running on this ARM-LINUX board. To do source level debugging, of my application I used to use gdb from command prompt of the linux board, that was with some earlier version of the board linux version.
With this version 2.6.21.5-cfs-v19, I dont have a related version of gdb for the board. I tried to look around to get gdb for this version of linux and arm port of it, but without much success. Can anyone point me where I can get either an independant executable for gdb for above mentioned os and board configuration or source for the same, which I may try compiling for that target.
-AD.
Sometime ago I published an article about cross-target debugging with GDB and GDBServer. The target processor there is PPC7450, but it's rather detailed, so maybe you'll find it useful.
You might have some luck using OpenEmbedded. If there's no precompiled version you can use right away, setting up an OE-cross compile environment is not that hard.
Another option could be to install gdb-server on the board, like described in this blogpost.