Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

phoronix.com

Post reply on HN
Print view View original

11–20 of 65 posts

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#11

Post by spockz »

bayindirh wrote: post #8
seanhunter wrote: post #5

It blows my mind how reliably AMD shoots itself in the foot. What we want isn’t that hard: 1) Support your graphics cards on linux using kernel drivers that you upstream. All of them. Not just a handful - all the ones you sell from say 18 months ago till today. 2) Make GPU acceleration actually work out of the box for pytorch and tensorflow. Not some special fork, patched version that you “maintain” on your website,…

AMD has two driver teams at this point. One of Linux/Open Source, one for Catalyst/Closed source, and they are not allowed to interact. Because, there are tons of IP and trade secrets involved in driver development and optimization. Sometimes game related, sometimes for patching a rogue application which developers can't or don't fix, etc. etc. GPU drivers are ought to be easy, but in reality, they are not. The open…

I accept that there are two teams for reasons that include IP. However, Nvidia must have the same problem and they appear not to be hamstrung by it. So what is the difference?

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#12

Post by rwmj »

bayindirh wrote: post #8
seanhunter wrote: post #5

It blows my mind how reliably AMD shoots itself in the foot. What we want isn’t that hard: 1) Support your graphics cards on linux using kernel drivers that you upstream. All of them. Not just a handful - all the ones you sell from say 18 months ago till today. 2) Make GPU acceleration actually work out of the box for pytorch and tensorflow. Not some special fork, patched version that you “maintain” on your website,…

AMD has two driver teams at this point. One of Linux/Open Source, one for Catalyst/Closed source, and they are not allowed to interact. Because, there are tons of IP and trade secrets involved in driver development and optimization. Sometimes game related, sometimes for patching a rogue application which developers can't or don't fix, etc. etc. GPU drivers are ought to be easy, but in reality, they are not. The open…

A laundry list of excuses ... or a list of things to work on. ("Why the hell do we have two driver teams?" - would be my #1 thing to fix if I was at AMD.)

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#13

Post by bayindirh »

spockz wrote: post #11
bayindirh wrote: post #8

Earlier quoted context omitted.

AMD has two driver teams at this point. One of Linux/Open Source, one for Catalyst/Closed source, and they are not allowed to interact. Because, there are tons of IP and trade secrets involved in driver development and optimization. Sometimes game related, sometimes for patching a rogue application which developers can't or don't fix, etc. etc. GPU drivers are ought to be easy, but in reality, they are not. The open…

I accept that there are two teams for reasons that include IP. However, Nvidia must have the same problem and they appear not to be hamstrung by it. So what is the difference?

NVIDIA and AMD, from my experience, have completely different cultures.

ATI started as a much more closed company. Then, they pivoted and started to open their parts. They were hamstrung at the HDCP at one point, and they decided to decouple HDCP block from video accelerators at silicon level to allow open source drivers to access video hardware without leaking/disabling HDCP support. So, they devoted to open what they have, but when you have tons of legacy IP, things doesn't go from 0 to 100 in a day. I want to remind that "game dependent driver optimization" started pre 2000s. This is how rooted these codebases are.

NVIDIA took a different approach, which was being indifferent on the surface, but their hardware became a bit more hostile at every turn towards nouveau. Then they released some specs to allow "hardware enablement" by nouveau, so closed source drivers can be installed, and the card didn't blank-screened at boot.

Then, as they fought with kernel developers, with some hard prodding by Kernel guys and some coercing by RedHat, NVIDIA accepted to completely remove "shim" shenanigans, and moved closed bits of the kernel module to card firmware by revising card architecture. It's important to keep in mind that NVIDIA's open drivers means "an open, bare bones kernel module, a full fledged and signed proprietary firmware which can be used by closed source drivers only and a closed source GLX stack", where in AMD this means "An open source kernel module, standard MESA libraries, and a closed source firmware available to all drivers".

It was in talks with nouveau guys to allow them to use the full powered firmware with clock and power management support, but I don't know where it went.

The CUDA environment is also the same. Yes it works very well, and it's a vast garden, but it's walled and protected by electrified fence and turrets. You're all in, or all out.

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#14

Post by bayindirh »

rwmj wrote: post #12
bayindirh wrote: post #8

Earlier quoted context omitted.

AMD has two driver teams at this point. One of Linux/Open Source, one for Catalyst/Closed source, and they are not allowed to interact. Because, there are tons of IP and trade secrets involved in driver development and optimization. Sometimes game related, sometimes for patching a rogue application which developers can't or don't fix, etc. etc. GPU drivers are ought to be easy, but in reality, they are not. The open…

A laundry list of excuses ... or a list of things to work on. ("Why the hell do we have two driver teams?" - would be my #1 thing to fix if I was at AMD.)

I guess that you don't understand that how silicon and 3rd party IP works. It took Intel a completely new GPU from scratch to be able to open drivers. AMD did at least one revision to their silicon to enable that kind of openness.

Yet, HDMI forum said that they can't implement an HDMI2.1 capable driver in the open, with some nasty legal letters.

I have a couple of friends who wrote 3D engines from scratch and debugged graphics drivers for their engines for a living. It's a completely different jungle filled with completely different beasts.

I think being able to call glxinfo on an AMD card running with completely open drivers and being able to see extensions from NVIDIA, AMD, SGI, IBM and others is a big win already.

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#15

Post by transpute »

throwaway48476 wrote: post #9

If AMD does deliver on client dGPU virtualization it would be amazing.

Some old AMD workstation GPUs supported SR-IOV, that repo was just archived.

https://open-iov.org/index.php/GPU_Support#AMD

https://github.com/GPUOpen-LibrariesAndSDKs/MxGPU-Virtualiza...

As "AI" use cases mature, NPU/AIE-ML virtualization will also be needed.

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#16

Post by onli »

bayindirh wrote: post #8
seanhunter wrote: post #5

It blows my mind how reliably AMD shoots itself in the foot. What we want isn’t that hard: 1) Support your graphics cards on linux using kernel drivers that you upstream. All of them. Not just a handful - all the ones you sell from say 18 months ago till today. 2) Make GPU acceleration actually work out of the box for pytorch and tensorflow. Not some special fork, patched version that you “maintain” on your website,…

