Author Topic: Shader versioning test  (Read 5094 times)

0 Members and 2 Guests are viewing this topic.

Offline Echelon9

  • Moderator
  • 210
  • Posts: 1,215
Re: Shader versioning test
Thanks for everyone's testing.

I'm comfortable with the variety of test coverage for the Pull Request to go forward for merge. If there are any further small issues shaken out, I'll address them in a later commit.

My next step will be to consider if we can adopt any of the dropped changes from this patch set with some further tweaks.

Update: Now merged into master. This refactor will be present in the next major Freespace 2 Open engine release.
« Last Edit: January 03, 2016, 06:39:55 pm by Echelon9 »


Offline AdmiralRalwood

  • 211
  • Posts: 3,129
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Shader versioning test
* AdmiralRalwood wonders if this means the AMD drivers would work with #version 140
So after a roundabout trip, it turns out the answer is "yes, if you also enable the GL_ARB_compatibility extension".

I tried valiantly to find a set of directives that would allow the Windows AMD drivers to work with a "#version 120" directive; one does not exist. The problem appears to be that it's lying about GL_ARB_texture_buffer_object support. The fs2_open.log clearly says this:
Code: [Select]
  Using extension "GL_ARB_texture_buffer_object".
But when it comes time to actually compile the shaders, we get this:
Code: [Select]
warning(#62) enable/warn/disable extension is not found. Extension "GL_ARB_texture_buffer_object" is not supported

Without a #version directive, this doesn't matter because the thing's basically running in maximum compatibility mode (instead of assuming GLSL 1.1, in clear violation of the spec but supporting the maximum number of shaders out-of-the-box, presumably), and the functionality of the GL_ARB_texture_buffer_object extension entered the core, with the bits we use in particular being added in... GLSL 1.4.

So yes, adding a #version 140 directive (plus using GL_ARB_compatibility to still have access to the deprecated pre-OpenGL 3.1 functionality) does, in fact, allow our current default shaders to compile on the Windows AMD drivers.

But we still can't apply the proper #version 120 directive to every system, and since Mesa drivers don't support the compatibility profile past OpenGL 3.0/GLSL 1.3, we can't just use GLSL 1.4 Compatibility on all platforms either.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.