1

I'm trying to figure out my OpenGL version. I'm running a Fedora 29 vmware guest in win10 host. If I use software rendering (through Mesa), I get

$ LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVE=softpipe glxinfo | grep OpenGL OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.3.6 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.1 Mesa 18.3.6 OpenGL shading language version string: 1.40 OpenGL context flags: (none)

Why are two versions, 3.3 (core) and 3.1, reported? Is it because for 3.3 I can only get core compatibility and for 3.1 it can be either core or compatibility profile? But when I tested it with code (using freeglut) requesting for 3.3 (core or compatibility profile), I can only get 3.1. I've tested the code with softpipe and llvmpipe. Furthermore the profile returned in the code below is always 0.

glutInitContextVersion(3, 3); glutInitContextProfile(GLUT_CORE_PROFILE); std::cout << "OpenGL version: " << glGetString(GL_VERSION) << '\n'; std::cout << "GLSL version: " << glGetString(GL_SHADING_LANGUAGE_VERSION) << '\n'; int major = 0; int minor = 0; int profile = 0; glGetIntegerv(GL_MAJOR_VERSION, &major); glGetIntegerv(GL_MINOR_VERSION, &minor); glGetIntegerv(GL_CONTEXT_PROFILE_MASK, &profile); std::cout << "major:" << major << '\n' << "minor:" << minor << '\n' << "profile:" << profile << '\n';

So why is glxinfo reporting 3.3 core (besides 3.1) when I cannot request for it? Or am I reading glxinfo wrongly?

Improve this question

1 Answer 1

Reset to default
2

I know this sounds a bit dumb, but you have made a call to glutCreateWindow prior to calling glGetIntegerv right? (Because otherwise the GL context will not yet exist, and the returned context version will be 0).

The main reason why the core would be at 3.3 where as compatibility is at 3.1 will be due to edge cases within the spec. For example, it may be easy enough to implement vertex array objects that follow the core spec, however it may take a lot longer to make that work correctly with ancient legacy features (like compiled vertex arrays, display lists, etc).

Basically for driver developers, there is less work involved to support the core profile - the compatibility profile by its nature is harder to maintain (which was the primary factor that decided the introduction of the core profile).

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Yes: init glut, create context, open window, then query context params. Not sure what's happening because I thought the code was working before. Your comment on the core-compatibility gap makes total sense - thanks.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.