[AdmiralRalwood]

There's a pull request to hopefully fix shader compilation on certain drivers, but it may break others. In the interests of collecting data, we'd like people to run both a recent Nightly Build and this test build with shaders enabled and report if there are any differences (e.g. if you can run a normal build with shaders, but can't run this build with shaders, or vice versa, let us know and share your debug log).

SSE2: http://deviance.duckish.net/downloads/fs2_fred2_open_PR316_SSE2.7z
AVX: http://deviance.duckish.net/downloads/fs2_fred2_open_PR316_AVX.7z

Please note that since we want to test shader compilation, you will need to remove the -no_glsl ("Disable GLSL (shader) Support") command-line option (and probably -disable_glsl_model / "Don't use shaders for model rendering" as well) for this test.

[m!m]

If you disabled the commandline options AdmiralRalwood mentioned you should be able to test it by simply going to the Tech Room and looking at a ship model.

[chief1983]

It would help to use the MediaVPs so that we actually are using most of the shaders too?

[Echelon9]

The background context here is standards compliance with the OpenGL GLSL shader language.

Per the specifications, it is clear that the start of a shader (whether a fragment, vertex, or geometry shader etc) *must* begin with a version declaration which informs the driver which feature set is expected by the program / shader. e.g.

Code: [Select]

#version 120
// Shader code goes here

Now driver conformance with the OpenGL specification is a mixed bag. As engine developers, we have to work with these quirks in the same way web developers have worked around browser-specific interpretations.

In this case, the specification is clear we *must* include a #version directive. We want to understand from this test which combinations (hardware, driver and OS) correctly interpret this. i.e.

• Mesa (Intel, nVidia, and AMD; open source driver on Linux): correctly requires a #version directive.
• nVidia GeForce (nVidia, closed source driver on Windows/Linux): correctly requires a #version directive?
• AMD Catalyst (AMD, closed source driver on Windows/Linux): barfs with a #version directive and certain OpenGL features.
• OS X ([all?], closed source driver on OS X): correctly requires a #version directive.

Now it may also be that our fs2open shaders are making errors too, which we can confirm by putting them through a reference GLSL compiler.

As GPUs become fully programmable devices, the former fixed function pipeline approaches are less relevant and shader-driven approaches come to the fore. We'd like to better understand the environment we are working with at the moment.

[niffiwan]

OK - recent master builds work, but a build from the PR does not. It exits as soon as I view a ship in the ship lab or tech room.

OS: Linux Mint 17 64bit
Card: GeForce GTS 450
NVIDIA Driver Version: 340.76 (closed source drivers supplied by distro)

Log here, as a wild guess I think my setup wants #version 140 in the shaders rather than #version 120

[AdmiralRalwood]

* AdmiralRalwood wonders if this means the AMD drivers would work with #version 140

[m!m]

OK - recent master builds work, but a build from the PR does not. It exits as soon as I view a ship in the ship lab or tech room.

OS: Linux Mint 17 64bit
Card: GeForce GTS 450
NVIDIA Driver Version: 340.76 (closed source drivers supplied by distro)

Log here, as a wild guess I think my setup wants #version 140 in the shaders rather than #version 120

Looks like another error on our side. I think Nvidia wants to have #extension GL_EXT_gpu_shader4 : enable or #version 140 in the shader. We use OpenGL 2.1 so enabling the extension seems like the way to go. Can you try inserting "#extension GL_EXT_gpu_shader4 : enable\n" in code/globalincs/def_files.cpp:1340 and see if that fixes the error? We might have to do additional extension checking if we want to do that though.

[niffiwan]

OK, that removed one error, just leaving this:

Code: [Select]

0(28) : warning C7508: extension ARB_texture_buffer_object not supported
0(70) : error C7532: global function texelFetch requires "#version 130" or later

And for the heck of it, I tried setting #version 140, and even more errors spat out 

Code: [Select]

0(28) : warning C7508: extension ARB_texture_buffer_object not supported
0(28) : warning C7555: 'attribute' is deprecated, use 'in/out' instead
0(35) : warning C7555: 'varying' is deprecated, use 'in/out' instead
0(61) : warning C7555: 'varying' is deprecated, use 'in/out' instead
0(64) : warning C7555: 'varying' is deprecated, use 'in/out' instead
0(65) : warning C7555: 'varying' is deprecated, use 'in/out' instead
0(102) : error C7616: global variable gl_TexCoord is removed after version 140
0(102) : error C7616: global variable gl_TextureMatrix is removed after version 140
0(102) : error C7616: global variable gl_MultiTexCoord0 is removed after version 140
0(103) : error C7616: global variable gl_Vertex is removed after version 140
0(109) : error C7616: global variable gl_ModelViewMatrix is removed after version 140
0(118) : error C7616: global variable gl_ProjectionMatrix is removed after version 140
0(120) : error C7616: global variable gl_Color is removed after version 140
0(123) : error C7616: global variable gl_NormalMatrix is removed after version 140
0(123) : error C7616: global variable gl_Normal is removed after version 140
0(156) : error C7616: global variable gl_ClipVertex is removed after version 140


[tomimaki]

Seems both builds work on win 7 and ancient amd drivers 13.12.
Log from PR316 shows:

Code: [Select]

  Using OpenGL driver workarounds:
    No #version: Don't add #version to OpenGL shaders
    <none>

[AdmiralRalwood]

Yes, the build currently does not add the #version line to any AMD drivers due to it already being known that they don't play nice with it.

[m!m]

Did you try going to the tech room or playing a mission? The shader problems usually only happen when one of the main shaders is compiled.
Now that I think about it, it would be nice to add a way to override which workarounds are used for testing purposes. I'll try to add that to the PR.

[tomimaki]

I checked Sathanas, Arcadia in Tech Room and Ship Lab, tested in mission and it works (no visible difference).

Tested on Xubuntu 15.04 64bit with Catalyst 15.3 and it works.

[m!m]

Thanks for all your help but I can't figure out how to properly fix this for Nvidia drivers. Our OpenGL rendering engine is pretty much FUBAR in my opinion and without in depth knowledge of the rendering code there is no way I can fix this.

[The Dagger]

Have some strange issues with this build (SSE2 version) but none with nightlies. In the F3 lab, it looks like only subobjects detached from hull (like the cockpit glass or moving parts) are rendered correctly while the first subobject is fixed in a certain direction (original position IIRC, since I'm looking straight into the thrusters). In-mission, those objects are invisible.

OS: Windows 7
Card: Nvidia GeForce GTX 460M
Driver version: 355.60

Here's a log running the latest MediaVPSs: http://pastebin.com/iJMcvSz9

There was a HUGE amount of repeated

Code: [Select]

ERROR! Unable to create vertex shader!
Compiling new shader:
        Model Rendering
   Loading built-in default shader for: main-v.sdr
   Loading built-in default shader for: main-f.sdr
Vertex shader failed to compile:
0(34) : warning C7508: extension ARB_texture_buffer_object not supported
0(35) : error C7532: global type samplerBuffer requires "#version 140" or later
0(35) : error C0000: ... or #extension GL_EXT_gpu_shader4 : enable
0(75) : error C7532: global function texelFetch requires "#version 130" or later
that I deleted in order to upload it.

[tomimaki]

I don't have account on Github so I write here.
Vendors for Mesa depends on GPU
and for Intel is:

Code: [Select]

OpenGL vendor string: Intel Open Source Technology Centerfor AMD opensource driver:

Code: [Select]

OpenGL vendor string: X.Orgfor NVIDIA opensource driver:

Code: [Select]

OpenGL vendor string: nouveau
So maybe easier add the same workaround for NVIDIA Corporation like for ATI Technologies Inc.?

[m!m]

@tomimaki: Thanks for providing the vendor strings. Those are really hard to identify so I just enabled the version workaround for NVIDIA which should fix the issues without the need for more shader fixing.

@The Dagger: Thanks for the log, our shaders don't really like the #version at the top. The latest commit to the PR should fix those issues but I can't compile new builds right now.

[AdmiralRalwood]

Downloads have been updated with fresh builds.

[The Dagger]

Tested the new builds, it's all good ingame and no errors are reported on the debug log (NVidia GPU).

[Echelon9]

Because we have a good group of motivated OpenGL testers here, thought I'd hijack this thread to provide an update on recent fs2open renderer refactoring that I've been looking at.

Branch for code here (no binaries as yet): https://github.com/Echelon9/fs2open.github.com/tree/fix/SHADER_MODEL-concept-removal

Background

On reviewing the OpenGL GLSL setup code in fs2open, it was apparent we use the 'Use_GLSL' variable to encapsulate three different concepts. This is a mess.

At present, depending on the value, this variable is used for:

• Zero: Implies all GLSL shaders are disabled.
• One: Implies a deliberately partial GLSL shader support, as set by -disable_glsl_model command line option.
• Two+: Implies a "Shader Model" level, which is a DirectX concept and not relevant to OpenGL.

The last bullet point is important, as the code readability is improved by removing legacy references to DirectX-only concepts. A broad mapping between DirectX Shader Model versions and GLSL versions can be found here: https://www.opengl.org/wiki/Detecting_the_Shader_Model.

Implementation: Refactoring 'Use_GLSL' variable

So, in order to do something about this, I've refactored the 'Use_GLSL' global variable to properly encapsulate only one concept. The branch does this by splitting the concept of (a) the GLSL version reported by the driver, and (b) whether a command line option has been used to disable GLSL shaders all together.

The third option, -disable_glsl_model appears less relevant today than when it was added. Today, most driver and GPU combinations will happily support > OpenGL GLSL 3.30 (cf. Steam Hardware Survey). There are a small number of users on older hardware that won't support GLSL shaders at all. There are significantly less in between, with partially working driver implementations. So I've taken this opportunity to remove a little used command line option.

The #version directive, which is required for standards conformance, is added in a dynamic manner. Am hoping this works across implementations, but I don't have all the hardware to test.

I'd be keen to see how users with a variety of GPUs and drivers handle this branch. Please test away.

Particularly keen to see if errors along the lines of "varying no longer support", or "global variable gl_TexCoord is removed after version 140".

Mesa open source drivers

Importantly, this branch was developed on an Intel GPU using the Linux Mesa open source drivers. The tooling and infrastructure is frankly fantastic. I want to be clear that the support and ability to see how the driver is internally handling the shaders is very helpful, and hopefully dispel some long-held, but now unsupported negative views on recent Intel GPUs.

I'll have a follow-up post that includes performance figures benchmarking the fs2open engine shaders through various Mesa versions and their shader-db tool, to see how they have improved of late.

[Swifty]

An idea I had floating in my mind was to have something called gr_is_capable() which would be some sort of function other parts of the code outside of the gr_screen specific code that would refer to when trying to figure out if a particular piece of code needed to be run or not.

gr_is_capable would accept a bunch of identifier constants like "CAPABILITY_DEFERED_LIGHTING", "CAPABILITY_ENV_MAPPING", "CAPABILITY_SOFT_PARTICLES", etc and would do all the work in determining if an end system is capable of a certain graphics feature.

Internally inside the gr_opengl code (and hypothetically the gr_vulkan code), we would have a table in the backend that lists all the pre-requisite extensions and shader versions needed for a particular graphics feature. So that way, the only code that needs to really know about extensions or a shader versions would be in the code that actually deals with OpenGL.

Echelon9's stuff seems to be a good step in the right direction.