AMD Open Source Driver for Vulkan

Post by bayindirh » Wed, Jan 23, 2019, 6:07 AM UTC

shmerl wrote: post #106

bayindirh wrote: post #16

Earlier quoted context omitted.

AMD beta tester here. AMD separated HDCP and DRM related silicon from video acceleration units some time ago to be able to open source their GPUs completely sans the NDA bound stuff. Even this is a very big generosity and step from them for the Linux community. I'm sure that the firmware contains some highly proprietary and revealing information about some of their secret sauce. So, they won't be able to do it even i…

There is no secret sauce in the firmware, but it has HDCP garbage (which is causing it to remain a blob). AMD could provide one without HDCP as an open option, but I suppose they didn't see enough demand for it.

Post by sitkack » Wed, Jan 23, 2019, 6:14 AM UTC

AsyncAwait wrote: post #92

beezischillin wrote: post #64

Earlier quoted context omitted.

If the new 3rd generation Ryzen stuff ends up being as good as it looks, then I'd say we're in for a good year as far as mobile AMD hardware's concerned. There's a good chance that you have nothing to worry about as far as upgrade paths are considered.

I hope so, but my current laptop has a desktop-class Ryzen 7 1700 in it and their mobile offerings usually come with half as many cores, but I guess we'll see what Ryzen 3 has to offer.

Post by shmerl » Wed, Jan 23, 2019, 6:33 AM UTC

bayindirh wrote: post #141

shmerl wrote: post #106

Earlier quoted context omitted.

There is no secret sauce in the firmware, but it has HDCP garbage (which is causing it to remain a blob). AMD could provide one without HDCP as an open option, but I suppose they didn't see enough demand for it.

I think it also had the clocks, memory settings, thermal thresholds and other hardware tuning parameters. So opening the firmware may also lead to many many fried boards. Also, if the core enablement and configuration is done in the firmware, some vendors may find themselves in a hard position, since they may be selling crippled GPUs as lower spec cards. Last, but not the least if folks enable faulty CUs in their car…

Post by bayindirh » Wed, Jan 23, 2019, 6:50 AM UTC

shmerl wrote: post #145

bayindirh wrote: post #141

Earlier quoted context omitted.

I think it also had the clocks, memory settings, thermal thresholds and other hardware tuning parameters. So opening the firmware may also lead to many many fried boards. Also, if the core enablement and configuration is done in the firmware, some vendors may find themselves in a hard position, since they may be selling crippled GPUs as lower spec cards. Last, but not the least if folks enable faulty CUs in their car…

You can fry the hardware even now, if you set fan curve incorrectly, or create some other power management mess. Opening up firmware isn't really affecting that. In the end, opening it up isn't any worse than opening up the kernel driver to begin with (you could apply similar arguments to that). And AMD were OK with it, and from what I've heard, DRM is really the main issue here. As usual, media lobby poisoned the te…

Post by shmerl » Wed, Jan 23, 2019, 6:57 AM UTC

bayindirh wrote: post #147

shmerl wrote: post #145

Earlier quoted context omitted.

You can fry the hardware even now, if you set fan curve incorrectly, or create some other power management mess. Opening up firmware isn't really affecting that. In the end, opening it up isn't any worse than opening up the kernel driver to begin with (you could apply similar arguments to that). And AMD were OK with it, and from what I've heard, DRM is really the main issue here. As usual, media lobby poisoned the te…

I think you won't be able to override the emergency shutdown thresholds in the firmware. I'm a big free and open software advocate. I primarily use free and open source software, and try to open every line of code I write. I'd like to see the firmware on the open like the drivers. I just wanted to talk my understanding of hardware. If my comments sounded otherwise, I'm sorry, my bad.