Live data from Hacker News

AMD Open Source Driver for Vulkan

phoronix.com

51–60 of 65 posts

Re: AMD Open Source Driver for Vulkan

#51
post #6

AMD has been working for years to make them the most Linux friendly GPU option. Sadly the legacy of the Linux community talks like AMD doesn't work in Linux and NVIDIA is the only real choice. Kind of like Windows users complaining about AMD drivers when they haven't been an issue for over five years. I had AMD on my Linux boxes for eight years and I have haven't had an issue for the past six years.

> Sadly the legacy of the Linux community talks like AMD doesn't work in Linux and NVIDIA is the only real choice.

Not in my experience. AMD efforts are welcomed by Linux community, especially gamers.

See trends here (AMD GPU usage is growing): https://www.gamingonlinux.com/users/statistics#trends

Re: AMD Open Source Driver for Vulkan

#52
post #6

AMD has been working for years to make them the most Linux friendly GPU option. Sadly the legacy of the Linux community talks like AMD doesn't work in Linux and NVIDIA is the only real choice. Kind of like Windows users complaining about AMD drivers when they haven't been an issue for over five years. I had AMD on my Linux boxes for eight years and I have haven't had an issue for the past six years.

While NVIDIA is far from the only choice and AMD has improved dramatically these days to the point where they are within NVIDIA's performance reach, NVIDIA still dominates the higher end side [1] and they do have by far the most complete and stable OpenGL implementation (with the Mesa front end on AMD you do not even get a compatibility profile - a major disaster IMO - whereas on the other hand NVIDIA not only gives…

Mesa definitely support compatibilty profile, I use OpenGL 1.x applications on RX580.

Re: AMD Open Source Driver for Vulkan

#53

Earlier quoted context omitted.

While NVIDIA is far from the only choice and AMD has improved dramatically these days to the point where they are within NVIDIA's performance reach, NVIDIA still dominates the higher end side [1] and they do have by far the most complete and stable OpenGL implementation (with the Mesa front end on AMD you do not even get a compatibility profile - a major disaster IMO - whereas on the other hand NVIDIA not only gives…

Mesa definitely support compatibilty profile, I use OpenGL 1.x applications on RX580.

The OpenGL compatibility profile is something very specific: it is defined by the OpenGL spec as a variation of a 3.x context that is modified to also support all obsolete features of OpenGL 2.1 (as opposed to a core context that drops all the quaint immediate drawing and matrix stack functions among others). It defines a few of the OpenGL 3.x features deliberately differently than a core 3.x context to keep backwards compatibility while providing most new features. This type of context was defined to help migrate applications forward. There's a lot of old OpenGL rendering code in CAD and DCC tools that is barely maintained and these vendors pushed the compatibility profile into the specification.

Re: AMD Open Source Driver for Vulkan

#54
post #40
post #20

Earlier quoted context omitted.

CUDA is made by nvidia

Not sure why you were down voted. CUDA is developed by NVIDIA. CUDA is a registered trademark by NVIDIA - https://trademarks.justia.com/850/30/cuda-85030071.html Here is the CUDA webpage https://developer.nvidia.com/cuda-zone

Because it's a pointless answer that basically just repeats part of the question, providing absolutely no new information.

Re: AMD Open Source Driver for Vulkan

#55
post #34
post #10

Earlier quoted context omitted.

> 2003 You had a problem with ATI's closed-source driver 14 years ago. AMD's open-source driver now is a COMPLETELY different story.

Yes, and it was bad enough that I decided to never ever buy from that company again. For the record, I did have the displeasure of using an AMD GPU in 2010, because that's what my employer at the time purchased, and it was only slightly more stable. I am absolutely convinced that nobody except nVidia can produce stable, working video drivers. The last 14 years haven't produced a counter-example.

I had a bad experience with an ATI card many years ago with a Ubuntu box. And line you, I said that I would never buy an ATI GPU. Actually my computer have a RX580 and work like a dream (On windows and Linux)

Re: AMD Open Source Driver for Vulkan

#56
post #7
post #6

AMD has been working for years to make them the most Linux friendly GPU option. Sadly the legacy of the Linux community talks like AMD doesn't work in Linux and NVIDIA is the only real choice. Kind of like Windows users complaining about AMD drivers when they haven't been an issue for over five years. I had AMD on my Linux boxes for eight years and I have haven't had an issue for the past six years.

