AMDGPU-PRO 17.30 Linux Driver Now Available For Download

[eydee]

i have a multihead config with a vega frontier using the staging 4.11, there is no acceleration though, but it's good enough for video, the terminal and web surfing.

A crappy intel IGP is "good enough for video, the terminal and web surfing". No reason to buy Vega for these.

[bridgman]

and still no openCL-only-amdgpu-pro installer for the Open-Source stack for pre-PCIE-IOMMU CPUs and mainboards... some even claim it will not run because of bugs and OpenCL-Clover is also in an useless state.

I call this a FAIL

Some people call the moon landing program a hoax as well, but that hasn't stopped other people from running AMDGPU-PRO's OpenCL with the all-open stack.

As you know we don't have an installer for the open source driver stack at the moment, and historically there has been very little interest expressed from our customers, but we are finding a few cases (like patching closed-source OpenCL on top of the all-open stack) where installer logic more like what we have for AMDGPU-PRO could be useful, and we are working on one as I told you recently.

If you are going to re-broadcast the information I give you, please try to keep the context with it.

[pcxmac]

pretty sure VegaFE will be able to use the same 'gaming' drivers as RX Vega, the only difference is memory capacity. I can't see why AMD would have shipped 'gimped' GPUs with 16 Gigs of HBM @ 1000+ to customers, that would be pretty bad.

[Marc Driftmeyer]

Some people call the moon landing program a hoax as well, but that hasn't stopped other people from running AMDGPU-PRO's OpenCL with the all-open stack.

As you know we don't have an installer for the open source driver stack at the moment, and historically there has been very little interest expressed from our customers, but we are finding a few cases (like patching closed-source OpenCL on top of the all-open stack) where installer logic more like what we have for AMDGPU-PRO could be useful, and we are working on one as I told you recently.

If you are going to re-broadcast the information I give you, please try to keep the context with it.

Unless you're talking about the specific amd sanctioned linux-kernel-4.11 uploaded to the AMD ROCm repository none of the OpenCL stack works outside of the narrow offering AMD has offered to date. It's great the stock is strong and making me quality money, but it's useless to doing any real work as I have zero interest building a machine to run Ubuntu, CentOS, etc sanctioned specifically just for the AMDGPU-PRO driver stack.

It amazes me how long it is taking [and this is coming back from working at NeXT and Apple directly in Engineering with the Device Driver Devs and Professional Services fellow consulting teams] just to get this stack [OpenCL] ready for any linux distribution not sanctioned as canon for the Pro Line of supported distributions.

We built NeXTSTEP/Openstep with less than 50 engineers. We ported it as Rhapsody with < 50 on PowerPC and the team of I/O Kit consisted of 10 members world-wide. Yet, the OpenCL stack that you guys have created and turned into a Pandora's Box has taken the OpenCL Spec first written and given to the world by Apple into this jungle of modules that reminds me of the entire CORBA initiative to compete against NeXTSTEP OOA/OOD paradigms and ultimately the OMG Group turned into a pile of ash.

I can't even cite Taligent from Apple as that was far more encompassing as it was meant to be a NeXTSTEP/Openstep clone, but equally dysfunctional. Seriously, we are going on 12 months since Polaris release which Windows was ready day one, and still the OpenCL stack is a PITA from where it should be. Literally been 12 months and counting as it was released in Q2 2016.

[bridgman]

It amazes me how long it is taking [and this is coming back from working at NeXT and Apple directly in Engineering with the Device Driver Devs and Professional Services fellow consulting teams] just to get this stack [OpenCL] ready for any linux distribution not sanctioned as canon for the Pro Line of supported distributions.

It shouldn't amaze you if you think about it in the right context.

If our end game was closed source everything we would have put less (zero) work into open source and more work into closed source, and we probably would have the installer & build/packaging infrastructure you expect by now. It wouldn't be a great solution because it would still be fairly maintenance intensive and would still probably leave out a few distros which were really important to someone.

What we are doing instead is solving the problem by restructuring/rewriting the code to make it available in open source form, and upstreaming a big chunk of new amdkfd code required to get ROC into every distro automatically. That does take longer than a closed source approach, and we are uncomfortable with the extra time required, but it does still seem like the right solution.

[Geopirate]

Vega Frontier Edition aimed for professional environment not gaming. It is like comparing Nvidia Quadro 4000 (the actual target for Vega Frontier Edition) with a Geforce GTX 1080 TI.

This is a poor comparison for a couple of reasons.

First the target is the Titan, not the Quadro cards, they still have Pro cards for that market to be a direct competitor to the Quadro as they have in the past.

