Live data from Hacker News

AMD Open Source Driver for Vulkan

github.com

171–180 of 181 posts

Re: AMD Open Source Driver for Vulkan

#171
post #140

Earlier quoted context omitted.

Khronos learned too late that the world has moved on and the community wanted to use something else other than C to program their GPGPUs. And they are doing it again with Vulkan. With a large majority looking for higher level wrappers instead of dealing directly with its APIs and increasing number of extensions.

> and the community wanted to use something else other than C to program their GPGPUs. This assertion makes no sense. The whole reason why these APIs are specified based on C is that once a C API is available its trivial to develop bindings in any conceivable language. You can't do that if you opt for a flavor of the month. Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain. Th…

> Furthermore, GPGPU applications are performance-driven, and C is unbeatable in this domain.

CUDA is clearly performance driven, and is a more mature C++ model.

Template functions are a type-safe way to build different (but similar) compute kernels. Its far easier to use C++ Templates Constexpr and whatever to generate constant-code than to use C-based macros.

In practice, CUDA C++ beats OpenCL C in performance. There's a reason why it is so popular, despite being proprietary and locked down to one company.

Re: AMD Open Source Driver for Vulkan

#172
post #140

Earlier quoted context omitted.

> No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). To be fair, only Intel has good OpenCL 2.0+ support. NVidia isn't really pushing OpenCL and AMD's ROCm OpenCL driver is still a bit unstable. AMD's OpenCL 2.0 support has always been poor. The Windows OpenCL 2…

Khronos learned too late that the world has moved on and the community wanted to use something else other than C to program their GPGPUs. And they are doing it again with Vulkan. With a large majority looking for higher level wrappers instead of dealing directly with its APIs and increasing number of extensions.

Honestly, I think I can live with the C thing to program GPGPUs.

The real issue IMO was the split-source. CUDA's single source or HCC's single-source means all your structs and classes work between the GPU and CPU.

