Valve Developer Andres Rodriguez Lands First Patches Into RADV Vulkan Driver

[shmerl]

They aren't going to lock out people on other distros using Steam because it makes literally zero sense.

Ask developers of Talos Principle why their game isn't sold on GOG. Or many other such developers. They are locked into using Steamworks.

[theriddick]

I think valve is just getting over the fact that getting a Linux platform for gaming to a Windows competing level is going to take ALLOT more work than they originally thought, and we're finally seeing them realize that by getting more involved with smoothing out all the millions of rough edges Linux has. Perhaps one day we will see Linux at 10% playerbase share on steam stats, that day could still happen, just not as quickly as Gabe had hoped for...

[Tomin]

Someone can sponsor implementing compatibility profile in Mesa. But I suppose it would still require to have a Windows driver for the same.

Even if Mesa implemented compatibility context, the behaviour of the obsoleted extensions is not exactly defined in the newer OpenGL versions. The applications actually rely on the fglrx (and/or Nvidia driver) behaviour and very likely those applications would have a ton of bugs when run on Mesa just because of this.

[bridgman]

Thanks. OK, let's go through that step by step.

In short, yes its dumb because AMD has limited driver development resources and their is a exploding market right now in and around machine learning...

Agree that getting all the resources we can onto ROCM makes sense, but the workstation business still supports a lot of our Linux work today.

... while AMD's amdkfd stack is a utter mess.

"Utter mess" is an dramatic way of saying "not yet upstream", right ?

Those workstation customers that have applications that are broken are being propped up by your own doing, that's _your_ (vendor not you personally obviously) fault for keeping it alive.

Are you suggesting that NVidia would drop support for compatibility profiles and other undocumented extensions if we did (or, as others have suggested, if we asked them nicely) ? Or would we just be handing the entire market (and associated revenues/margins->developer funding) over if we dropped support ?

Further, that market share has stagnated and is falling. Most "workstation customers" are most likely using Windows and/or are happy to keep some accident driver going.

Yep, that is in a nutshell why the -PRO driver does make sense.

1. You might be underestimating the size of the Linux workstation business, since it includes pretty much all of the old proprietary Unix market trivially ported to Linux.

2. We need to maintain the GL userspace driver anyways for the Windows market anyways.

3. Even in cases where the primary use will be on Windows (which I agree is significant and growing) having certified Linux drivers as well is generally a pre-requisite for all corporate sales.

4. ISVs would prefer an existing, working driver over a reimplementation, whether it be in Mesa or something else.

Put these together, and you end up with the amdgpu-pro plan - focus on the open source stack, but offer a version with the existing proprietary GL driver and associated kernel/X tweaks in order to support the existing ISV application base and keep selling into the market, while avoiding the need to maintain an entire separate driver stack.

Whether the intended use is Linux or Windows we need to maintain the userspace driver anyways.

I understand that you are suggesting we should have the people working on the workstation driver today switch focus to the ROCM stack instead, and that is a completely reasonable suggestion, but you may be over-estimating the number of people that would affect. Most of our Linux devs are working on common code shared between hybrid, all-open and ROCM stacks these days.

Mean while, CUDA has become the de facto standard for all GPGPU related things and AMD don't even have a upstream working and stable driver that can do memory pinning with released ASIC's without hacks

CUDA established whatever position it has well before we announced ROCM. Agree it's not upstream yet (as I have said before we had to get eviction implemented and stable, which it now appears to be). Not sure what you mean about "memory pinning... without hacks", do you mean eviction (required for upstreaming) or the pre-eviction state where we hard-pinned like CUDA (the ultimate hack IMO) ?

and random github half baked source drops every 9 months.

Presumably this is a typo, since we have released ~5 drops in ~12 months ?

[Hi-Angel]

Just FTR, CUDA isn't very comfortable to use. Besides requiring a NVidia GPU, they managed — just don't ask, I've no idea why/how — to tie every CUDA toolkit to a specific GCC version. EDIT: I'm not even talking about major versions, e.g. if the toolkit is supposed to run gcc-4.6, you won't get it working with 4.7.

[bridgman]

Also, can you please give some update on your efforts to open Vulkan and OpenCL from your closed implementations? It's been a while, and supposedly you have a better idea about the ETA now? And may be you can clarify how do you envision to integrate / merge it with radv if at all?

On the OpenCL side, you probably noticed that we just released a developer preview (albeit in binary form) which includes most of the code changes we have to make as a pre-requisite for opening up the code...

1. Replacing the third party C++ parser with clang,

2. Replacing the combination of llvm-to-amdil back end and proprietary amdil-to-ISA shader compiler with the open llvm-ir-to-ISA back end used in Mesa graphics/compute and HCC,

3. Running over ROC instead of low-level code shared with the workstation GL driver.

So maybe 18 months of pre-requisite work is now done; the rest should be easier by comparison.

There has been a fair amount of work on Vulkan as well but not sure how much I can talk about, so will stick to OpenCL for now.

[pmorph]

Valve already has a closed ecosystem. Valve sees business reasons for this, just as AMD sees business reasons for maintaining AMDGPU-Pro.

If Valve goes all-in closed, they just make MS look better, not gaining much themselves.

[ernstp]

On the OpenCL side, you probably noticed that we just released a developer preview (albeit in binary form) which includes most of the code changes we have to make as a pre-requisite for opening up the code...

1. Replacing the third party C++ parser with clang,

2. Replacing the combination of llvm-to-amdil back end and proprietary amdil-to-ISA shader compiler with the open llvm-ir-to-ISA back end used in Mesa graphics/compute and HCC,

3. Running over ROC instead of low-level code shared with the workstation GL driver.

So maybe 18 months of pre-requisite work is now done; the rest should be easier by comparison.

There has been a fair amount of work on Vulkan as well but not sure how much I can talk about, so will stick to OpenCL for now.

Wait, which specific release are you talking about here... ?

[bridgman]

Wait, which specific release are you talking about here... ?

https://www.phoronix.com/scan.php?pa...-1.4-Available

https://github.com/RadeonOpenCompute/ROCm

New Features to ROCm
Developer preview of the new OpenCl 1.2 compatible language runtime and compiler

• OpenCL 2.0 compatible kernel language support with OpenCL 1.2 compatible runtime
• Supports offline ahead of time compilation today; during the Beta phase we will add in-process/in-memory compilation.
• Binary Package support for Ubuntu 16.04 only
• Supports Fiji, Baffin and Ellesmere ASICS only

[shmerl]

There has been a fair amount of work on Vulkan as well but not sure how much I can talk about, so will stick to OpenCL for now.

Thanks for the update on OpenCL, and I hope you'll be able to publish some info about Vulkan as well in the future.