Radeon Adrenalin Edition 18.2.1 WHQL Download & Discussion

Discussion in 'Videocards - AMD Radeon Drivers Section' started by NvidiaFreak650, Feb 1, 2018.

  1. ObscureangelPT

    ObscureangelPT Master Guru

    Messages:
    552
    Likes Received:
    66
    GPU:
    Zotac GTX 1650 Supe
    This driver still has the problem with relive audio corruption, jerkness and stuttering.

    Take a look at the mid-video
     
  2. JonasBeckman

    JonasBeckman Ancient Guru

    Messages:
    17,509
    Likes Received:
    2,906
    GPU:
    MSI 6800 "Vanilla"
    Cemu is getting Vulkan support though that's 2019 at the earliest last I heard.
    https://www.reddit.com/r/cemu/comments/7qwk8b/cemu_1113_guide_for_amd_users_for_30fps/

    For OpenGL I would say it has to do with AMD and NVIDIA having different views on OGL with NVIDIA having multi-threading and some other non-standard implementations (And games using NVIDIA OpenGL extensions.) whereas AMD sticks to the specs (They have extensions of their own though, same goes for Vulkan.) but then you also have Linux and the unofficial Mesa drivers there and those sticking to spec as well, while being a lot faster or so I've heard which if accurate that then throws that theory out entirely and instead AMD seems to just be dragging behind particularly on Windows and their drivers when it comes to support for OpenGL in general, probably less so for version 4.x and above but still not comparable to NVIDIA.
     
    Jackalito and warlord like this.
  3. OnnA

    OnnA Ancient Guru

    Messages:
    13,707
    Likes Received:
    3,532
    GPU:
    3080Ti VISION OC
    18.2.1 Still broken when playing Starfighter Assault in SW BF2 -> Triangles all over the screen :confused:o_O:eek:
     
    Last edited: Feb 4, 2018
    Jackalito likes this.
  4. OnnA

    OnnA Ancient Guru

    Messages:
    13,707
    Likes Received:
    3,532
    GPU:
    3080Ti VISION OC
    Now it is ~89-95USD (it will last min. 3-5 years so NP here)
    Yes it is a little expensive but my current one is not good at all tasks/games (it was ~35USD)

    -> https://www.bloody.com/en/product.php?pid=10&id=120
     
    HK-1 likes this.

  5. HK-1

    HK-1 Master Guru

    Messages:
    877
    Likes Received:
    528
    GPU:
    RX580 Power Color
    hmm is not very expensive imo, I love it realy man thanks for the link too :)
     
  6. WhiteLightning

    WhiteLightning Don Illuminati Staff Member

    Messages:
    29,106
    Likes Received:
    1,941
    GPU:
    GTX1070 iChillx4
    It will not help if you post things like that here. please stick to driver feedback in advance!
     
    HK-1 and warlord like this.
  7. LM2014

    LM2014 Member Guru

    Messages:
    156
    Likes Received:
    29
    GPU:
    RX 6800 XT
    I'm getting very disappointed with AMD
    I'm tired of reporting problems with my graphics card
    Already tried with a new installation of windows 10 with both version 1709 and 1703 and continue with the same problems.

    Issues:
    when I stop playing any game my screen begins to flickering and this issue not have in previous drivers. (issues with 17.12.2 18.1.1 and 18.2.1)
    Sometimes Arma 3 and Call of Duty Infinite Warfare lockup my computer with black screen and high pitch sound playing continously. My GPU isn't responding anymore, and the driver isn't restarting, or anything. I have to restart my pc. (17.12.1 and all previous drivers)
    I try DDU and same.
    Back to 17.12.1 most stable but with sporadic black screens.
     
  8. Krteq

    Krteq Master Guru

    Messages:
    802
    Likes Received:
    387
    GPU:
    RX Vega 56 +64 BIOS
    Any OC on your card?
     
  9. ObscureangelPT

    ObscureangelPT Master Guru

    Messages:
    552
    Likes Received:
    66
    GPU:
    Zotac GTX 1650 Supe
    @LM2014 It seems that AMD have a lot of work to go through yet with Vega.
    I'm starting to think that Raja was right, at some point one time he said that he was really working hard on Vega drivers and he was tired.
    I'm assuming that Vega was a problem since the very beginning and it will take a ton of time to change.

    Since there is no other arquitechture to be released soon, this might be fixed more fast than the usual.
    Altough it clearly shows that Vega was never ready to be released, they even cancelled some of the features on the drivers that were exclusive to vega arquitechture, so that pretty much sums it up.
    It's much more work than they can deal with :/

    I still have people complaining with stupid issues in Polaris cards.
    AMD really needs more people to work on the drivers, this was always a problem, and it seems that it's still an issue.
    The fact that they added wattman, relive, chill and many other softwares might be putting more stress in the team to fix more stuff, since all that software have it's own problems too, and this might be detracting people from spending time on those real issues.
     
    OnnA likes this.
  10. vbetts

    vbetts Don Vincenzo Staff Member

    Messages:
    15,124
    Likes Received:
    1,700
    GPU:
    GTX 1080 Ti
    This is not a bashing ground for AMD. I do understand if the driver has issues.
     
    warlord likes this.

  11. warlord

    warlord Ancient Guru

    Messages:
    2,761
    Likes Received:
    927
    GPU:
    Null
    I just wondered why in 2018 and new driver branches, OpenGL still not fixed/improved since ATI's age. I got my eyes into DoTA 2 missing quality in comparison with Nvidia rival and tested Zelda with cemu. I know you should help us all with site's well behavior rules, but also you should accept the privilege of conversation. Tessellation fixed with "AMD Optimized" profiles since years. OpenGL never worked 100% properly and we pray for Vulkan API. If Vulkan/Mantle never existed in the first place, what we should expect? Fixed by 2033? Thanks.
     
  12. Fox2232

    Fox2232 Ancient Guru

    Messages:
    11,809
    Likes Received:
    3,366
    GPU:
    6900XT+AW@240Hz
    I have Roccat Kone XTD Optical. You can alter functionality of all buttons. Set double, multi, repetitive click, macros, timing at 1ms intervals.

    What you can't do is to set up "tap/click" on MOUSE-DOWN. I had to reverse-engineer (not very hard to do) structure of profile files and codes for function to get it into mouse.
    But now, I have profile for CS, where pressing down LMB causes actually to press and release (click) on input for PC. And mouse will not send another click till LMB is physically released and pressed again.
    Single-Tap-Shooting without need to have script, and therefore undetectable.
     
    OnnA likes this.
  13. Krteq

    Krteq Master Guru

    Messages:
    802
    Likes Received:
    387
    GPU:
    RX Vega 56 +64 BIOS
    Are there any differences in image quality? What are you talking about?

    AMD's OpenGL implementation is 100% compliant Khronos standards (OpenGL 4.5 atm.). You are crying on a wrong grave mate.
     
  14. Eastcoasthandle

    Eastcoasthandle Ancient Guru

    Messages:
    3,021
    Likes Received:
    567
    GPU:
    Nitro 5700 XT
    The next time this happens exit back to desktop and hit:
    CTRL+SHIFT+WIN+B

    This should reset your graphics driver.
     
  15. LM2014

    LM2014 Member Guru

    Messages:
    156
    Likes Received:
    29
    GPU:
    RX 6800 XT
    Hi
    No overclok
    It´s impossible to back to desktop because lock up with black screen with pitch sound playing continously and I have to restart (force)
     

  16. Romulus_ut3

    Romulus_ut3 Master Guru

    Messages:
    689
    Likes Received:
    151
    GPU:
    AMD RX 570 4GB
    Having a 100% compliance doesn't mean.. anything at all, specially when it comes to performance.

    What Warlord is trying to say is that on AMD, the OpenGL performance has historically been inferior compared to any competing nvidia product. Take DOOM for example. AMD trails nvidia's OpenGL performance, even if you discard the existence of the Titan XP and the GTX 1080 Ti. To keep up the pace, you need to lower certain settings that you shouldn't be needing to do.

    With Cemu or pretty much every other emulator, it gets much worse. An example would be that a GTX 750 Ti can run circles around the likes of a HD 7870 in certain instances. And these emulators and it's video OpenGL plugins aren't running vendor specific codes.

    Rich Geldreich's blog from 2014 pretty much sums it up.

    The Truth on OpenGL Driver Quality

    The driver landscape is something that any practicing GL dev must face unless you like having only a fraction of potential customers able to enjoy your product. (These are the drivers you'll have to work with in order to actually ship a product today or within the next year or so. If you're just a dev playing at home with one driver you'll probably not have to deal with any of this gritty real-world stuff.)

    If all you've ever done is use D3D then you better strap yourself in because the available GL drivers for Windows/Linux are all over the map. Here's my current opinion on driver quality:

    Vendor A

    What most devs use because this vendor has the most capable GL devs in the industry and the best testing process. It's the "standard" driver, it's pretty fast, and when given the choice this vendor's driver devs choose sanity (to make things work) vs. absolute GL spec purity. Devs playing at home use this driver because it has the sexiest, most fun to play with extensions and GL support. Most of what you hear about the amazing things GL will be able to do in order to compete against D3D12/Mantle are by devs playing with this driver. Unfortunately, we can't just target this driver or we miss out on large amounts of market share.

    Even so, until Source1 was ported to Linux and Valve devs totally held the hands of this driver's devs they couldn't even update a buffer (via a Map or BufferSubData) the D3D9/11-style way without it constantly stalling the pipeline. We're talking "driver perf 101" stuff here, so it's not without its historical faults. Also, when you hit a bug in this driver it tends to just fall flat on its face and either crash the GPU or (on Windows) TDR your system. Still, it's a very reliable/solid driver.

    Vendor A supports a zillion extensions (some of them quite state of the art) that more or less work, but as soon as you start to use some of the most important ones you're off the driver's safe path and in a no man's land of crashing systems or TDR'ing at the slightest hickup.

    This vendor's tools historically completely suck, or only work for some period of time and then stop working, or only work if you beg the tools team for direct assistance. They have enormous, perhaps Dilbert-esque tools teams that do who knows what. Of course, these tools only work (when they do work) on their driver.

    This vendor is extremely savvy and strategic about embedding its devs directly into key game teams to make things happen. This is a double edged sword, because these devs will refuse to debug issues on other vendor's drivers, and they view GL only through the lens of how it's implemented by their driver. These embedded devs will purposely do things that they know are performant on their driver, with no idea how these things impact other drivers.

    Historically, this vendor will do things like internally replace entire shaders for key titles to make them perform better (sometimes much better). Most drivers probably do stuff like this occasionally, but this vendor will stop at nothing for performance. What does this mean to the PC game industry or graphics devs? It means you, as "Joe Graphics Developer", have little chance of achieving the same technical feats in your title (even if you use the exact same algorithms!) because you don't have an embedded vendor driver engineer working specifically on your title making sure the driver does exactly the right thing (using low-level optimized shaders) when your specific game or engine is running. It also means that, historically, some of the PC graphics legends you know about aren't quite as smart or capable as history paints them to be, because they had a lot of help.

    Vendor A is also jokingly known as the "Graphics Mafia". Be very careful if a dev from Vendor A gets embedded into your team. These guys are serious business.

    Vendor B

    A complete hodgepodge, inconsistent performance, very buggy, inconsistent regression testing, dysfunctional driver threading that is completely outside of the dev's official control. Unfortunately this vendor's GPU is pretty much standard and is quite capable hardware wise, so you can't ignore these guys even though as an organization they are idiots with software. Basic stuff like glTexStorage() crashes (on a shipped title) for months on end with this driver. B's driver devs try to follow the spec more closely than Vendor A, but in the end this tends to do them no good because most devs just use Vendor A's driver for development and when things don't work on Vendor B they blame the vendor, not the state of GL itself.

    Vendor B driver's key extensions just don't work. They are play or paper extensions, put in there to pad resumes and show progress to managers. Major GL developers never use these extensions because they don't work. But they sound good on paper and show progress. Vendor B's extensions are a perfect demonstration of why GL extensions suck in practice.

    This vendor can't get key stuff like queries or syncs to work reliably. So any extension that relies on syncs for CPU/GPU synchronization aren't workable. The driver devs remaining at this vendor pine to work at Vendor A.

    Vendor B can't update its driver without breaking something. They will send you updates or hotfixes that fix one thing but break two other things. If you single step into one of this driver's entrypoints you'll notice layers upon layers of cruft tacked on over the years by devs who are no longer at the company. Nobody remaining at vendor B understands these barnacle-like software layers enough to safely change them.

    I've occasionally seen bizarre things happen on Vendor B's driver when replaying GL call streams of shipped titles into this driver using voglreplay. The game itself will work fine, but when the GL callstream is replayed we'll see massive framebuffer corruption (that goes away if we flush the GL pipeline after every draw). My guess: this driver is probably using app profiles to just turn off entire features that are just too buggy.

    Interestingly, Vendor B has a tiny tools team that actually makes some pretty useful debugging tools that actually work much of the time - as long as you are using vendor B's GPU. Without Vendor B's tools togl and Source1 Linux would have taken much longer to ship.

    This could be a temporary development, but Vendor B's driver seems to be on a downward trend on the reliability axis. (Yes, it can get worse!)

    On the bright side, and believe it or not, Vendor B knows the OpenGL spec inside and out - to the syllable. If you can get them to assist you, their advice is more or less reasonable about plain GL matters (not extensions).

    Vendor C - Driver #1

    It's hard to ever genuinely get angry at Vendor C. They don't really want to do graphics, it's really just a distraction from their historically core business, but the trend is to integrate everything onto one die and they have plenty of die space to spare. They are masters at hardware, but at software they aren't all that interested really. They are the leaders in the open source graphics driver space, and their hardware specs are almost completely public. These folks actually have so much money and their org charts are so deep and wide they can afford two entirely different driver teams! (That's right - for this vendor, on one platform you get GL driver #1, and another you get GL driver #2, and they are completely different codebases and teams.)

    Anyhow, this vendor's HR team is smart: it directly hires open source wiz kids to keep driver #1 plodding forward. This driver is the least advanced of the major drivers, but it more or less works as long as you don't understand or care what "FPS" means. If it doesn't work and you're really motivated you can git your hands dirty and try to fix it and submit a patch. If you're really good at fixing this driver and submitting patches then you may get a job offer from this vendor.

    Anyhow, driver #1 is unfortunately pretty far behind on the GL standard, but maybe in 1-2 years they'll catch up and implement the spec as of last year. But you can't ignore this driver because they have a significant and strategically growing market share. So as a developer who wants to reach this market, you can't afford to use those fancy extensions or the latest trendy "modern" GL supported by vendors A and B. You must do a min() operation across all the drivers and in many cases this driver gates what you can do.

    Vendor C has no GL tools at all for either platform. Sorry - want to debug that graphics problem you're having? Welcome to 1999.

    Vendor C - Driver #2

    A complete disaster. This team's driver is barely used by any titles because GL on this platform is totally a second class citizen, so many codepaths in there just don't work. They can't update a buffer without massive, random corruption. This team will do stuff like give you a different, unique, buggy driver drop for every title in your back catalog for perf analysis or testing. This team will honestly ask you if "perf" or "correctness" is more important.

    I've seen one well-known engine team spend over a year attempting to get their latest GL 4.x+trendy extensions backend working at all on this team's driver. Hey guys - this driver just doesn't work, just move on already and implement a plain GL 3.x backend with workarounds (just like togl and other shipping titles do today).

    On the bright side, Vendor C feeds this driver team more internal information about their hardware than the other team. So it tends to be a few percent faster than driver #1 on the same title/hardware - when it works at all.

    Other drivers:

    In addition to the above major drivers, there are several open source drivers, mostly developed by the community, for hardware from vendors A and B. They tend to be behind the times from a GL perspective, but I hear they mostly work. I don't have any real experience or hard data with these drivers, because I've been fearful that working with these open source/reverse engineered drivers would have pissed off each vendor's closed source teams so much that they wouldn't help.

    Vendor A hates these drivers because they are deeply entrenched in the current way things are done. These devs have things like mortgages and college funds (or whatever) to keep funding, so there's a massive amount of inertia from this camp. There's no way they are going to release their Top Secret GPU Specs to the public, or (gasp!) open source their driver. Vendor A will have to jump on the open source driver bandwagon soon in order to better compete against Vendor C's open model, whether they like it or not.

    Vendor B halfheartedly helps their open source driver by funding a tiny team to keep the thing working. At some point, the open source driver for Vendor B's GPU may be a more viable path forward then their half-functional closed source driver.

    Conclusion

    To ship a major GL title you'll need to test your code on each driver and work around all the problems. May the "GL Gods" help you if you experience random GPU corruption, heap corruption, lockups, or TDR's. Be very nice to the driver teams and their managers/execs, because without them your chances aren't nearly as good.​

    There's also Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame.
     
    Last edited: Feb 4, 2018
  17. LocoDiceGR

    LocoDiceGR Ancient Guru

    Messages:
    2,418
    Likes Received:
    839
    GPU:
    Gigabyte 3060 Ti
    You guys talking about Cemu that until recently didnt even support more than 1 CPU Core.

    Get this off-topic to another thread please.
     
    Last edited: Feb 4, 2018
    Krteq likes this.
  18. Romulus_ut3

    Romulus_ut3 Master Guru

    Messages:
    689
    Likes Received:
    151
    GPU:
    AMD RX 570 4GB
    Being able to "read" is a wonderful skill to possess.

    We are talking about AMD's drivers being not up to the task, specially when it comes to OpenGL with information quoted straight from people who work within the industry.

    Shill elsewhere, if you can't handle AMD's drivers being rightly criticized, please. You don't help the consumers in any fashion, except helping them to make the jump to the green team much sooner than expected.
     
    Last edited: Feb 4, 2018
    MS-DOS likes this.
  19. OnnA

    OnnA Ancient Guru

    Messages:
    13,707
    Likes Received:
    3,532
    GPU:
    3080Ti VISION OC
    IMO :D (based on my experience)

    DX9c or 9.3 -> Working just like it should (im playing now HoMM VII & BL2) 4.5/5
    DX11.x
    -> Working very good (look at BF1, SW BF2, NFS & DeusEx MkD) 5/5
    DX12.x
    -> Best possible Performance (Async Compute On/Off no matter) 5/5
    OGL 4.5
    100% OGL 4.6 70% -> Depends on Game/App, some games like Wolf tOB is just Bad, but other games like Satellite Reign & Sword Coast Legends performs just Good. 3.5/5
    Vulkan
    -> Best possible Performance 5/5 (Doom & Wolf)
    Mantle
    -> Best possible Performance 5/5 (BF4, BF:H & DragonAge: I)

    [​IMG]

    [​IMG]

    more -> https://imgur.com/a/AtDcb
     
    Last edited: Feb 5, 2018
  20. Rootax

    Rootax Member Guru

    Messages:
    158
    Likes Received:
    25
    GPU:
    3090 MSI Suprim X
    Can confirm, Vega FE is no longer supported. Weird.
     

Share This Page