Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #194119 > unrolled thread

Can't get an OpenGL context above 1.3 in Stretch

Started byDaniel Keast <daniel@kea.st>
First post2018-03-24 15:10 +0100
Last post2018-03-29 19:50 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.debian.user

Contents

  Can't get an OpenGL context above 1.3 in Stretch Daniel Keast <daniel@kea.st> - 2018-03-24 15:10 +0100
    Re: Can't get an OpenGL context above 1.3 in Stretch Hans <hans.ullrich@loop.de> - 2018-03-24 15:30 +0100
      Re: Can't get an OpenGL context above 1.3 in Stretch Daniel Keast <daniel@kea.st> - 2018-03-24 17:30 +0100
        Re: Can't get an OpenGL context above 1.3 in Stretch Daniel Keast <daniel@kea.st> - 2018-03-29 19:50 +0200

#194119 — Can't get an OpenGL context above 1.3 in Stretch

FromDaniel Keast <daniel@kea.st>
Date2018-03-24 15:10 +0100
SubjectCan't get an OpenGL context above 1.3 in Stretch
Message-ID<vwS1P-6Jv-9@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

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?

-- 
Daniel Keast

[toc] | [next] | [standalone]

#194120

FromHans <hans.ullrich@loop.de>
Date2018-03-24 15:30 +0100
Message-ID<vwSlc-6QD-7@gated-at.bofh.it>
In reply to#194119

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#194127

FromDaniel Keast <daniel@kea.st>
Date2018-03-24 17:30 +0100
Message-ID<vwUdj-88b-5@gated-at.bofh.it>
In reply to#194120

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#194274

FromDaniel Keast <daniel@kea.st>
Date2018-03-29 19:50 +0200
Message-ID<vyJQu-3VW-7@gated-at.bofh.it>
In reply to#194127

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web