My Three Hopes For AMD's Open-Source Stack The Rest Of 2017

[whitecat]

My two hopes, as a crypto miner user, is :
- rocm-smi being able to undervolt the vcore
- rocm being able to run on non pcie atomics processor and port, that means low cost Celeron and pcie 2.0 @1x ports.

[ownaginatious]

Just curious, what was the "huge pain" associated with using a kernel from agd5f's staging tree ? Are there specific config options or non-upstream patches required for Arch which precluded use of agd5f's staging tree or one of the repos built from those trees ?

Sorry, it was an overstatement to refer to it as a huge pain. The issue is mostly with the fact that the kernel is only as up-to-date as agd5f's tree is, and it was only until fairly recently that a 4.11 branch was created. I suppose this isn't a big deal to anyone who frequently compiles their own kernel, but it's just simply another thing I'd rather not deal with at the moment.

what load of bullshit. in what world is it easier to live with proprietary shit instead of with alternative kernel package?

Well, with the proprietary Nvidia drivers, I get performance that's basically on par with Windows and working HDMI 2.0 + HDMI audio. Driver updates are also fairly regular and in my experience, bugs/issues reported on their forums are usually addressed quickly. Under Arch Linux, installation is literally just "sudo pacman -S nvidia", and then the package is automatically kept up to date with normal system updates from then on out. So for someone who is more concerned about having something that works well over something that's open source, I'd say it's much easier to live with.

Don't get me wrong, I'm all for open-source drivers and am totally fine with switching back to an AMD GPU if the issues get worked out, but I'm also not going to act like using proprietary drivers is the equivalent of selling my soul to the devil either...

---

Anyway back to the topic of DAL/DC being merged, I'm really curious as to how this is going to work. Both sides of the argument make sense to me: AMD wanting to keep their code DRY and the kernel not wanting HALs to prevent a rats nest that non-AMD devs can't contribute to. How is this being sold to the business? I feel like the AMD devs telling the business "yeah, we gotta rewrite a lot of our universal driver specifically for this Linux platform that only a small fraction of the market uses on their desktop/laptop" isn't going to be prioritized very highly. Maybe I have the wrong impression of the issues here :/

[bridgman]

Anyway back to the topic of DAL/DC being merged, I'm really curious as to how this is going to work. Both sides of the argument make sense to me: AMD wanting to keep their code DRY and the kernel not wanting HALs to prevent a rats nest that non-AMD devs can't contribute to. How is this being sold to the business? I feel like the AMD devs telling the business "yeah, we gotta rewrite a lot of our universal driver specifically for this Linux platform that only a small fraction of the market uses on their desktop/laptop" isn't going to be prioritized very highly. Maybe I have the wrong impression of the issues here :/

If we rewrite the code for Linux only that defeats the purpose of having common code in the first place, which was to let Linux open source users have access to more display features and better-tested code than the Linux PC business could otherwise afford.

What we need to do is restructure the code to make it align with the latest upstream AND fit that new design back into drivers for the other OSes and diag frameworks. That allows us to keep picking up new code as we add support for future hardware and display features.

[Michael]

If i remember it correctly is was my suggestion and assessment that it would need at minimum 6 month to get any result.
I am very good in predicting the future but i can not always be right and sometimes people take some "predictions" to seriously.
i also wonder why people mix up my forum posts with your forum posts but they also did this in the past to...

Michael: "It also remains unlikely that AMD would drop AMDGPU-PRO, contrary to popular comments in our forums and elsewhere. AMDGPU-PRO is still important for workstation users and those needing OpenGL with compatibility profile support."

I call this Corporatism Propaganda to sell expensive FireGL/FirePro class Workstation hardware and to promote and trap people into the closed source world by broken software by design fixed by closed source driver scam.

What we really need is a strategy/tactic to escape from this trap and to fix the bugs in the source place of the bug. instead of workaround hacks in the driver for broken software.

No, qarium , my comment was not based on any information you said... bridgman it was based on what was said in another conf call last year arranged I believe from Edelman.... If interested I could probably dig up the email of the call participants for who said it, as with not getting too many AMD press briefings, should be able to locate it.

[geearf]

My 2 wishes without thinking too much:

- More performance improvements (nothing in particular, any % is great!).

- Full official support of SI cards in amdgpu, including uvd, audio and whatever I'm not thinking of that exists in radeon

[Sevard]

Well, with the proprietary Nvidia drivers, I get performance that's basically on par with Windows and working HDMI 2.0 + HDMI audio. Driver updates are also fairly regular and in my experience, bugs/issues reported on their forums are usually addressed quickly. Under Arch Linux, installation is literally just "sudo pacman -S nvidia", and then the package is automatically kept up to date with normal system updates from then on out. So for someone who is more concerned about having something that works well over something that's open source, I'd say it's much easier to live with.

