AMDVLK vs. RADV vs. AMDGPU-PRO 17.50 Vulkan Performance

[wizard69]

Yeah, the problem right now is Linux games are hitting the CPU-bound point relatively sooner than we see on Windows - may be related to the prevalence of porting frameworks but not sure yet - and once you hit that point you see much less scaling with GPU performance.

Maybe it might help to have a more balanced test suite that pushes more tests to the GPU that aren't game related. The problem here at the moment is the lack of support for Vulkan. Maybe Michael or somebody else has suggestions for non game apps using vulcan.

In a nutshell having crappy game ports making vulcan look bad kinda sucks.

[bridgman]

Please don't take everything literally

In fairness, you did establish the pattern by assuming that calling the package "Radeon Software for Linux" somehow implied that it would have exactly the same features as "Radeon Software for Windows".

If we had wanted to imply an identical feature set with Windows we would have called it "Radeon Software for Windows on Linux"

Once the name of the driver package has become more like a package for Windows, so we are getting closer and closer to erase more of the boundaries between operating systems?

You are reading a lot more into the name than anyone intended. The "Radeon Software" name is what we apply to the consumer/gaming package - there's nothing Windows-specific about it at all other than Windows being the dominant gaming OS at the moment.

We couldn't call the package "AMDGPU-PRO" any more because we were now including the open source stack. I gather that the rationale for using the "Radeon Software" name was that including the open source option shifted the focus of the package towards consumer/gaming and away from the previous workstation focus.

What stands in the way of porting the "Radeon Settings" on Linux?

A pile of additional work, split between kernel driver and UI, and everyone already being full-time-and-more busy on more urgent work.

Surely for the sake of marketing will have to wait for 11 December 2018, when there will be some "Alizar Edition", which together with the new features for the driver and will bring the full panel for Linux?

Depends on what the schedule would have been otherwise. The packaged driver release model these days seems to be settling around one major feature release each year with other releases for bug fixes, new game fixes and new hardware support.

Most of the features we have been releasing over the last few years have been more related to HW or app support than to the kind of ease-of-use features you see in the annual releases but if we were to implement some kind of UI that would probably end up aligning with the annual cycle as you suggested.

Our preference would still be to expose controls at the driver level and have a cross-vendor GUI interact with them, but I don't think there has been much interest from other vendors or distros in that yet.

[Djhg2000]

Just a curious thought; could PAL theoretically enable gluing the Windows driver DirectX 10/11/12 stuff onto AMDGPU? I recently got back into experimenting with Gallium Nine and this question has been bugging me for the past few days. Hardly a practical solution, but the tantalizing thought of wiping the floor with the green team by the way of native DirectX games on Linux is too persistent for me to simply let it go that easily.

[davidmaoAMD]

Phoronix: AMDVLK vs. RADV vs. AMDGPU-PRO 17.50 Vulkan Performance

With AMD's release on Friday of the long-awaited open-source "AMDVLK" Radeon Vulkan driver here are our initial benchmarks of this official Radeon open-source Vulkan driver compared to the unofficial RADV Mesa-based Vulkan driver and the similar AMDGPU-PRO 17.50 closed-source Vulkan driver.

http://www.phoronix.com/vr.php?view=25725

I have tested the F1-2017 with AMDVLK. Everything just works fine with 4K resolution.
Could you let me know the version of game? I am wondering if you have missed the latest upgrade.

[faldzip]

Good job AMD guys! I really appreciate your opensource work! I'm sure performance will increase in time as it does with radeonsi. And I would really like to see some better Linux ports, as the proper Vulkan implementation needs to be started on a engine design level, not on DX11 to Vulkan layer... So we need some more games with new engines to see the actual Vulkan power.

[mphuZ]

You are reading a lot more into the name than anyone intended.

I am very strict
I still hope that you want to port the interface to Linux. We'll be waiting!

[theriddick]

gluing the Windows driver DirectX 10/11/12 stuff onto AMDGPU?

DirectX is more then just a graphics API, allot more. So you would still need wine regardless and I don't think AMD is one bit interested in doing such a thing to help wine devs map rendering calls directly via the driver. Also microsoft might get all upset and stuff if you started doing such a thing...

[valici]

The most important step was achived, getting the driver released as open source. Performance will get in time where is should be. Next will be getting llvm upstreamed, and all along with radv nicely shipped with distros.

Is the team working on Vulkan different from the one working on Mesa?

[puleglot]

I still hope that you want to port the interface to Linux. We'll be waiting!

Why you need such a GUI?

[theriddick]

There does exist a amdgpu or radeon gui interface on github somewhere, been a while since I used it. Has quite a few features but yes more advanced video and display configuration options would be nice.