New AMD Radeon GPU Driver Drops With Noise Suppression Tech, Major OpenGL Performance Uplift
Wow! GZDoom's OpenGL renderer (known to be slow on Radeons) runs almost twice as fast here (Vega 8, Windows 10).
11 1 111 11 1 1 1 1 1 11 1 1 111 1 111 1 1 1 1 111
Too bad it's not relevant much for modern cards, which can do Vulkan just fine.
I must be some kind of standard: the anonymous gangbanger of the 21st century.
The Serpent Rider wrote on 2022-07-27, 00:47:Too bad it's not relevant much for modern cards, which can do Vulkan just fine.
True, but for applications where Vulkan and D3d are not available its totally relevant even on modern AMD GPUs...like Minecraft Java as an example.
I know this driver will once again make my Radeon VII useful to me again, I stopped using it due to the utter garbage OpenGL performance of AMD drivers, im glad they finally fixed it.
Apparently, new driver translates OpenGL calls to Vulkan now. So no, original AMD OpenGL API is still below average. BTW GzDoom can work with Vulkan anyway, so choosing OpenGL is just redundancy with new driver.
Would be nice if community backport it to fanmade drivers for GCN 1.0/2.0/Fury family of chips though (for Windows), which are EoL.
I must be some kind of standard: the anonymous gangbanger of the 21st century.
So it's like an openGL wrapper for vulkan I guess?? Wonder what the overhead is on CPU, since a min CPU is specified.
On older cards, looks like OpenGL vs Vulkan is about 30% difference...
https://www.pcgamer.com/doom-benchmarks-retur … an-vs-opengl/2/
So, would we get a solution that goes, IF game NOT cpubound, THEN ogl wrapper for vulkan = faster.
Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.
The Serpent Rider wrote on 2022-07-27, 13:27:Apparently, new driver translates OpenGL calls to Vulkan now. So no, original AMD OpenGL API is still below average. BTW GzDoom can work with Vulkan anyway, so choosing OpenGL is just redundancy with new driver.
Would be nice if community backport it to fanmade drivers for GCN 1.0/2.0/Fury family of chips though (for Windows), which are EoL.
Honestly Ill take what I can get, anything that makes OpenGl faster on modern AMD GPUs is ok in my books .. even a GL > Vulkan wrapper, Im not sure why exactly AMD is so against just fixing their OpenGL, if nVidia can manage to keep their GL performance on par then I see no reason AMD cannot do the same.
Because OpenGL is obsolete and it's not productive to fix it for a bunch of old software and linux users.
I must be some kind of standard: the anonymous gangbanger of the 21st century.
And if the AMD stuff ain't backportable, maybe crossport from Haiku (Yeah, the BeOS clone that even has Vulkan support these days.)
https://www.reddit.com/r/Amd/comments/r5zvr3/ … un_zink_opengl/
Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.
The Serpent Rider wrote on 2022-07-27, 16:00:Because OpenGL is obsolete and it's not productive to fix it for a bunch of old software and linux users.
Should have done it way before the "major corporate greed" started. Now I don't see the original OpenGL getting fixed anymore. Still the Vulkan wrapper is better than nothing.
previously known as Discrete_BOB_058
The Serpent Rider wrote on 2022-07-27, 13:27:Apparently, new driver translates OpenGL calls to Vulkan now.
This makes no sense.
The performance increase Vulkan has over OpenGL is due to lack of driver overhead (which is CPU bound). Using vulkan doesn't magically remove this CPU overhead as the driver still needs to perform the ancillary functions of the GL pipeline (on the CPU), which for Vulkan, is the repsonsibility of the client application. If anything it would be slower since there would be two driver layers to deal with (even with AZDO). GPU raster performance is the same for GL or VK it's hardware dependant, not API dependant.
OpenGL wrapping to Vulkan is almost oxymoronic (from a GPU architecture point of view) imo.
BEEN_Nath_58 wrote on 2022-07-27, 20:31:Now I don't see the original OpenGL getting fixed anymore.
It's in maintence as the API has been pushed as far as it will go. Only thing to do now is fix driver bugs/improve performance. tbf Vulkan (AZDO) is the logical progression, however it's only a benefit for GPU bound situations and comes with development/maintence cost. CPU bound (which accounts for most software other than gaming and a few other GPUPU/Compute heavy applications) have less of a development headache by using OpenGL over raw Vulkan.
For this reason alone (legacy requirement aside), It's not obsolete and will be here for years imo. Heck even Autodesk (And they have a large software range in CAD/CAE market) don't even have an official Vulkan engine yet.
Wrapper thing is not 100% confirmed though, but Zink link has some indication, that AMD could be using similar approach. Something like 3dfx OpenGL ICD, which internally was still translating API calls to Glide. But hey, maybe AMD really rewrote OpenGL, due to benefit of nuking all graphics chips before Polaris.
I must be some kind of standard: the anonymous gangbanger of the 21st century.
https://old.reddit.com/r/Amd/comments/w9cp6y/ … _6800u/ihvd4a3/
"It's a ground-up redesign of the of OpenGL UMDs on Windows."
11 1 111 11 1 1 1 1 1 11 1 1 111 1 111 1 1 1 1 111
wrote:Interestingly there are some visual bugs that previously only happened in Vulkan that now also happen in OpenGL. This was observed in Ryujinx for example.
I will stick with "corporate greed" scenario for now.
I must be some kind of standard: the anonymous gangbanger of the 21st century.
It's 20 years too late and they still keep hiding some of the new stuff behind Navi only, even though it would work just as well on Polaris of Vega.
After 14 years of AMD/AMD (Phenom II X4 Hd 5870 -> R7 1700X RX 550 -> RX 580), I have had it with all the driver issues and stuff not getting fixed, constant tinkering and adjusting stuff until it works and their attitude of "we can't reproduce it so it's on your end only, won't fix it", unless the issue gets reported over and over again by 1000 different people so they can't keep ignoring it.
My next upgrade will be nVidia, at least their OpenGL performance never sucked on Windows.
The Serpent Rider wrote on 2022-07-27, 21:28:Something like 3dfx OpenGL ICD, which internally was still translating API calls to Glide.
miniGL exists because 3dfx hardware was incapable of implementing full GL spec, and they didn't have an ICD. Luckily the GL requirement was minimal (and could be translated to GLide) so wrapping made sense.
AMD already has a full spec ICD, so no point wrapping to another API as it will have both overheads.
The Serpent Rider wrote on 2022-07-27, 21:41:wrote:Interestingly there are some visual bugs that previously only happened in Vulkan that now also happen in OpenGL. This was observed in Ryujinx for example.
I will stick with "corporate greed" scenario for now.
Latest GL version supports SPIR-V for shaders (introduced by Vulkan), more likely that either client application now uses SPIR-V or AMD changed/unified their ICD shader compiler somehow. Same compiler with same shader source code == same assembly execution which could lead to the same manifestation on same hardware (be it OpenGL or Vulkan).
The Serpent Rider wrote on 2022-07-27, 13:27:Apparently, new driver translates OpenGL calls to Vulkan now. So no, original AMD OpenGL API is still below average. BTW GzDoom can work with Vulkan anyway, so choosing OpenGL is just redundancy with new driver.
Would be nice if community backport it to fanmade drivers for GCN 1.0/2.0/Fury family of chips though (for Windows), which are EoL.
Don't be so sure about GCN (in my case, a 7770) being EOL'd... Yesterday I did a new Win7 install on an old system, I was surprised to find April 2022 drivers available for it (and for Windows 7!). They installed and worked fine.
(Decommissioned:)
mockingbird wrote on 2022-07-28, 00:22:The Serpent Rider wrote on 2022-07-27, 13:27:Apparently, new driver translates OpenGL calls to Vulkan now. So no, original AMD OpenGL API is still below average. BTW GzDoom can work with Vulkan anyway, so choosing OpenGL is just redundancy with new driver.
Would be nice if community backport it to fanmade drivers for GCN 1.0/2.0/Fury family of chips though (for Windows), which are EoL.
Don't be so sure about GCN (in my case, a 7770) being EOL'd... Yesterday I did a new Win7 install on an old system, I was surprised to find April 2022 drivers available for it (and for Windows 7!). They installed and worked fine.
IIRC AMD didn't say that there would be no further fixes for GCN but rather no new features, game optimizations or major up[dates, in other words there will still be small maintenance releases for security fixes and such along with updates to retain windows functionality.
No idea how long they will do this but I suspect for the newer cards sent to EOL it may be a while.
spiroyster wrote on 2022-07-27, 23:46:miniGL exists because 3dfx hardware was incapable of implementing full GL spec, and they didn't have an ICD. Luckily the GL requirement was minimal (and could be translated to GLide) so wrapping made sense.
That's not quite right. 3dfx did eventually have a full ICD even for Voodoo1. Just go look at the files in the later Voodoo1 driver releases.
The miniGL was originally created for GLQuake. id was not interested in using Direct3D 3 or going proprietary again after Vquake. But they didn't need all of OpenGL to run a game.
I wouldn't be surprised if the only thing addressed in any new driver is a security CVE. Graphics drivers are seeing a lot of vulnerabilities discovered these days.
Certainly with all their prior chips put out to "legacy" status that was the end and game developers stopped supporting them too.
You mean that new legacy driver? Most likely. Plus they've made it specifically for old generations of cards and stripped anything related to Polaris, Vega or RDNA.
I must be some kind of standard: the anonymous gangbanger of the 21st century.