Some time ago I installed openSUSE Tumbleweed (Ubuntu was unstable and outdated, so I wanted to switch to something stable, easy to use and up to date) on machine with NVIDIA GPU. Image that I downloaded had kernel 4.10. It turned out that nouveau was buggy at that time and NVIDIA official driver didn't support kernel 4.10. I needed use workaround for few weeks until the issue was fixed. At the same time on my other machines with AMD and Intel GPUs everything worked fine. So no - NVIDIA binary blob isn't much easier to live with. If you use rolling distro and try to keep everything up to date, then binary blobs (both from NVIDIA and AMD) are pain in the ass.

[aufkrawall]

On Tumbleweed yes, on Arch no.
Usually only minor changes are needed to make compiling of the NV driver successful in case of trouble. In such cases users usually provide patches which you can add to the nvidia-beta-dkms package in the AUR. And Arch usually doesn't even roll out new kernels as long as there is trouble with the Nvidia driver (and others).
Problem is that there is no maintainer for Nvidia drivers on Tumbleweed.

[Sevard]

Usually only minor changes are needed to make compiling of the NV driver successful in case of trouble.

I tried those minor changes and they didn't help.

And Arch usually doesn't even roll out new kernels as long as there is trouble with the Nvidia driver (and others).

That's why I don't use Arch. When I use rolling distribution I don't want to wait few weeks till somebody fixes issues with major components.

Problem is that there is no maintainer for Nvidia drivers on Tumbleweed.

From my point of view it's not openSUSE issue, but NVIDIA's one. If they don't want to make their drivers compatible with all recent distros, then I really don't need to use their hardware. Fortunately I have alternatives that work out of the box.

[Danny3]

"My Three Hopes For AMD's Open-Source Stack..."
These are exactly my hopes too for AMD, especially the first 2 ones
*Open-Source Vulkan Driver
This would be great for performance and I think it will help many game developers to choose Vulkan API, less pain a game devellper has -> better Vulkan adoption
I think it would be better for Steam too, which in turn is better for Linux, which in turn is better for AMD too
I believe nowadays everybody who wants to use Linux to its fullest, without pain, know that it must buy an AMD graphics card
I think that the adoption of Vulkan, SteamOS/machines, Linux goes hand in hand with the open source AMD driver, the better the performance and quality of the driver -> the better the adoption of those technologies/devices.
I don't get why would they develop Vulkan and donate it to Khronos, but not make the best open source driver for it.
This makes not sense to me, why would anyone not make the last step of a great thing.

*Mainlining DC (DAL)
The only thing that makes me switch from Nvidia and by only AMD GPUs in the future is that I want a system with open source software and they have an open surce driver.
I initially thought that the open source driver will allow you to use the full capability of the graphics card, the same way the closed source driver, but I keep hearing the audio doesn't work because of this DAL missing.
I have a Nvidia GTX 650 on my main desktop computer with Windows 7 which passes the sound to a 5.1 AV receiver to watch movies with Kodi as in a cinema.
I'm planning to ditch Nvidia in the future and buy an AMD RX 480 because of its awesome open source driver performance on Linux.
Since Microsoft is using any method to stop supporting Windows 7 and they will completely stop supporting it in the future, I'm sure I'll have to switch to Linux completely one day.
For this I need GPU with great open source drive like RX 480.
Since Kodi works on Linux too and I'm planning to continue watching movies in the same configuration, with the AV receiver connected to one of the HDMI ports on the GPU, I need audio over HDMI.
I don't have any other speakers.
So for me, no audio over HDMI is a deal-breaker and I will be forced to buy Nvidia once again.
I don't care if AMD has audio over HDMI in their closed source driver.
The whole point of buying and AMD GPU for me is to use it with the open source driver.
So I hope AMD will hurry up and solve this problem before the next Ubuntu LTS which will be the basis of next Linux Mint, the distro I'll be using.

[aufkrawall]

I tried those minor changes and they didn't help.

They did for me and others.

That's why I don't use Arch. When I use rolling distribution I don't want to wait few weeks till somebody fixes issues with major components.

Then you're wrong on Tumbleweed as well, they still haven't rolled Qt 5.8.

From my point of view it's not openSUSE issue, but NVIDIA's one. If they don't want to make their drivers compatible with all recent distros, then I really don't need to use their hardware. Fortunately I have alternatives that work out of the box.

The driver is distribution-agnostic.