[Mesa-dev] [PATCH 0/2] Allow redeclaration of GLSL builtins; fixes Dying Light and Dead Island Definitive Edition

Sat May 13 02:25:58 UTC 2017

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 at lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >--
> >John Brooks
> >Frogging101 on IRC and elsewhere
> >
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
John Brooks
Frogging101 on IRC and elsewhere