If you have a complex datastructure to pass data between the CPU and GPU, you can share all your code on CUDA (or AMD's HCC). But in OpenCL, you have to write a C / C++ / Python version of it, and then rewrite an OpenCL C version of it.

OpenCL C is driven by this interpreter / runtime compiler thingy, which just causes issues in practice. The compiler is embedded into the device driver.

Since AMD's OpenCL compiler is buggy, this means that different versions of AMD's drivers will segfault on different sets of code. As in, your single OpenCL program may work on 19.1.1 AMD Drivers, but it may segfault on version 18.7.2.

The single-source compile-ahead-of-time methodology means that compiler bugs stay in developer land. IIRC, NVidia CUDA also had some bugs, but you can just rewrite your code to handle it (or upgrade your developer's compilers when the fix becomes available).

That's simply not possible with OpenCL's model.

Re: AMD Open Source Driver for Vulkan

#173
post #54

Earlier quoted context omitted.

yes, the firmware is the same regardless of your OS. think of it like using an open-source client for slack: it still hits the API of a closed blob (the slack servers).

Thx! Then, if the performance is "worse" or "better" for a specific OS, it's just because the code of the open-source part (kernel and/or userland progs) and/or the app (game/application/whatever) is not written as well as on the other OSs, right? Indirectly asking as well: even if the firmware is alway the same one, there is no "part" of the firmware that is dedicated to only a specific OS?

performance differences come down to how the driver utilizes the firmware, or how the applications utilize the driver. there may be some other factors, like how the OS manages memory buffers.

it's unlikely that the firmware has OS-specific code. it's more likely that the firmware exposes functionality that happens to be taken advantage of by one OS' drivers more than it is by another OS' drivers -- perhaps in part because of differences in driver execution models on different kernels. or sometimes (as with nvidia) because a proprietary closed-source windows driver was written by the company with access to private documentation of all the firmware's features while the community-written linux OSS driver was written with incomplete knowledge of the firmware's features derived from reverse engineering.

Re: AMD Open Source Driver for Vulkan

#174
post #82

A lot of people are talking along the lines of "oh AMD is nice but... Nvidia". No, in 2019 all AMD GPUs this decade support OpenGL through 4.5, support Vulkan, and still really don't have a great OpenCL situation (rocm is out of tree on every distro and only supprts parts of 2.0 still). For gaming though, theres no reason not to get an AMD GPU. They are at near performance parity with Nvidia relative to their Windows…

> their RTX crap I was hyped about RTX when it came out and I'm all for more performant raytracing however my hype has seriously waned since the RTX release due to the lack of support. Until we have more games that support it I'm inclined to agree that there is no reason to included it when deciding between NVIDIA and AMD at this time. I would argue that by the time raytracing in gaming is more widespread there will…

Fair enough. But when the choice is a 2080 for 699 with RTX and their new 2080 competitor without RTX for 2080, or no AMD card at all, it's not a hard choice.

Re: AMD Open Source Driver for Vulkan

#175
post #13

Earlier quoted context omitted.

Some of the firmware has been reverse engineered, with community supplied patches, but that's not supported at all by AMD. https://github.com/fail0verflow/radeon-tools/tree/master/f32 What's interesting is there's not a clear reason for the firmware to not be opened other than it's probably a huge amount of work to document. It looks like an unexpected house design so there shouldn't be IP issues, and it's pretty mun…

That has actually been discussed by an AMD employee [0]. Commentary [1]. [0] https://www.reddit.com/r/Amd/comments/950g8r/will_we_be_able... [1] https://www.reddit.com/r/linux/comments/95romz/ubridgmanamd_...

A lot of that falls flat. Part of what he's saying is in regard to signed updates, but the microcode on at least some pretty new chips isn't signed, as the fail0verflow guys were able to patch it.

Re: AMD Open Source Driver for Vulkan

#176
post #49

Earlier quoted context omitted.

Temperature monitoring for the first gen Ryzen chips has been in the kernel for about a year. The patch for second gen is there but narrowly missed the 5.0 release window, so it should land in the first release after 5.0. Intel is a bit faster about this but it's not like they have perfect day 1 kernel support either. i.e. temperature monitoring drivers for both first gen Ryzen and Coffee Lake landed in 4.15. At the…

Thanks. It's not easy to find information like this. How did you find it?

I just Googled "ryzen temperature monitoring linux".

I've had a Ryzen 1700 since they first came out so I was following the Linux support for that fairly closely at the time, mostly by browsing Phoronix fairly frequently. Thankfully after a few months I didn't need to because things were working pretty well by then, other than the thermal monitoring that took quite a while to land. Linux and brand new hardware rarely seem to get along well regardless of the vendor unfortunately.

Re: AMD Open Source Driver for Vulkan

#177

Earlier quoted context omitted.

Please keep in mind that this site is operated by a US VC, on US hardware and software, for a US audience residing in a few tech-centric US cities. US colloquialisms are perfectly appropriate on this site.

> Please keep in mind that this site is operated by a US VC, on US hardware and software, for a US audience residing in a few tech-centric US cities. And funded by a Brit :-) Honestly, that's not how today's world works. Sites like Reddit and HN obviously have an international audience. It is not meant for people from tech-centric U.S. cities, but rather to be a sort of sales channel for YC, which BTW has well-known…

"It runs on Linux, I presume, who's creator is Finnish"

Who currently lives and works in the United States, last I checked.

Not to say I disagree with your point, of course; just pointing out the irony of condemning someone for putting undue emphasis on a particular nation's contributions to something while inadvertently doing the same in the process.

Re: AMD Open Source Driver for Vulkan

#178
post #117

Earlier quoted context omitted.

You must be smoking some real good stuff if you think "What are you smoking?" is meant to be a literal accusation of substance abuse.

I am well aware of the colloquialism. My point is that it violates the site's comment guidelines. 'When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."' This comment can be shortened to eliminate the first sentence, which is needlessly rude.

I don't disagree. That's not the objection your original response presented, though; rather, your comment implied a literal interpretation of "What are you smoking?", at which my own comment poked fun with a variation on that colloquialism.

Re: AMD Open Source Driver for Vulkan

#179
post #137

Earlier quoted context omitted.

> they work with the inbuilt drivers on every distro out of the box No they don't work with any distro that uses linux-libre.

What gpu works on linux-libre?

Many old gpus store firmwares in non-volatile memory so that OS doesn't need to load them. Such gpus work with linux-libre as long as there is a free driver.

Re: AMD Open Source Driver for Vulkan

#180

Earlier quoted context omitted.

also there are a lot of developers globally with looser morals because of different cultural values. in my experience anyone from a -stan country will make whatever you want as long as you give them a decent salary and a visa

Aside from the racism - are you suggesting that working on closed source software is immoral!?

closed source is the default. and where is the racism? you don't even get ethics lectures if you're educated as an engineer in a third world country. anecdotally i was educated from a pretty good private college and even there the ethics professor herself said you don't really get to make any ethics decisions as an engineer in india. your only choice is quitting and that is a really tough choice
Post reply on HN