Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.
Valve's Rich Geldreich has been busy working on Vogl, he has now fixed a number of issues that where driver specific to AMD, allowing the debugger to work for AMD now too.

It's funny to see people claiming AMD's drivers have improved, yet when you see developers and Valve themselves here clearly having to go to extra lengths for their drivers, AMD still has work ahead of them.

I really hope some developers start using it, as seeing better OpenGL performance from games would of course benefit Mac OSX as well as Linux.

QuoteI fixed a number of issues specific to AMD's driver - changelist notes are here. Mike should hopefully push these changes to github out tonight or tomorrow latest.

Here's Dota2 replaying on fglrx in -interactive mode. Also, our regression test suite is now working (for the first time!) on AMD, which is pretty exciting.

The GL API callstream involved is hairy - it's kinda amazing that it works at all:

- I traced Dota2 using apitrace on an NVidia 780 to a .trace file
- I played this back on AMD's fglrx using glretrace, then intercepted its output using libvogltrace to a vogl .bin trace file
- I then play this new trace using voglreplay. The regression test suite verifies that the backbuffer CRC's seen during tracing vs. replaying are the same (we've failed if not).

So we're mixing two different drivers and tracing/replaying frameworks in this test. The yellow warnings in the screenshot below are caused by missing uniforms, which are optimized differently by the AMD driver's compiler vs. NVidia (so some program uniforms are missing on AMD, which should be harmless).

Source Article taken from GamingOnLinux.com.
0 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
7 comments

Half-Shot Mar 15, 2014
QuoteIt's funny to see people claiming AMD's drivers have improved, yet when you see developers and Valve themselves here clearly having to go to extra lengths for their drivers, AMD still has work ahead of them.

Mhmm, pretty much why I abandoned the official driver to go hang out with the FOSS driver. (Funny cause these issues don't happen on that driver). I still want AMD to flip all the catalyst code into the FOSS driver where it fits and then work on that full time. These issues would be avoided much easier.
paupav Mar 15, 2014
You are very arrogant. It's not about AMD it is about OpenGl. OpenGl is messy API and need to improve fast.

Wikipedia:
addition to the features required by the core API, GPU vendors may provide additional functionality in the form of extensions.
And OpenGl doesn't have basic features so gpu vendors have to add extensions.

OpenGl needs drastical changes or people will abandon it. Now when Valve is in OpenGl group its time for change.
Liam Dawe Mar 15, 2014
Quoting: paupavYou are very arrogant. It's not about AMD it is about OpenGl. OpenGl is messy API and need to improve fast.

Wikipedia:
addition to the features required by the core API, GPU vendors may provide additional functionality in the form of extensions.
And OpenGl doesn't have basic features so gpu vendors have to add extensions.

OpenGl needs drastical changes or people will abandon it. Now when Valve is in OpenGl group its time for change.

No, I just happen to know a lot about AMD drivers thanks. OpenGL supporting extensions doesn't mean OpenGL doesn't have basic features, jeez talk about talking out of your ass.

I used AMD chips for 5-6 years before finally switching to Nvidia.

Also it is "OpenGL", not "OpenGl" as you call it.
Half-Shot Mar 15, 2014
Quoting: paupavYou are very arrogant. It's not about AMD it is about OpenGl. OpenGl is messy API and need to improve fast.

Wikipedia:
addition to the features required by the core API, GPU vendors may provide additional functionality in the form of extensions.
And OpenGl doesn't have basic features so gpu vendors have to add extensions.

OpenGl needs drastical changes or people will abandon it. Now when Valve is in OpenGl group its time for change.

Well the one thing I credit AMD for is not doing the NVidia/Apple "lets make our own extensions and then we will get all the monies". So in part it is Nvidia's fault for not sharing OpenGL extensions out but hey, they aren't opensource guys. AMD do have some blame though, those drivers are just bad in implementation as they are in OpenGL.

I haven't actually done much with raw OpenGL myself but just watch the sheer number of extension checking it has to do for platform specific extensions when you load a source game.

Edit: But I think people abandoning OpenGL is going a bit far, I mean its literally impossible at this point, its like abandoning C++.
paupav Mar 15, 2014
I exaggerate by saying people will abandon OpenGl, but improvements are necessary!
Anonymous Mar 15, 2014
Reading the release notes show that there are problems with both AMD and nvidida drivers. There was likely more testing with nvidia first (not too surprising), and now they've moved on to making it work with AMD ("just got the ball rolling").
That's all the news that's here.

What OpenGL lacks the most is some standarised framework for compatibility testing, and that's pretty much everyone's fault. G-truc provides a good start for such things, and a debugger provides another.
DrMcCoy Mar 16, 2014
Quoting: paupavAnd OpenGl doesn't have basic features so gpu vendors have to add extensions.

You obviously have no idea how OpenGL standardization works.

There are several paths to a new OpenGL features. One of them is by GPU vendors introducing new features, either by themselves (NV_/ATI_/AMD_/INTEL_) or jointly (EXT_). The Khronos Group frequently reviews those new features and often gives them their "blessing", adding an official ARB_ extension to match the vendor-specific extension.

Those ARB_ extensions very often enter the core of the next OpenGL version.

This is not a case of "Oh, OpenGL is lacking essential features, so we have to roll our own", but a case of "Oh, there's this new thing that was just discovered in a research paper, let's implement it in a new extension". This path to OpenGL standardization exists by design.

Quoting: paupavNow when Valve is in OpenGl group its time for change.

Valve has been a contributor member of the Khronos Group for quite a while now.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.