Web lists-archives.com

Re: Can't get an OpenGL context above 1.3 in Stretch




Am Samstag, 24. März 2018, 14:58:41 CET schrieb Daniel Keast:

Hi Daniel,

 

maybe I am wrong, but I believe, that the problem might be your hardware.

 

Some hardware is not capable on opengl2, only on opengl1. On my netbook I am using an Intel i945 graphics chip, which is only opengl1.0 capable.

 

However, I can use opengl2, as this is software based! In mesa-1.3 there was a software opengl2 solution, which is no more in higher versions. The developer decided to get rid of it, because it was too difficult to maintain it any more.

 

So I downgraded the following packages and theire dependencies to version 1.3:

 

libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa

After that, I set these three packages to hold by using aptitude:

 

aptitude hold libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa

 

so they are not updated automatically. For me, this solution is working very well, as I can still use opengl2 (I love the special effects in KDE, which need opengl2) and until today I got in no problems. Even games are running faster (also in wine).

 

Maybe this does help. It is a pity, that the software opengl2 is been gone in mesa, but that how are things change.

 

Best regards, happy hacking and good luck!

 

Hans

 

> Heya All,

>

> I have some OpenGL code that used to work fine on Jessie, but now I'm

> running Stretch I can't seem to get a context above 1.3. I have a ThinkPad

> X220, with cpuinfo reporting that it has an "Intel(R) Core(TM) i5-2520M CPU

> @ 2.50GHz".

>

> This I think is the relevant bit of code, but I'm happy to provide the rest,

> it's just noddy glued together examples to make a cube spin:

>

> window = SDL_CreateWindow("SDL", SDL_WINDOWPOS_CENTERED,

> SDL_WINDOWPOS_CENTERED, 0, 0,

> SDL_WINDOW_FULLSCREEN_DESKTOP

>

> | SDL_WINDOW_OPENGL);

>

> if (!window) sdl_fail();

>

> if (SDL_ShowCursor(SDL_DISABLE) < 0) sdl_fail();

>

> /* initialise opengl */

> if (SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2) != 0) sdl_fail

> if (SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1) != 0) sdl_fail

> if (SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1) != 0) sdl_fail();

>

> if (!SDL_GL_CreateContext(window)) sdl_fail();

> glEnable(GL_DEPTH_TEST);

>

> {

> GLenum err = glewInit();

> if (GLEW_OK != err) {

> fprintf(stderr, "Error: %s\n", glewGetErrorString(err));

> exit(1);

> }

> }

>

> printf("GL_RENDERER:\t%s\n", glGetString(GL_RENDERER));

> printf("GL_VERSION:\t%s\n", glGetString(GL_VERSION));

> printf("GL_VENDOR:\t%s\n", glGetString(GL_VENDOR));

>

> Just running as it is, I get this output:

>

> $ ./glthing

> MESA-LOADER: failed to retrieve device information

> GL_RENDERER: Mesa DRI Unknown Intel Chipset

> GL_VERSION: 1.3 Mesa 13.0.6

> GL_VENDOR: Intel Open Source Technology Center

> Segmentation fault

>

> The segfault is happening just below this code, when it tries to call

> glBindBuffers (which isn't in OpenGL 1.3). If I request an OpenGL 3.0

> context (I think this cpu should support slightly above that) it fails when

> creating the context:

>

> $ ./glthing

> MESA-LOADER: failed to retrieve device information

>

> Could not create GL context: GLXBadFBConfig

>

> If I dont use GLEW, and just use the OpenGL headers directly (and remove

> anything not OpenGL 1) then I get the higher context, this seems to match

> what happens with glxgears (which from the code seems to use the immediate

> mode):

>

> $ glxgears -info 2>&1 | grep GL_ | head -n 3

> GL_RENDERER = Mesa DRI Intel(R) Sandybridge Mobile

> GL_VERSION = 3.0 Mesa 13.0.6

> GL_VENDOR = Intel Open Source Technology Center

>

> There's no mention of the MESA-LOADER line in the raw output of glxgears.

> Some searching online doesn't seem to have gotten me anything useful about

> what that might be caused by.

>

> Supertuxkart reports that same GLXBadFBConfig line, and then seems to work

> anyway (reporting a 3.0 context).

>

> $ supertuxkart --log=2 | sed -ne '/Irrlicht/,$p'

> Irrlicht Engine version 1.8.0

> Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64

> [warn ] [IrrDriver Temp Logger]: Level 2: X Error: GLXBadFBConfig

> [warn ] [IrrDriver Temp Logger]: Level 2: From call : unknown

> [warn ] [IrrDriver Temp Logger]: Level 3: Vertex shader compilation

> failed at position -1: [warn ] [IrrDriver Temp Logger]: Level 3: Pixel

> shader compilation failed at position -1: [warn ] [IrrDriver Temp

> Logger]: Level 3: Vertex shader compilation failed at position -1: [warn

> ] [IrrDriver Temp Logger]: Level 3: Pixel shader compilation failed at

> position -1: [warn ] [IrrDriver Temp Logger]: Level 3: Vertex shader

> compilation failed at position -1: [warn ] [IrrDriver Temp Logger]: Level

> 3: Pixel shader compilation failed at position -1: [info ] IrrDriver:

> OpenGL version: 3.3

> [info ] IrrDriver: OpenGL vendor: Intel Open Source Technology Center

> [info ] IrrDriver: OpenGL renderer: Mesa DRI Intel(R) Sandybridge

> Mobile [info ] IrrDriver: OpenGL version string: 3.3 (Core Profile) Mesa

> 13.0.6

>

> I don't have any Xorg.conf.d lines now, although I've tried the intel and

> modesetting driver, and both sna and uxa.

>

> Oh, also if I use the LIBGL_SOFTWARE_ALWAYS=true environment variable the

> code runs perfetly fine:

>

> $ LIBGL_ALWAYS_SOFTWARE=true ./glthing

> GL_VERSION: Gallium 0.4 on llvmpipe (LLVM 3.9, 256 bits)

> GL_VERSION: 3.0 Mesa 13.0.6

> GL_VERSION: VMware, Inc.

>

> For the complexity of things that I'm rendering right now, software is

> perfectly fine... it'd just be nice to have some idea of what's going on.

> Any chance anyone could shed some light on this for me?