>to make them the most Linux friendly GPU option. Intel works quite fine. I'm pretty sure it's just nVidia that's the problem.

Agreed; but they were probably referring to big beefy GPUs, so you only have team green and team red.

Re: AMD Open Source Driver for Vulkan

#57
post #39

Earlier quoted context omitted.

Semi-relatedly and unfortunately, AI research is locked-in to NVIDIA (on Linux) because all the big lienar algebra and autodifferentiation frameworks work only with CUDA.

AMD is working on ROCm https://rocm.github.io/ It will be an open source answer to CUDA and I hope this will now get more support. "We are excited to present ROCm, the first open-source HPC/Hyperscale-class platform for GPU computing that’s also programming-language independent. We are bringing the UNIX philosophy of choice, minimalism and modular software development to GPU computing. The new ROCm foundation lets yo…

Does anyone here know how fqr along this effort is? Is it usable today (in the sense that one could develop TF backend which uses ROCm)?

Re: AMD Open Source Driver for Vulkan

#58
post #53

Earlier quoted context omitted.

Mesa definitely support compatibilty profile, I use OpenGL 1.x applications on RX580.

The OpenGL compatibility profile is something very specific: it is defined by the OpenGL spec as a variation of a 3.x context that is modified to also support all obsolete features of OpenGL 2.1 (as opposed to a core context that drops all the quaint immediate drawing and matrix stack functions among others). It defines a few of the OpenGL 3.x features deliberately differently than a core 3.x context to keep backward…

[deleted]

Re: AMD Open Source Driver for Vulkan

#59

Earlier quoted context omitted.

I'm curious - what would you need OpenGL compatibility profile for?

Regardless of what i'd personally need it for, it is still something that NVIDIA's drivers provide and AMD/Mesa lack and thus a negative on Mesa's side (especially considering that NVIDIA not only provides all that extra stuff but they still manage to be faster than the implementations - like Mesa and Apple - that do not). Now as for what I would need the compatibility profile, it is very simple: i just find it more…

The hard truth is that OpenGL 3.0 was far too tame when it came to breaking compatibility. Initially, they tried to design something much closer to Vulkan (back in 2008!), but ended up with a far too conservative final specification to make backwards compatibility possible. The disappointment among OpenGL users after the release of the final 3.0 specification was very real.

If you have a good understanding of how GPUs actually work (of which the OpenGL pipeline is just a very crude and simplistic abstraction), you can understand why modern APIs like Vulkan and DX12 are the way they are and also the power they hand to a capable user.

The hardware model underlying the design of OpenGL has aged. The one used for 1.0 and 1.1 is so outdated now that using it runs exactly counter to what the driver needs to do on hardware built within the last 15 years. The story gets a bit better once you get to vertex buffers, but those are not exposed in a way that lets the driver handle them without any guesswork on its part. The same is true for textures and framebuffers. Even that damned global OpenGL state is a quint relic of the past. Modern drivers should get the desired new state all at once instead of piecemeal through a chain of calls that triggers expensive recomputation of the desired actual GPU hardware state at each step.

Instead of clinging to OpenGL 1.x or 2.x for no good reason, you should really switch to a high level drawing library or rendering engine that knows how to pass things properly to an underlying modern API.

Re: AMD Open Source Driver for Vulkan

#60
post #49

Earlier quoted context omitted.

I built a new system recently, Ryzen 7 with an AMD Vega 64... I've yet to get the Vega 64 to work right with Debian Testing (Or Ubuntu 17.10/16.04). I am hoping I have some time to fiddle with it and maybe get it working before Christmas :)

Vega cards will be supported in Linux 4.15 onwards with mesa drivers. Linux 4.12, 4.13, and 4.14 do support Vega cards but not for display output. You'll have to use AMD's proprietary drivers for now.

I plan to try the 4.15 rc. But then I don't know for what all I need on top of that. Phoronix has some articles on the topic, but they don't provide much specifics.

I did try their proprietary drivers, too, but did not have any luck. Maybe I'll have time to tinker with it tomorrow. It would have been nice to have out of the box support :) I suppose they will get there eventually.

Post reply on HN