On Sat, May 13, 2017 at 10:47:17AM +1000, Timothy Arceri wrote: > On 13/05/17 09:55, John Brooks wrote: > >On Sat, May 13, 2017 at 09:04:05AM +1000, Timothy Arceri wrote: > >>On 13/05/17 00:11, John Brooks wrote: > >>>On Fri, May 12, 2017 at 03:56:26PM +0200, Samuel Pitoiset wrote: > >>>> > >>>> > >>>>On 05/12/2017 03:39 PM, John Brooks wrote: > >>>>>Since release, Dying Light and Dead Island Definitive Edition have been > >>>>>broken > >>>>>on Mesa, producing at best only a black screen after loading. I found > >>>>>that the > >>>>>root of the problem is that their vertex shaders redeclare the GLSL > >>>>>builtin > >>>>>gl_VertexID, which Mesa's compiler considers to be an error: > >>>>> > >>>>> error: `gl_VertexID' redeclared > >>>>> > >>>>>These patches make the compiler more lenient so that the shaders compile. > >>>>>Because such redeclarations are not explicitly valid in the spec, this > >>>>>behaviour is selectively activated by the new > >>>>>allow_glsl_builtin_redeclaration > >>>>>driconf option, which has been enabled for both games in the default > >>>>>drirc. > >>>>> > >>>>>With this change, both games work on Mesa and render correctly. Note > >>>>>that the > >>>>>games require OpenGL 4.4+, and so it is necessary to launch them with > >>>>>MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE set to OpenGL > >>>>>4.4 (GLSL > >>>>>440) or higher. > >>>>> > >>>>>Contrary to popular belief, this problem actually had nothing whatsoever > >>>>>to do > >>>>>with compatibility profiles. Forcing Mesa to create a higher version > >>>>>compatibility profile with MESA_GL_VERSION_OVERRIDE=4.5COMPAT or > >>>>>allow_higher_compat_version results in graphical glitches, so don't use > >>>>>that. > >>>> > >>>>I wonder if there is multiple versions of Dying Light, but using > >>>>MESA_GL_VERSION_OVERRIDE=4.4 and MESA_GLSL_VERSION_OVERRIDE=440 doesn't > >>>>work > >>>>for me (game crash at launching). Also it requests some unsupported GL > >>>>functions (compat?). > >>>> > >>>>IIRC, Dying Light wants a GL 4.4 compat profile, I guess Timothy can > >>>>confirm? > >>>> > >>>>What's your steam app ID? > >>>> > >>>>Btw, you probably don't need to override the GL/GLSL versions, it should > >>>>be > >>>>backward compatible. > >>>> > >>> > >>>Steam App ID 239140. The use of legacy functions (such as glBegin) in > >>>frame 0 > >>>is SDL's doing: > >>><https://github.com/spurious/SDL-mirror/blob/master/src/render/opengl/SDL_render_gl.c#L1334> > >>> > >>>I don't know why your game would crash on launch. My first thought would be > >>>steam runtime issues though. Make sure Steam runtime is enabled and remove > >>>~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6 > >>> > >>>The version override is necessary since the game will not render at all > >>>with a > >>>3.0 compat profile, which is what it gets without an override. > >> > >>Right but isn't that is because the game is requesting a compat profile? > >> > >>How do you know that the rendering issues you see when using the compat > >>override are not because of missing compat support for higher GL versions? > >> > >>For example a feature/behavior supported in an eariler GL version may have > >>been changed to be more like core and it just happens that overriding to use > >>core makes the rendering problems go away. > >> > > > >Nope, it's not requesting a compat profile or anything specific at all. I > >checked with ltrace and the game calls SDL_GL_CreateContext without calling > >SDL_GL_SetAttribute to specify a version or type. Thus, SDL just calls > >glXCreateContext: > >https://hg.libsdl.org/SDL/file/tip/src/video/x11/SDL_x11opengl.c#l620 > > >The spec says nothing of what version you're supposed to get with > >glXCreateContext, but the result with Mesa is a 3.0 compatibility profile > >unless you override it. > > That's because glXCreateContext is from a time before there was such a thing > as compat profiles. glXCreateContextAttribsARB was introduced to solve this > problem. > > Are you suggesting other drivers don't return a compat profile in this > scenario? >
No, only that it's not explicitly defined by the spec and what Mesa does is not necessarily the same as what other drivers do. However, it is a reasonable assumption that they also would return a compatibility profile. The difference would be that other drivers would return a real compatibility profile because they support it. Much has changed between OpenGL 3.0 and 4.4, and since Mesa's implementation of the compatibility spec is strictly limited to 3.0 (before there even was a separate compatibility spec), it's anyone's guess what we're doing differently when presenting a faux 4.4 compatibility profile backed by a 3.0 implementation. Maybe they use a new feature that we implement with existing code that has a different path for 3.0 compat, but that path isn't supposed to be used for this feature and we don't account for it because it didn't exist in 3.0. Kind of like what you said. In any case, it's clear that the game functions best with a core profile and there's no obvious intent to use a compat profile, just some silliness with the SDL context creation where they didn't set a couple of variables to tell SDL to get them a specific version. The game's API calls are clearly those of a modern OpenGL application. > > > >>_______________________________________________ > >>mesa-dev mailing list > >>mesa-dev@lists.freedesktop.org > >>https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > >-- > >John Brooks > >Frogging101 on IRC and elsewhere > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- John Brooks Frogging101 on IRC and elsewhere _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
