Mesa 20.3 Released With Big Improvements For Open-Source Graphics Drivers

[StillStuckOnSI]

I for one am excited about the potential for a linux-native, cross-vendor (and cross language. Looking at you, SYCL/DPC++) compute framework. Even earlier in the year this video felt like a pipe dream, but with how well the Clover work is progressing and all the recent discussion about how to design an "open" compute API, there at least appears to be some light at the end of the tunnel.

[uid313]

So when can Nvidia (or Nouveau) have open source Vulkan drivers?

[duby229]

Anybody down to benchmark OpenCL1.2 Clover vs ROCm?

[zxy_thf]

EDIT: Cuda state tracker in mesa? Maybe? Anyone know?

Close to impossible.
CUDA is more like a programming language than an API.
You need a compiler to make it work.

[duby229]

Close to impossible.
CUDA is more like a programming language than an API.
You need a compiler to make it work.

Ok, so does Vulkan or OpenGL.

What about HIP? It's supposed to be open source, can it be forked out of ROCm and ported to mesa?

[tuxd3v]

AMD actually implemented most of clover years ago and tried drive it as an open source community driven OpenCL implementation, but there was never much interest in it until the last few months. In the meantime, we had a complete implementation that we could open source. Not community driven I realize, but there wasn't and still isn't much of a community around OpenCL and it allowed us to get something out sooner rather than later. It should also be noted that there are only a couple of cards that require platform atomics for ROCm. The vast majority do not.

I understand the motive for Rocm, as a datacenter solution..

However, for a lot of APUs, and discrete cards, there are no opensource AMD driver, and the problem cannot be described as "only a few require..", since pcie atomics need to be supported also by the Motherboard, so its a plethora of things not being able to run mesa clover, only the old proprietary solution, and in some cases maybe the proprietary solution fails too..

Mesa Clover could had being the "backup solution" for everything not supported in Rocm..

[tuxd3v]

Anybody down to benchmark OpenCL1.2 Clover vs ROCm?

Yes, that could be a good benchmark..

[agd5f]

Mesa Clover could had being the "backup solution" for everything not supported in Rocm..

Or ROCm could be the solution. It's open source. The support it there for every generation of gfx going back to gfx7. It's mostly just a matter of testing and bug fixing.

[jrch2k8]

Or ROCm could be the solution. It's open source. The support it there for every generation of gfx going back to gfx7. It's mostly just a matter of testing and bug fixing.

Well, i haven't tried ROCm latest version but so far has proven to be extremely hard to build let alone testing, i really don't wish ROCm to my worst enemy and that is putting it kindly. Even using Archlinux AUR is Russian roulette and if the gods smile on you ROCm really hate Polaris for one reason or another.

Really, i take clover any day of the week even if it is half the speed(i suspect it won't be).

[zxy_thf]

Ok, so does Vulkan or OpenGL.

What about HIP? It's supposed to be open source, can it be forked out of ROCm and ported to mesa?

No, they are different kinds of animals.
You don't need specialized compiler to process your host code in either Vulkan, OpenGL, or even OpenCL.
But CUDA needs one (nvcc), and that's the reason CUDA SDK supports only a few versions of GCC.

HIP mostly copied CUDA's API, but it has quite a few weird design decisions.
For example I don't see the benefits of requiring a specialized kernel driver (amdkfd) for GPU computing as its runtime.
Sure they may have a few corporate grade features there, but it's not accessible to general developers and thus almost DOA (looking at my 5500XT).

To be frank, there are two main problems of ALL CUDA's competitors:
1. Hard to access. It seems none of them are interested in send changes to upstream, or any practice that make itself easier to get than CUDA.

If I wanna start a GPU programming project, why would I prefer your new, untested, not-sure-if-working-but-still-need-installing-packages platform, over the mature, battle-tested, requiring-a-package-but-everyone-around-me-knows-how-to-install CUDA?

2. Verbose interface (at least for beginners): CUDA requires a specialized compiler (nvcc), but the language itself is very clean (<<<>>> may look weird but not too horrible).

I won't the expect the dominance of CUDA may end any time soon.