Radeon Vulkan Driver Added To Mesa, Fresh Radeon Vulkan vs. OpenGL Benchmarks + AMDGPU-PRO

[artivision]

It is not about selling new chips always, as even Mantle was GCN only API is designed for new hardware, so what you expect there i dunno... Tulkan maybe, but Vulkan no

Vulkan is designed for all standard compute capable hardware. Also bigger vector registers will benefit (slightly) even if ACUs are not present.

[dungeon]

That was always the case, that Catalyst also worked only for specific kernels otherwise needs patching

I suggested to bridgman to ship orig.tar.gz file officialy (package from where debs are builded from) like one that is available in steamos repo... but in the end that is up to AMD and release/build managers to decide

That way others can again make scripts without unpacking tons of debs around In the end it is the same approach - place these files here and there and rebuild module

[smitty3268]

For non-Skylake? If by that you mean every other integrated Intel graphics and all GPUs created by nVidia and AMD then; thats cool.

The topic was originally about Intel. Skylake is much slower on linux than windows, but their olders GPUs tend to be pretty close I believe.

For AMD and NVidia their performance is very close between windows and linux if you are using the proprietary OpenGL drivers.

Mesa for AMD tends to vary - in some cases it is now actually faster, while in others it still is slower. Nouveau tends to be consistently much slower than the NVidia proprietary drivers, in part because it lacks a lot of reclocking support still.

[bridgman]

As far as I could see, it works only for specific kernels. The next small kernel update can break it. AMD officially only offers a driver for ubuntu x86_64.
So, for me this is no replacement for the old binary drivers that just worked for me (OpenSuse) thanks to a niche un/installer from http://sebastian-siebert.de/

The fglrx driver only worked for specific kernels as well (that's the case for any out-of-tree driver), it just worked for a lot of kernels because support for a lot of kernels had accumulated over the years (via the KCL). We're using a similar approach for the amdgpu kernel driver in the hybrid stack (KCLs are not allowed upstream).

[smitty3268]

Vulkan is designed for all standard compute capable hardware. Also bigger vector registers will benefit (slightly) even if ACUs are not present.

Does Vulkan require virtual memory addressing? I believe that was only introduced in Northern Islands, and i'm not sure if it was ever enabled there in the drivers. I know originally radeonSI was the first one to turn it on.

[adler187]

That's looking quite promising already. Indeed, AMD will have to come up rather quickly with their contributions.
But then, according to John Bridgman, they're currently quite busy with the preparations for the upcoming HW.

In other news I wonder who on earth (besides Michael) uses a 3840 x 2160 resolution for gaming. Are there 8k gamers out there? Multi-monitor-gamers? My max is still 1920 x 1200 and below (and the 1200 is because I love 16:10 or 4:3, some people also gotta do work on their boxes).

FYI, 3840x2160 is 4K, not 8K.

It's called "4K" since 3840 is *roughly* 4K in the same way that 1024 (bytes) is roughly 1000. Of course it all falls apart the further you take it, like the difference between 2³⁰ (GiB) and 10⁹ (GB). Of course, 3840x2160 is also 4x 1920x1080, so it makes it easier for people try to justify shoving that square peg in that round hole. Why not call it 4X instead, then? Maybe X is not cool anymore and K is the new hotness?

I thought we'd finally settled on vertical scan resolution as the shorthand (480p, 720p, 1080p), why not 2160p? I guess it's still too long. Also, 4K doesn't sound like more of the same just bigger: "Hey, you interested in a 2160p TV?" "No, my 1080p is just fine." "What about a 4K TV?" "Oooh, hadn't heard of those. What's that?"

/rant

[s_j_newbury]

Been in mine since last month.

I'm actually trying to make some effort to unify efforts and collaboration between third-party overlay maintainers in the GPU arena; it's not a competition, right? It would be great to have an overlay with all the best ebuilds and multiple maintainers. With that in mind, can I contact you to discuss this further?

[bridgman]

Rather than just try this on the 480, try it on other cards, you obviously have them. Try it on SI and CIK as well.

From the article:

The focus for testing was on various Volcanic Islands and Polaris graphics cards. In a follow-up article will be tests with CIK/SI GPUs.

[FireBurn]

Where it's out of sync with the portage version it's only bug fixes and extra features like glvnd, properly working opencl-icd and eselect opencl etc. I do keep it up to date with changes. What's the problem with llvm-9999? I've not tried llvm-9999 for a while, I have bumped the requirement to llvm-3.9 as required by RADV.

It doesn't appear that glvnd is actually doing anything in your build, you've installed the libglvnd libraries in a place they're never looked for and enabled it unconditionally in the build which renames the libGLX libraries to libGLX_mesa. Have you found any docs on how this is supported to be configured?

[s_j_newbury]

It doesn't appear that glvnd is actually doing anything in your build, you've installed the libglvnd libraries in a place they're never looked for and enabled it unconditionally in the build which renames the libGLX libraries to libGLX_mesa. Have you found any docs on how this is supported to be configured?

Yes, it's broken at the moment, I have been trying to fix this over the weekend. Docs are unfortunately rather too high-level to be useful. My understanding is: -

Each screen is supplied a driver name through Option "GlxVendorLibrary" in the Screen section of xorg.conf

GL programs link to libGL (GLX) or libOpenGL, this is a wrapper for libGLdispatch below.

The "loader" (libGLdispatch) gets the driver name through the X server GLX X extension for the screen on which the output has been opened. It (supposedly) reads ICD configuration from a json format file (in the case of the NVIDIA driver this is the same file as the Vulkan ICD configuration). It then uses this information to open the correct libGLX_vendor.so or libEGL_vendor.so.