AMD has two driver teams at this point. One of Linux/Open Source, one for Catalyst/Closed source, and they are not allowed to interact. Because, there are tons of IP and trade secrets involved in driver development and optimization. Sometimes game related, sometimes for patching a rogue application which developers can't or don't fix, etc. etc. GPU drivers are ought to be easy, but in reality, they are not. The open…

Fact of the matter is that I have a Radeon RX 6600, which I can't use with ollama. First, there is no ROCm at all in my distros repository - it doesn't compile reliably and needs too many ressources. Then, when compiling it manually, it turns out that ROCm doesn't even support the card in the first place.

I'm aware that 8GB Vram are not enough for most such workloads. But no support at all? That's ridiculous. Let me use the card and fall back to system memory for all I care.

Nvidia, as much as I hate their usually awfully insufficient linux support, has no such restrictions for any of their modern cards, as far as I'm aware.

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#17

Post by markus_zhang »

bayindirh wrote: post #14
rwmj wrote: post #12

Earlier quoted context omitted.

A laundry list of excuses ... or a list of things to work on. ("Why the hell do we have two driver teams?" - would be my #1 thing to fix if I was at AMD.)

I guess that you don't understand that how silicon and 3rd party IP works. It took Intel a completely new GPU from scratch to be able to open drivers. AMD did at least one revision to their silicon to enable that kind of openness. Yet, HDMI forum said that they can't implement an HDMI2.1 capable driver in the open, with some nasty legal letters. I have a couple of friends who wrote 3D engines from scratch and debugge…

Thanks. All these sound interesting.

What does the 3d engine look like? Custom made AAA in companies such as EA or Ubisoft?

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#18

Post by markus_zhang »

bayindirh wrote: post #13
spockz wrote: post #11

Earlier quoted context omitted.

I accept that there are two teams for reasons that include IP. However, Nvidia must have the same problem and they appear not to be hamstrung by it. So what is the difference?

NVIDIA and AMD, from my experience, have completely different cultures. ATI started as a much more closed company. Then, they pivoted and started to open their parts. They were hamstrung at the HDCP at one point, and they decided to decouple HDCP block from video accelerators at silicon level to allow open source drivers to access video hardware without leaking/disabling HDCP support. So, they devoted to open what th…

I'm wondering how much effort went into RE Nvidia cards and drivers. Graphics card drivers are completely a mythical beast to me, and I guess it's one of the most complicated drivers in the hardware world.

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#19

Post by bavell »

seanhunter wrote: post #5

It blows my mind how reliably AMD shoots itself in the foot. What we want isn’t that hard: 1) Support your graphics cards on linux using kernel drivers that you upstream. All of them. Not just a handful - all the ones you sell from say 18 months ago till today. 2) Make GPU acceleration actually work out of the box for pytorch and tensorflow. Not some special fork, patched version that you “maintain” on your website,…

Sucks that you've had so much trouble... My experience with my cheap 6750XT is that it just works OOTB on Arch with rocm, llama.cpp, ollama, whisper, etc by setting an envvar.

Re: AMD Publishes Open-Source Driver for GPU Virtualization, Radeon "In the Roadmap"

#20

Post by gessha »

bayindirh wrote: post #14
rwmj wrote: post #12

Earlier quoted context omitted.

A laundry list of excuses ... or a list of things to work on. ("Why the hell do we have two driver teams?" - would be my #1 thing to fix if I was at AMD.)

I guess that you don't understand that how silicon and 3rd party IP works. It took Intel a completely new GPU from scratch to be able to open drivers. AMD did at least one revision to their silicon to enable that kind of openness. Yet, HDMI forum said that they can't implement an HDMI2.1 capable driver in the open, with some nasty legal letters. I have a couple of friends who wrote 3D engines from scratch and debugge…

But who holds these patents? And what are they about?
Post reply on HN