Secondly if you compare a Quadro or Titan card to the equivalent consumer card like the 1080Ti the results are generally withing margin of error in gaming benchmarks.

[bridgman]

it is just a big "bug" now other people add that it only work on a AMD-FAKE-kernel : "specific amd sanctioned linux-kernel-4.11 uploaded to the AMD ROCm repository" and i can tell you i am on Linus Torwald upstream kernel 4.13RC2 so real people do not use some AMD fake kernel they use the REAL Linus Torwald kernel.

I think we are talking about two different things here.

We test the AMDGPU-PRO kernel drivers (not the whole kernel, just the drivers) with the all-open userspace as well as the closed source GL/Vulkan drivers, and the AMDGPU-PRO install model uses DKMS to build the GPU kernel drivers against your kernel headers during initial install or whenever you update your kernel.

I assume by "AMD fake kernel" you mean the internal development trees we push to public repos for user & developer convenience ? Or does installing an out-of-tree but open source GPU driver turn a "REAL Linux Torvald kernel" into an "AMD fake kernel" ?

I was very precise and i doubt you find someone here in the phoronix forum or general IT forums who is even more precise than my person. because i am a person who always double check facts on google and wikipedia for every sentence i write. And I think it is just impossible to "keep the context" without copy&past massiv amount of Copyright text and authors and links....

I agree in principle, but when you get excited about a debate you let your desire to win the argument over-ride your normal precision and attention to detail. I'm just asking you to maintain your usual care and attention even when you think you are closing in for the intellectual kill.

Now free your mind and be ready for a outside of your filter bubble advice: drop amdgpu-pro and just put it into the trash and focus the resources on 3 protects: A Open-Source-stack based workstation solution (OpenGL-Compatible-profile for mesa)

Looking at it (as I said we do every so often). Probably a bit too soon but there may be a time that makes sense. There's a big difference between writing a compatibility mode driver and writing one which includes all of the vendor-specific behaviour (usually some other vendor ) that makes popular workstation apps behave as expected.

and build a installer to fix the pre-XOMMU-OpenCL hole by patching closed-source OpenCL on top of the all-open stack

Yep, working on it.

and then try to make the best ROCm openCL stack for the XOMMU2.0 compatible and plus hardware.

Yep. Why do you keep mentioning IOMMUv2 by the way ? We use IOMMUv2 on APUs because it is guaranteed to be there but on dGPU we do not use IOMMUv2. The must-have hardware is the MEC block, which we started adding in CI and finalized in Fiji and Carrizo.

[kanyck]

As you know we don't have an installer for the open source driver stack at the moment, and historically there has been very little interest expressed from our customers, but we are finding a few cases (like patching closed-source OpenCL on top of the all-open stack) where installer logic more like what we have for AMDGPU-PRO could be useful, and we are working on one as I told you recently.

Oh! Come on! Stop lying! What "expression of interest" do you need to eventually fix the damn thing! Thousands of people rioting behind your windows? I may acknowledge that it still ain't working at the moment -- again!, at least on my 7770 Cape Verde. On the previous thread you promised me to find out what the heck is going on and let me know -- and disappear forever. Of course! You've nothing to say and you aren't going to fix the damn thing because there's "little interest"! I already demanded to send me the card that works if you think there's no reason to fix mine. I've paid the money and want my card work! Today, not in a couple of years! Is it something too complex to you to understand and accept?
You try to represent us, who bought certain AMD hardware as minority. Well WHY DIDN'T AMD PUT IT ON THE CARD'S BOX? Somewhat like "We want you guys to buy our crap and go heck out of here! Don't bother us with complaining our stuff isn't working on Linux -- it's not supposed to!" That label would be honest -- but you cannot be honest, do you?

[kanyck]

and still no openCL-only-amdgpu-pro installer for the Open-Source stack for pre-PCIE-IOMMU CPUs and mainboards... some even claim it will not run because of bugs and OpenCL-Clover is also in an useless state.

I call this a FAIL

There is such a package in Gentoo. However, it doesn't work, so it's practically no use to create one.

[bridgman]

Oh! Come on! Stop lying! What "expression of interest" do you need to eventually fix the damn thing! ...

I think we are talking about two different things here. Your previous posts have been about fixing issues with OpenCL in the AMDGPU-PRO driver, but this discussion was about providing a native-ish installer for the all-open stack. That's the part where I said "there hadn't been much interest".

I did confirm that we were covering OpenCL in the AMDGPU-PRO QA passes. Are you still seeing problems with the OpenCL in AMDGPU-PRO on your 7770 on a supported distro ? If so let me know the environment and I'll try to figure out what is different between your testing and ours.