Radeon Software 18.20 Preview Offers Early Support For Ubuntu 18.04 LTS & RHEL 7.5

[dlcusa]

It comes up fine for me (in Canada) - maybe there is some country-specific issue ? Here are the links from the page if that helps:

EULA: https://support.amd.com/en-us/download/gpu-pro-eula

download: https://www2.ati.com/drivers/linux/u...-579836.tar.xz

Install instructions: https://support.amd.com/en-us/kb-art...cs-Stacks.aspx

Vulkan SDK from LunarG: https://vulkan.lunarg.com/sdk/home

All those links are alive for me (although the download doesn't like being directly accessed from outside AMD--at least it's nice about it) but the link to the Notes produces not a bit of feedback. I could get it fine a week or two ago. Thanks for letting me know it's there for you. I'll try some different platforms...

[bridgman]

Now, however, I cannot get the AMD website to cough up https://support.amd.com/en-us/kb-art...ase-Notes.aspx again.

It comes up fine for me (in Canada) - maybe there is some country-specific issue ? Here are the links from the page if that helps:

EULA: https://support.amd.com/en-us/download/gpu-pro-eula

download: https://www2.ati.com/drivers/linux/u...-579836.tar.xz

Install instructions: https://support.amd.com/en-us/kb-art...cs-Stacks.aspx

Vulkan SDK from LunarG: https://vulkan.lunarg.com/sdk/home

[dlcusa]

I'm new here. I put together a new box using an Asus Sabertooth with an FX 9590, H105 cooler, 32 GB RAM, and a Radeon R9 Fury X using hand-me-down and new components my oldest son provisioned. Thus, I'm interested in exercising this guy, and it looks like that means Ubuntu 18.04. My first attempt installing the preview package would not build but being especially busy I deferred bug reporting until I could reinstall Ubuntu and try again, possibly capitalizing on others' subsequent experience. Now, however, I cannot get the AMD website to cough up https://support.amd.com/en-us/kb-art...ase-Notes.aspx again. I tried creating an AMD support forums account but it won't honor clicks on the "I agree to the T&Cs" button. So maybe I can get pointed to the right information here. Have the Notes been pulled pending imminent formal release? Should I ignore 18.20 for getting started?

[ribalda]

Because we are already working 12+ hour days and can't pack any more in until we finish some of the current tasks/topics.

Sorry to hear, I really feel you . I guess is not that easy to recruit people that can do graphic stacks

[TemplarGR]

Not really... sorry. Most of it relates to either not-yet-announced AMD products or never-going-to-be-announced semi-custom projects.

Consoles :P

[rdemaria]

I have tested the Ubuntu 18.04 amdgpu-pro 18.20 with a R9 280X (Tahiti). Xorg seems to work fine. The OpenCL driver however silently corrupt memory on the device, leading to wrong computations. See

https://bugs.freedesktop.org/show_bug.cgi?id=106527 and perhaps https://bugs.freedesktop.org/show_bug.cgi?id=102491

Is it a regression or expected? Tahiti is not in the list of supported hardware, but it seems it is close to be usable and it seems the only hope to continue to use this hardware on recent linux kernels for OpenCL applications.

[FastCode]

well, the issue is fixed with firefox 60, we can stop fighting now.

[bridgman]

Not really... sorry. Most of it relates to either not-yet-announced AMD products or never-going-to-be-announced semi-custom projects.

[FastCode]

do you use kde or gnome or unity? bridgman talks like it is my fault if i use KDE...

I call this bullshit this rotten closed source driver is just a shit driver.

using default unity DE on ubuntu 18.04, my system is using default settings as much as possible.
the crash is in the amdgpu library.
I also have the flash/noise bug with amdgpu.dc if that's related.
the hardware is GL702ZC-GC154T

[bridgman]

Sounds not so bad really. But really AMD need to rethink this amdgpu-pro workstation driver whats the problem in including stuff like OpenGL compatibility profile to the all open stack? because a driver who even do crash firefox on AMD.com is really strange.

The smaller issue is that it is a big pile of coding work. The larger issue is that a lot of compatibility profile usage happens outside the OpenGL specs, and so "getting it right" on a different driver architecture is more like reverse engineering than regular development, with a lot of testing & tweaking. Compatibility profiles would have died already if there were more than a couple of GPU vendors supporting them, since every driver is going to behave somewhat differently.

Yes why not re include ROCm in the packaged for all-open stack... or write a more smart installer script who checks if the hardware is compatible to ROCm.

Each new stack we release requires a bunch of additional testing; in the short term we want to keep the number of places/forms we release code aligned with our ability to test it.

"it hasn't really been discussed much yet" thats good to why not just start discussing it now. it would be much easier to the people to install a open-source PAL packets in the Linux distro instead of downloading a closed source driver packet from amd.com

Because we are already working 12+ hour days and can't pack any more in until we finish some of the current tasks/topics.