Support us on Patreon
PayPal
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.
Source Article taken from GamingOnLinux.com.
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
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
7 comments
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.
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.
0 Likes
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.
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.
0 Likes
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.
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.
0 Likes
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.
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++.
0 Likes
I exaggerate by saying people will abandon OpenGl, but improvements are necessary!
0 Likes
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.
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.
0 Likes
And 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.
Now 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.
0 Likes
See more from me