Web lists-archives.com

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




On Sat, Mar 24, 2018 at 04:20:48PM +0000, Daniel Keast wrote:
> On Sat, Mar 24, 2018 at 03:26:03PM +0100, Hans wrote:
> > 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.
> 
> I think this cpu is sandy bridge, which if I'm reading this right means I should
> be able to get up to Open GL 3.3:
> 
> https://en.wikipedia.org/wiki/Intel_HD_and_Iris_Graphics#Capabilities
> 
> Which is what supertuxkart seems to be reporting as it's GL_VERSION. That's the
> thing that's throwing me at the moment, supertuxkart seems to work fine...
> there's something different in my code, but I can't get my head around the
> difference.
> 
> > 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.
> 
> I think when I run LIBGL_SOFTWARE_ALWAYS=true it forces mesa to use it's
> software driver (I think that's what Gallium 0.4 on llvmpipe (LLVM 3.9, 256
> bits)) means.
> 
> > 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
> 
> I get this when I try the downgrade:
> 
>     # dpkg -i libgl*
>     dpkg: warning: downgrading libgl1-mesa-dri:amd64 from 13.0.6-1+b2 to 10.3.2-1+deb8u1
>     (Reading database ... 325277 files and directories currently installed.)
>     Preparing to unpack libgl1-mesa-dri_10.3.2-1+deb8u1_amd64.deb ...
>     Unpacking libgl1-mesa-dri:amd64 (10.3.2-1+deb8u1) over (13.0.6-1+b2) ...
>     dpkg: warning: downgrading libgl1-mesa-glx:amd64 from 13.0.6-1+b2 to 10.3.2-1+deb8u1
>     Preparing to unpack libgl1-mesa-glx_10.3.2-1+deb8u1_amd64.deb ...
>     Unpacking libgl1-mesa-glx:amd64 (10.3.2-1+deb8u1) over (13.0.6-1+b2) ...
>     dpkg: warning: downgrading libglapi-mesa:amd64 from 13.0.6-1+b2 to 10.3.2-1+deb8u1
>     Preparing to unpack libglapi-mesa_10.3.2-1+deb8u1_amd64.deb ...
>     Unpacking libglapi-mesa:amd64 (10.3.2-1+deb8u1) over (13.0.6-1+b2) ...
>     dpkg: dependency problems prevent configuration of libgl1-mesa-dri:amd64:
>      libgl1-mesa-dri:amd64 depends on libllvm3.5; however:
>       Package libllvm3.5 is not installed.
>     
>     dpkg: error processing package libgl1-mesa-dri:amd64 (--install):
>      dependency problems - leaving unconfigured
>     Setting up libglapi-mesa:amd64 (10.3.2-1+deb8u1) ...
>     Setting up libgl1-mesa-glx:amd64 (10.3.2-1+deb8u1) ...
>     Processing triggers for libc-bin (2.24-11+deb9u3) ...
>     Processing triggers for glx-alternative-mesa (0.7.4) ...
>     Processing triggers for libc-bin (2.24-11+deb9u3) ...
>     Errors were encountered while processing:
>      libgl1-mesa-dri:amd64
> 
> Starts sounding a bit scary, is there anything else you've done?
> 
> > 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.
> 
> I'm confused since the software renderer above gives me a 3.0 context... perhaps
> it's part of the intel driver are implemented in software that got removed?
> 
> > Best regards, happy hacking and good luck! 
> > 
> > Hans
> 
> Thanks a lot for your help, it's definitely more information than I had!
> 
> > 
> >   
> > 
> > > 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
> 
> -- 
> Daniel Keast

Aha!

I found this freebsd bug report that lines up with what I'm seeing in Stretch:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217585

It sounds like FreeBSD's fix got upsreamed, and even better Debian backports has
it. If I install this package everything works perfectly again:

https://packages.debian.org/stretch-backports/libdrm-intel1

-- 
Daniel Keast

Attachment: signature.asc
Description: PGP signature