OpenGL Successor

Have you guys heard of glNext being devoloped by Khronos and Value? I am very interested in seeing the advantages over OpenGL which has sort of been thought as a dying engine.
http://www.pcgamer.com/opengl-successor-to-be-unveiled-at-gdc-session/

The reason I bring it up is because (correct me if I am wrong) PA is running on OpenGL

What improvements do you think it will bring?

For PA? Probably none, I doubt they will update PA for that stuff.

I'll give it a few more years to mature first

Yep this is correct.

It's should bring simplified work with context from within multiple threads/cores and this it's might finally bring unified shader compiler that will solve a lot of compatibility issues that GLSL had because vendors implemented things differently (e.g Nvidia allowed to compile tons of broken code).

Though currently Uber already implemented their own threading model for GL and using GLSLang for shader validation. Still as far as I understand problem with brightness on AMD/Windows is happen because there something really wrong with AMD shader compiler on AMD proprietary drivers and if there was more strict GLSL compiler this would likely help to avoid such problems

Very interesting, I always liked OpenGL, I felt like I've always had higher FPS with ID software games back in the day. It's sad it doesn't get more use.

OpenGL isn't an engine, it's a graphics API. Graphics APIs take data and commands and passes on that data to a GPU to tell it what to render. A graphic or game engine is the thing that decides what that data is and what the commands are.

Part of what modern graphics APIs do is help move the data where the graphics card can access it and translate the commands to a form the graphics card understands. This means that generally the commands and data we give to the API will work on different hardware even if they work very differently.

PA is running OpenGL 3.1, even though there are tons of improvements in OpenGL from versions 3.2 through now 4.5. You can blame a combination of wanting to support a wide range of users, as well as Mac & Linux which had iffy support for OpenGL after 3.2 when we started working on PA (and in fact we dropped back down to OpenGL 3.1 because of Linux).

One of the big problems with OpenGL and DirectX (pre version 12) is these APIs are still basically designed around how video cards theoretically worked in the late 90's. Graphics cards have changed significantly, but the APIs haven't, so there's a lot more translating happening behind the scenes. DirectX 12, Mantle (AMD), and Metal (iOS) are all looking to break with the past and present an API that is closer to how the graphics card is actually doing stuff today.

OpenGL is funny because of a concept of extensions to the base API. Different graphics cards and drivers can support a range of features such that something that is "OpenGL 3.0" might use a feature that is consider part of OpenGL 4.4. It also allows for different graphics card vendors to have unique extensions that are closer to what the driver is sending the video card behind the scenes or features that aren't part of the base feature set. These extensions often get added back into later versions of OpenGL as part of the "core" language and made to work on different devices, though sometimes one card has to implement a bit of that translation again because that's not how their hardware works.

The problem with this is now there's a hundred ways to skin a cat in OpenGL, and most of them are bad. I suspect nextGL will strip out most of the redundant functionality of OpenGL and try to be like DirectX 12 and Mantle being closer to the actual hardware functionality, but cross platform (unlike DirectX) and cross vendor (unlike Mantle).

Also, yes Mantle is "open" in that AMD has offered to let Intel and Nvidia join them in supporting it, but really it exists because it's close to what runs on the Xbone and PS4.

We have our own threading model for setting up calls to OpenGL, but the actual API calls all have to happen on one thread. What we do is build a giant buffer of API calls that get chewed on. If we could just make the calls from all of those threads things would be even faster.

The AMD brightness bug has nothing to do with GLSLang or strict GLSL compilers. AMD (and OSX) have very strict compilers, but sometimes stuff just doesn't work even if it should.

Really enjoyed this detailed explanation, thanks for the post. I misspoke when I said engine, I misused the terminology but know the difference. Curious to know if Uber is interesting in ever upgrading to GlNext if it's successful. I also didn't know Mantle was open and the primary reason for that was Xbox1 and PS4 sharing similar AMD cards.

Though it's also needed for Intel Sandy Bridge (HD2000 / HD3000) on Windows.

Thanks. You're explaining it much better than me.

Interesting... Any details on what going wrong here?
Anyway hope you'll eventually find workaround for this one.

You may note this open is in quotes which is just about right. My personal understanding of this situation: Mantle is "open", but it's designed by one vendor to suite specific architecture their own hardware best.

This kind of openness is opposite to Khronos standards. OpenGL/GLNext isn't just "open", but created by cooperation of multiple vendors which is main difference.

Will we upgrade PA? No.
Will we upgrade the engine on some future project? Possibly (hopefully).

None yet, though I can say for the first version of the SAO shader it had serious problems on some AMD cards. One of the ones in the office had the issue and the problem was caused by the shader getting completely junk data from an otherwise mundane and commonly used function. Specifically dFdx and dFdy were random returning infinites and nans, and when it wasn't it was returning values that were the inverse of every other video card. It wasn't any issue with the shader, the function was (and probably still is) just straight up broken.

It could be something like this, it could be something completely different.

I kind of wish there wasn't macos and linux support, just so we windows users could bask in windows 10 dx12 glory

Have to say I agree. On the other hand, I think what Valve is doing, trying to push the OS monopoly off Microsoft is admirable as well.

^value?
you mean valve?

I am perfectly content with the Microsoft OS monopoly.

Until they start charging you $1000 per os, like many monopolies do. Pay attention to ISP's in your area lately for example?

Without mac and linux the game probably would have lost a lot of funding. XP

But can you give work to all cores and increase performance? If we want 40 player battles, we need all the juice in PC we can get.

You think? I always thought of mac and linux being a very low percentage for gaming, probably less then 5% I could be wrong though.

Makes me wonder if Steam offers any bonuses for having a game that supports Linux/Mac.