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
signature.asc
Description: PGP signature
