Comments Locked

49 Comments

Back to Article

  • Jtaylor1986 - Tuesday, December 15, 2015 - link

    Seems like they are making some sensible changes on the driver front all around. The proof of the pudding is in the eating though
  • niva - Tuesday, December 15, 2015 - link

    There has been talks about doing this in the past. At this stage I've reached the point of "I'll believe it when I see it."
  • Atari2600 - Wednesday, December 16, 2015 - link

    Yeah, I heard all this before about 4 years ago - I'll wait till they actually start doing it before praising them.

    As good 'ol Dubya would say; "Fool me once, shame on you.... fool me..... can't get fooled again".
  • Flunk - Tuesday, December 15, 2015 - link

    Only for their Linux drivers, with the majority of users running Windows this doesn't change much. It would be nice to see those drivers opened up.
  • przemo_li - Wednesday, December 16, 2015 - link

    Yes, and No.

    OpenSource driver is accompanied by ISA documentation for GCN too. Game devs on Windows still benefit, by great transparency into how GPUs actually work. Sure they may still not know what quirks Catalyst have, but they will be prepared for hardware quirks.
  • ToTTenTranz - Tuesday, December 15, 2015 - link

    Having secured the hardware for all consoles (so almost all developers will inevitably work with GCN), it makes sense that AMD is trying to make this into a competition over "pure" hardware, instead of vendor-specific software optimizations like nVidia has been doing with Gameworks.
  • Dribble - Tuesday, December 15, 2015 - link

    AMD puts out another bunch of power point slides proclaiming open source will solve all their problems. What this translates into is "we know our competitor does X, so we will just announce we can do it too, only free to all and then hope the open source fairies do all the work". Previous experience shows this goes no-where.
  • Merkin Mustache - Tuesday, December 15, 2015 - link

    So salty.
  • DigitalFreak - Tuesday, December 15, 2015 - link

    No, so true.
  • BurntMyBacon - Wednesday, December 16, 2015 - link

    @Merkin Mustache

    It depends on what your expectations are. If you are expecting that open sourcing the driver will fix all the problems that the previous closed source drivers had, then you are relying on @Dribble: "open source faires" and "Previous experience shows this goes no-where." If you are expecting that this will benefit the open source driver and not so much the closed source driver, then you may not be so disappointed.

    As I see it, their are two extremes:
    Pessimistically, by using the same open source kernel space driver for both their partially closed and fully open source drivers, the quality of the closed source driver will drop to match that of the open source driver as ATi relies on the open source community almost entirely to write a driver that they don't have the hardware knowledge to properly optimize.
    Optimistically, the open source driver quality will go up to match the quality of the closed source driver given the same code will be used as a base for both. There may even be a slight improvement compared to previous closed source efforts as the workforce that was once divided and replicating each others work will now be unified and more effort can be put into the single driver base. They may even get something useful from the open source community at large to fold back into the driver.

    Most likely, the end result will be somewhere in between. I don't think that RTG will rely on the open source community to develop its driver. Rather, they will now have the same people, who were once working closed source only, working the same code that will be used in the open source driver. I suspect that the workforce that was once working the open source only driver will reassigned to some of the surrounding modules or dismissed to cut cost. The open source community may in time make some suggestions and/or contributions to UI, ease of use, or feature to be used in the windowing system, but I wouldn't expect much in the way of optimization. Meaningful optimization may come out of the HSA and HPC efforts, but I wouldn't expect that to pay off any time soon. More HSA enabled software is needed before the benefit could even be seen.

    Any way you dice it, though, this will not be the same as the previous endeavors into open source. By using they same base for the open and closed source drivers, they have for better or for worse eliminated the disparity between them (at least as far as the base code is concerned). Given that OpenGL maintains open and closed source separation, we will still see disparity in gaming. That said, it remains to be seen how quickly the OpenCL and Vulkan evolve to open source. It may be that gaming parity will eventually be achieved through Vulkan, but that is an optimistic view.
  • mdriftmeyer - Tuesday, December 15, 2015 - link

    Sure thing. You must not be paying attention to Linux Kernel 4.4/4.5 development.
  • Ikefu - Tuesday, December 15, 2015 - link

    I think Open Source has shown massive merits in other spaces. Lulzbot with 3D Printers is a great example. It took time but the community feedback and development bolstered their own and now they have one of the most awarded consumer printers going. Open source can have huge benefit when you use it in conjunction with your own engineering.
  • FLHerne - Tuesday, December 15, 2015 - link

    So...the last time you bothered to read anything was three years ago?
    In the real world, AMD already have the best open-source graphics drivers (mainly through hiring and paying your 'open-source fairies' so they could work full-time).
    The open RadeonSI driver is *already* faster than Catalyst in some cases, despite the focus still being on feature development rather than optimisation.
    The new amdgpu driver mentioned in the article has been in the mainline kernel for weeks.
  • TheinsanegamerN - Tuesday, December 22, 2015 - link

    Even if the open source driver is faster, it is still pathetically behind the windows drivers, as is evident of a 290 loosing to a 750ti in linux. That is unacceptable.
  • close - Wednesday, December 16, 2015 - link

    You'd have waited for DX12 a while were it not for Mantle.
  • Michael Bay - Wednesday, December 16, 2015 - link

    DX12 is a big selling point for win10 regardless of Mantle, which was irrelevant from the start, and even more irrelevant now.
  • BurntMyBacon - Wednesday, December 16, 2015 - link

    @Michael Bay: "DX12 is a big selling point for win10 ..."

    Of course it is. If you (MS) are going to put resources out to develop a new API, you are going to want to capitalize on it regardless of why you develop it or where the initial framework came from. I'm not saying DX12 wouldn't have happened without Mantle, but it likely would have been much different. It may not even have been low level, but rather another high level API with new features like pretty much all its predecessors (how much credit do you want to give Microsoft?). There is also a possibility that it would have launched after Windows 10. It wouldn't have been the first time, so @close may not be that far off base suggesting that you would have waited for DX12.

    Lest anyone get the wrong idea, ATi needed Microsoft to buy into the Mantle framework more than Microsoft needed the framework. ATi has had a hard time getting developers to develop around their features where nVidia has had much success. Consequently, ATi hardware does not perform nearly as close to its potential in these games as nVidia's counterparts. Getting DX12 standardized around a Mantlelike framework guarantees that ATi's hardware will perform much closer to its potential. While it shouldn't take more than a generation for nVidia to optimize their hardware to the new standard, at the very least, it is an area that ATi is not playing catch up.
  • loguerto - Thursday, December 17, 2015 - link

    Except freesync with the same method is dominating the market now, it is proven that good open/free initiatives are welcomed.
  • tubbymctubs - Tuesday, December 15, 2015 - link

    > AMDGPU itself is an open source kernel space driver – the heart of a graphics driver in terms of Linux driver design

    This is pretty untrue, the vast majority of a graphics driver on Linux is in userspace.
  • mickulty - Tuesday, December 15, 2015 - link

    In fairness the vast majority of a mammal isn't the heart.
  • przemo_li - Tuesday, December 15, 2015 - link

    One correction to the article.

    Catalyst already used open source kernel driver. Such licensing is demanded by licensing of Linux kernel itself. It was put to good use too, as someone from Arch Linux community was able to constantly provide support for newer kernel versions not yet supported by AMD. Sadly AMD Catalyst team never included those (or never done it in timely fashion).

    What is revolutionary, is that now it will be physically single component with dedicated team able to pick up any community work. But also AMD Catalyst developers now can do stuff inside open source community.
  • mooninite - Tuesday, December 15, 2015 - link

    Not exactly. The kernel driver provided in Catalyst, now Crimson, was not open source. It had a partially open kernel compiling infrastructure paired with a closed-source binary-only kernel module.

    The exact same thing that NVIDIA provides in their binary driver.
  • przemo_li - Wednesday, December 16, 2015 - link

    No. It was GPL licensed. Catalyst shipped with GPL licensed kernel module. (Still is, Catalyst not yet reached a point where they can switch to AMDGPU)
  • bridgmanAMD - Saturday, December 19, 2015 - link

    The Linux Catalyst kernel driver is made up of a BSD-ish licensed open source "Kernel Compatibility Layer" compiled on the user system plus a closed source binary component. Definitely not GPL licensed, although the KCL code may refer to "GPL plus additional rights", which is how BSD/X11-licensed code usually gets described in the kernel.
  • alyarb - Tuesday, December 15, 2015 - link

    Close to Metal all over again
  • ruthan - Tuesday, December 15, 2015 - link

    Slides are nothing we will see, their GPU driver is soo bad that even Valve disable AMD GPU in their Steam machines.
  • mrdude - Tuesday, December 15, 2015 - link

    Is this the 3rd or 4th time AMD has taken Linux drivers seriously in the past several years? I've lost count.
  • przemo_li - Wednesday, December 16, 2015 - link

    They never stopped taking it seriously ...

    I'm using r600g for quite a few years now. AMD was fully behind it all the time. Always cooking up new features. Always hiring new devs. Always expanding things that are possible in OpenSource.
  • mrdude - Wednesday, December 16, 2015 - link

    So they were hiring when their Linux GPU team was gutted?

    How about when they announced to open-source their newest line of GPUs, starting from Tonga, and have sat on it for about half a year now with utterly nothing in the way of improvements, including not supporting their Fiji GPUs for months after release?

    I'm confused. If AMD taking Linux seriously means their newest and most costly GPUs perform on the order of nVidia's low-end/mid-tier GPUs, and even Intel's on-die graphics, then I don't want to see just how horrendously things will go once they stop taking it seriously.
  • mdriftmeyer - Wednesday, December 16, 2015 - link

    Do some legwork and research the staff of Linux Devs. They've hired quite a few folks of late.
  • silverblue - Thursday, December 17, 2015 - link

    Every time I see somebody state that AMD have sacked loads of driver devs or marketing bods, I wait with baited breath for the links to any sort of proof yet come away disappointed (or not). They're probably right, but unfortunately, the net is full of people giving their opinions with little or no evidence to back it up.

    No offence intended mrdude; it's just nice to see links to articles.
  • mrdude - Thursday, December 17, 2015 - link

    This was discussed on various forums, including Phoronix. At one point, AMD had only a handful of people working on it. (In fact, at its lowest point I think the number amounted to just 2).

    Their Linux support is absolutely god awful, whether it's via catalyst or open source. Historically, you would be lucky if GPU-accelerated web browsing didn't cause a kernel dump. If you wanted to game on an AMD GPU, you may as well have checked yourself into the psych ward.

    The unified kernel driver was a great start, but it's all for naught unless there are actual improvements and AMD doesn't just reach parity with nVidia, but are then able to best them. Bear in mind, AMD has a long history of having abysmal support in Linux -- powerpoint presentations aren't going to change anyone's mind. Results, on the other hand, will be a great first step. Years of results will provide a compelling argument to go red over green.

    http://www.phoronix.com/scan.php?page=article&...

    "In the forums it was mentioned by John Bridgman of AMD that there is no legal/IP issues blocking the open-source power management support for these newer graphics processors. The issue is not enough developer resources... "The issue is writing the code and getting it working." The few AMD developers employed to work on the open-source code have their handsful with other tasks for the time being."

    It's a combination of Linux having near-zero market share and AMD having near-zero spare resources to dedicate to its development. Sure, Devinder Kumar seems like he's got a level head on his shoulders, but he doesn't s*** gold. Until AMD has enough cash -- and shows actual legitimate dedication -- I have zero hope that it will get any better.
  • mrdude - Thursday, December 17, 2015 - link

    Can't edit! :(

    Regarding the gutting of their Linux team, this happened during Read's tenure. Non-essential projects were cancelled or gutted to the bone, and that included Linux development.
  • bridgmanAMD - Saturday, December 19, 2015 - link

    At its lowest point the open source gfx team was one person, right after we hired Alex. The second-lowest point was two people, after we hired Richard. It's been going up consistently ever since then.
  • itsjustaprankbro - Wednesday, January 27, 2016 - link

    And yet, the "white screen of death" is still there. The suspend issues are still there. Power management is still a nightmare. Performance is still sub par. And not a single card has all the features green lighted in the feature matrix.

    Honestly? If I were an AMD exec, I would say ditch the entire Linux driver, because no matter how many devs and how much cash they throw at it, this thing will never work. I don't know Intel and Nvidia uses black magic - so their driver works, but it's just sad for AMD.

    Lastly, AMD is also the worst when it comes to proprietary drivers. You have a one-two gen old card? To hell with you, go buy a new one if you want drivers. What the hell is up with that? (I was a former AMD/Radeon owner, had several Radeon GPUs but this enraged me slightly when they started this driver support dropping.)
    New tech is the same.

    "Here, look Mantle, you want this. You NEED this. Buy GCN cards. It is da future."
    Ok, peep goes to shop, buys a new AMD card.
    "Oh, sorry bro, but Mantle is ded, and GCN1.1 is now the thing, you suck dude. Buy a new card!"

    I mean... come on!
  • itsjustaprankbro - Wednesday, January 27, 2016 - link

    Sidenote: There is also FreeBSD/BSD, where I was able to use Nvidia with SLI included years ago. (It was two 460 or something like that, and I installed the driver / enabled SLI in 3-4 commands.) Try using AMD cards there. Even on OpenBSD that supports the new (KMS) driver arch, the situation is a mess. And who uses OpenBSD anyway?
  • jasonelmore - Wednesday, December 16, 2015 - link

    about time for some linux drivers amirite?
  • OrphanageExplosion - Wednesday, December 16, 2015 - link

    And still the elephant in the room - sub-optimal CPU performance on the DX11 driver - remains unaddressed.
  • BurntMyBacon - Wednesday, December 16, 2015 - link

    @OrphanageExplosion: "And still the elephant in the room - sub-optimal CPU performance on the DX11 driver - remains unaddressed."

    Were you seriously expecting anything DX in a clearly Linux Driver oriented article? Wouldn't it be ironic if you got what you asked for in this context.
    ATi: "Hey, we fixed all of sub-optimal CPU performance issues in DX11 for our Linux driver"
    Gamer: "Sweet, Imma go play me some - Wait a minute. You say you fixed it in your Linux driver?"
    ATi: "Yup. Its open source too."
    Gamer: "Yeah, that's great and all, but I just want to play me some games. I didn't know that linux got DX games working natively."
    ATi: "They didn't"
    Gamer: "So, was it Valve that got it working on their steam boxes?"
    ATi: "Well, steam boxes are linux, so no."
    Gamer: "Then how do I use this new fangled DX11 super driver?"
    ATi: "You can't."
    Gamer: "Then why in the world did you develop it?"
    ATi: "You're the one who asked for DX11 CPU performance optimizations in an open source linux driver so you tell me."
  • atlantico - Wednesday, December 16, 2015 - link

    DX11 an API which nvidia designed its fermi and maxwell architecture around will never be as good on AMD GPUs, it just can't. But that's ok, in the long run, since DX11 performance is very good nevertheless on AMD GPUs and it is a tech that will be obsolete in the near future. The performance disparity will also be irrelevant, solved through brute force really with newer AMD GPUs.

    DX12 is already designed with AMD GPUs in mind, that's the Mantle legacy. For the future AMD is in an amazing position for DX12 and DX11 will perform better than anyone needs on those older games.
  • Macpoedel - Wednesday, December 16, 2015 - link

    All DirectX editions are Microsoft API's, I don't know why you're saying Nvidia designed it. Anyway the point is that DX11 is more CPU bottlenecked with AMD GPU's than with Nvidia GPU's, and that has nothing to do with DX11 favoring one side more than the other, it's just AMD's DX11 drivers that are more CPU dependent.
  • silverblue - Thursday, December 17, 2015 - link

    Multithreading in DX11 doesn't appear to be mandatory, but it does obviously help and would help alleviate the CPU limitations as regards AMD cards. I'm wondering what sort of work would be required to implement it.

    In lightly-threaded games it wouldn't be so bad, I suppose.
  • itsjustaprankbro - Wednesday, January 27, 2016 - link

    And yet, AMD still does not have a single GPU that supports DX12 full feature set.
    A good joke, I say.

    Not to be a fanboy, just saying that this should have been the no.1 priority when they came out with the new cards.
  • pcfxer - Wednesday, December 16, 2015 - link

    Nope. Too little too late. nVidia it is and I'm not looking back.
  • loguerto - Thursday, December 17, 2015 - link

    Raja is doing a great job, separating Radeon group form the rest of the of the company and giving the lead to one of the best graphic architects around, helps to define clear paths for the future. For now I am very happy to see where AMD Radeon group is pointing, and I really hope they will succeed.
  • TheinsanegamerN - Tuesday, December 22, 2015 - link

    I'll believe it when AMD actually manages to deliver the drivers ON TIME. Not a year and a half later. Till then, team green all the way.
  • loguerto - Thursday, December 24, 2015 - link

    Thankfully with the newer graphical APIs the drivers will have marginal influence in the overall application performance. However unifying and opening both windows ad linux drivers is a great news. Linux users deserve much more than AMD offered in the las years.
  • loguerto - Thursday, December 24, 2015 - link

    GPUopen on the other side is Great news! In my opinion nvidia's alternative, gameworks, is hurting the industry much more than helping it, as most of the games the implements it, for a reason or an other, they run like crap. I am sure that competition will help improve this situation.
  • lsatenstein - Sunday, January 10, 2016 - link

    For the past 10 years, and most of my computer systems, I've used ati/amd hardware. Graphics cards worked out of the box. At the time, the price difference between AMD and Intel CPUs was not that great. Today, I will purchase AMD because, 3 AMD systems will cost me less than two equivalent Intel systems.

    With the world moving to IoT, I am holding back on purchasing expensive (1200$+) systems.

    In fact, I would really like to buy computers where the components are second sourced.

Log in

Don't have an account? Sign up now