GL_VERSION string and glxinfo version string don't agree? - c++

I'm trying to get a very basic openGL application up and running. I have a GTX 770, and i've installed nvidia-361 drivers. when i run glxinfo | grep version, i get:
OpenGL core profile version string: 4.5.0 NVIDIA 361.42
OpenGL core profile shading language version string: 4.5.0 NVIDIA
OpenGL version string: 4.5.0 NVIDIA
this would lead one to believe that your drivers supported OpenGL 4.5, right?
now, i'm using GLEW in my basic application. i get the version string and print it:
const GLubyte* version = glGetString(GL_VERSION);
printf("version: %s\n", version);
and when i run the program, i get:
version: 3.2.0 NVIDIA 361.42
?????????????????????????
what's happening here? i checked my version of libglew-dev, and it's 1.13.0. OpenGL 4.5 support was added in 1.11.0. so i don't think GLEW is the problem, but i can't figure out what's going on.

glGetString(GL_VERSION) returns the version the current GL context is providing, not necessarily the highest version your GL implementation is supporting.
GLEW has nothing to do with that, it just loads GL function pointers. Relevant is the way you created the context. What you see here is the normal behavior of the nvidia driver in recent versions: when you ask it for some GL x.y context, it does return version x.y, and not a higher version it would still support.
If you want a 4.5 context, just request a GL 4.5 context. How to do that depends on the way you create the context. If you use some libraries like GLFW, GLUT, SDL, Qt, ..., just consult the documentation on how to request a specific context version. If you manually create the context via glX, use glXCreateContextAttribsARB with proper GLX_CONTEXT_MAJOR_VERSION_ARB and GLX_CONTEXT_MINOR_VERSION_ARB attributes.

Related

OpenGL 3.3 vs 4.0 and Tessellation

From my understanding, modern OpenGL starts with version 3.3 which is mostly the same as 4.0. Both versions were released at the same time and 3.3 is just for back compatibility with older graphics cards. In my application I need to use tessellation control. All of the sources I have found online say tessellation starts with 4.0, but also say 3.3 is virtually the same.
Does OpenGL 3.3 have tessellation or not? Should I even bother with 3.3 in 2021 or should I just use the latest version 4.6? Is 4.6 compatible with mac?
Tessellation shaders are in the standard since OpenGL 4.0. However you can test if you hardware supports the ARB_tessellation_shader extension, which is written against the OpenGL 3.2.

New mesa installed but glxinfo show the older one

I am doing some work using Google Cloud Platform,that's to say I use ssh to login. When I run a script(mayavi/test_drawline.py) from others, it tells me:
ERROR: In /work/standalone-x64-build/VTKsource/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 797 vtkXOpenGLRenderWindow (0x3987b00): GL version 2.1 with the gpu_shader4 extension is not supported by your graphics driver but is required for the new OpenGL rendering backend. Please update your OpenGL driver. If you are using Mesa please make sure you have version 10.6.5 or later and make sure your driver in Mesa supports OpenGL 3.2.
So I think I need to up upgrade my mesa. Before that, the glxinfo shows:
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)
I followed the instruction from How to upgrade mesa, but the glxinfo didn't change.
And I tried to compile Mesa from source code. So I followed the instruction from Mesa official website Compiling and Installing. I use
Building with autoconf (Linux/Unix/X11). All things are OK, it seemed that I have installed the newest Mesa.
However, when I run glxinfo| grep version again, it still like this:
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 1.4 (2.1 Mesa 10.5.4)
I have tried reboot, but it doesn't work.
So, does anyone know how to solve it?
Thank you!
The OpenGL version reported depends on the available Mesa version only be second degree. You're reported GLX-1.4 and OpenGL-1.4 which is an absolute baseline version dating back over 15 years ago. So this is not a Mesa version problem.
What far more likely is, that you're trying to create a OpenGL context in a system configuration which simply can't do more than OpenGL-1.4 without resorting to software rendering. Now one reason for that could be, that you're connecting via SSH using X11 forwarding. In that case all OpenGL commands would be tunneled through the X11 connection (GLX) to your local machine and be executed there. However GLX is very limited in it's OpenGL version profile capabilities. Technically it's supporting up to OpenGL-2.1 (which is the last OpenGL version, that defines GLX transport opcodes for all its functions). But a given configuration might support less.
If the remote machine does have a GPU, you have to use that. A couple of years ago, this would have meant running a Xorg server there. Not anymore. With NVidia GPUs you can use headless EGL. With Intel and AMD GPUs you can also use headless EGL, or use GBM/DRI to create a headless GPU accelerated OpenGL context. Of course this requires a GPU being available on the remote end.
If you don't have a GPU on the remote site, you must use some software implementation. Which with Mesa unfortunately doesn't work with a forwarded X11 session. Your best bet would be running something like Xpra, or Xvnc (i.e. some kind of remote framebuffer), where the X server runs on the remote end, so that the GLX connection terminates there, and not on your local machine.
Or you somehow coax the program you're building to use OSMesa (Off-Screen Mesa), but that requires entirely different OpenGL context setup, entirely different from what's done with GLX, so your VTK application may not work out of the box with that.

xming 7.7.0.23 OpenGl version reported incorrectly

I'm trying to use xming to render software using OpenGl running on the same machine in WSL / windows bash.
This works fine for some really small demos, however once I try something like glmark2, it fails because it seems the OpenGl version is reported incorrectly.
glxinfo | grep OpenGL reports this:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 970M/PCIe/SSE2
OpenGL version string: 1.4 (4.5.0 NVIDIA 382.05)
If I let xming run on my internal graphics card (using a laptop), it reports
OpenGL vendor string: Intel
OpenGL renderer string: Intel(R) HD Graphics 4600
OpenGL version string: 1.4 (4.3.0 - Build 20.19.15.4568)
The weird part is the 1.4 in front of 4.5.0 NVIDIA 382.05.
The OpenGl support is definitely at least 3, because a demo using GLSL shaders which require newer OpenGl runs, but the version string is kinda garbage.
The problem you're running into is, that the GLX portion of XMing does support only up to OpenGL-1.4. The part inside the parentheses is the version string as reported by the system native OpenGL implementation. However since XMing lacks (so far) the capability to reliably pass on anything beyond OpenGL-1.4 it will simply tell you "all I guarantee you to support is OpenGL 1.4, but the system I'm running on could actually do …".
Maybe some day someone goes through the effort to implement a fully featured dynamic GLX←→WGL wrapper.

glxinfo vs. glewinfo interpretation

I have difficulties interpreting glxinfo and glewinfo.
glxinfo gives me this:
OpenGL version string: 3.0 Mesa 9.2.2
OpenGL shading language version string: 1.30
whereas glewinfo goes up to version 4.0:
GL_VERSION_4_0: OK
---------------
glBlendEquationSeparatei: OK
glBlendEquationi: OK
glBlendFuncSeparatei: OK
glBlendFunci: OK
glMinSampleShading: OK
I know that I cannot use GLSL newer than 1.30, but I'm wondering, is that a driver issue?
My GPU is
VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
I'm using Arch Linux and SDL, and have Mesa 9.2 and Mesa-libgl 9.2.2 installed.
When glewinfo reports certain functions being there, that just means it could retrieve a function pointer for them. However the function pointer being available does not tell, that the corresponding extension/version support being actually available. Since OpenGL follows a client server model, the client side interface may very well expose also newer functionality, while the server side doesn't support it.
The list of supported extensions and the reported version are the authorative information on that and you must rely on only those.

How can I check which Version of OpenGL is supported on a linux system with optirun?

I have had a lot of problems / confusion setting up my laptop to work for OpenGL programming / the running of OpenGL programs.
My laptop has one of these very clever (too clever for me) designs where the Intel CPU has a graphics processor on chip, and there is also a dedicated graphics card. Specifically, the CPU is a 3630QM, with "HD Graphics 4000" (a very exciting name, I am sure), and the "proper" Graphics Processor is a Nvidia GTX 670MX.
Theoretically, according to Wikipedia, the HD Graphics Chip (Intel), under Linux, supports OpenGL 3.1, if the correct drivers are installed. (They probably aren't.)
According to NVIDIA, the 670MX can support OpenGL 4.1, so ideally I would like to develop and execute on this GPU.
Do I have drivers installed to enable me to execute OpenGL 4.1 code on the NVIDIA GPU? Answer: Probably no, currently I use this "optirun" thing to execute OpenGL programs on the dedicated GPU. See this link to see the process I followed to setup my computer.
My question is, I know how to run a compiled program on the 670MX; that would be 'optirun ./programname', but how can I find out what OpenGL version the installed graphics drivers on my system will support? Running 'glxinfo | grep -i opengl' in a terminal tells me that the Intel Chip supports OpenGl version 3.0. See the below information:
ed#kubuntu1304-P151EMx:~$ glxinfo | grep -i opengl
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL version string: 3.0 Mesa 9.1.3
OpenGL shading language version string: 1.30
OpenGL extensions:
How do I do the same or similar thing to find out what support is available under 'optirun', and what version of OpenGL is supported?
Update
Someone suggested I use glGetString() to find this information: I am now completely confused!
Without optirun, the supported OpenGL version is '3.0 MESA 9.1.3', so version 3, which is what I expected. However, under optirun, the supported OpenGL version is '4.3.0 NVIDIA 313.30', so version 4.3?! How can it be Version 4.3 if the hardware specification from NVIDIA states only Version 4.1 is supported?
You can just run glxinfo under optirun:
optirun glxinfo | grep -i opengl
Both cards have different features, so its normal to get different OpenGL versions.