Trying AMDGPU-PRO 17.10 On Ubuntu 17.04

[bridgman]

I was always under the assumption that the Vulkan driver was meant to be open sourced and on Linux since the conception and always wondered why you guys had to open source it after the fact. I'm glad you cleared that up for me.

There was awareness that we would need an open source driver for Linux, but the Vulkan team didn't feel that writing a separate IP-clean driver from scratch in parallel with the more (internally) maintainable shared-code driver was practical.

Amdgpu-pro supports opencl 2.0 for years. Are you talking about 2.1?

It's actually what we call "1.2+" or "2.0-" - 2.0 compute kernels and most of the 2.0 features (theoretically at least the ones people actually use) but not full 2.0.

[bug77]

It's called Patents to protect within your IP. If your innovations are completely open, what incentive do you have to invest and do all the research if the entire community will wait until all that work is done, then come in and use it? The FOSS community seems to be under the delusion that we live in a true world of altruism.

Are you really buying that? I mean, if drivers were actually depending on IP, how does AMDGPU work? Cause it's sure devoid of any IP or trade secrets.

[duby229]

There was awareness that we would need an open source driver for Linux, but the Vulkan team didn't feel that writing a separate IP-clean driver from scratch in parallel with the more (internally) maintainable shared-code driver was practical.



It's actually what we call "1.2+" or "2.0-" - 2.0 compute kernels and most of the 2.0 features (theoretically at least the ones people actually use) but not full 2.0.

IMO, it's the part you put in brackets, and the strategies to make that happen, that are the root cause of this situation. Your internal development practices are incompatible and probably always will be. I'm afraid that when AMD finally realizes that it'll already be too late and AMD will decide to pull out of open source instead. I've already explained my fears though, so I'm repeating myself unfortunately.

EDIT: What I mean is that I'm afraid everything you do is going to have to be developed internally. With this strategy that's just the way it'll have to be. But we've already seen what happens when AMD's internally developed code needs to get accepted to an upstream project. It's just not a sound strategy at all. I doubt it'll ever improve, more likely it'll get much worse. If you don't want to have to fight against upstream communities, then you are going to have to develop your code with them.

EDIT: It's not like you don't already know this, for the most part you guys have been developing in the open for years. You already know it's the best strategy, so I just don't get it.

[vein]

Amdgpu-pro supports opencl 2.0 for years. Are you talking about 2.1?

There was awareness that we would need an open source driver for Linux, but the Vulkan team didn't feel that writing a separate IP-clean driver from scratch in parallel with the more (internally) maintainable shared-code driver was practical.



It's actually what we call "1.2+" or "2.0-" - 2.0 compute kernels and most of the 2.0 features (theoretically at least the ones people actually use) but not full 2.0.

Actually, I just saw that clinfo shows 1.2 for my R9 fury (that got 2.0 with fglrx when I bought it some time ago), so I thought that amdgpu-pro doesn't support 2.0 yet... so shame on me..

But actually now that I look at it I see:

Number of platforms                               1
  Platform Name                                   AMD Accelerated Parallel Processing
  Platform Vendor                                 Advanced Micro Devices, Inc.
  Platform Version                                OpenCL 2.0 AMD-APP (2348.3)
  Platform Profile                                  FULL_PROFILE
  Platform Extensions                             cl_khr_icd cl_amd_event_callback cl_amd_offline_devices
  Platform Extensions function suffix             AMD

  Platform Name                                   AMD Accelerated Parallel Processing
Number of devices                                 1
  Device Name                                     Fiji
  Device Vendor                                   Advanced Micro Devices, Inc.
  Device Vendor ID                                0x1002
  Device Version                                  OpenCL 1.2 AMD-APP (2348.3)
  Driver Version                                  2348.3
  Device OpenCL C Version               OpenCL C 1.2
  Device Type                                     GPU

So...paltform is 2.0 but device is 1.2... is there something wrong with my installation or is this because of the "1.2 + 2.0" thing?

[bridgman]

So...paltform is 2.0 but device is 1.2... is there something wrong with my installation or is this because of the "1.2 + 2.0" thing?

I think that is because of "the 1.2+ / 2.0- thing".

[bridgman]

IMO, it's the part you put in brackets, and the strategies to make that happen, that are the root cause of this situation. Your internal development practices are incompatible and probably always will be. I'm afraid that when AMD finally realizes that it'll already be too late and AMD will decide to pull out of open source instead. I've already explained my fears though, so I'm repeating myself unfortunately.

EDIT: What I mean is that I'm afraid everything you do is going to have to be developed internally. With this strategy that's just the way it'll have to be. But we've already seen what happens when AMD's internally developed code needs to get accepted to an upstream project. It's just not a sound strategy at all. I doubt it'll ever improve, more likely it'll get much worse. If you don't want to have to fight against upstream communities, then you are going to have to develop your code with them.

EDIT: It's not like you don't already know this, for the most part you guys have been developing in the open for years. You already know it's the best strategy, so I just don't get it.

I think the confusion here comes from you generalizing the term "internal development practices" across different areas where we have significantly different internal practices:

1. Linux-specific code - our "internal development practices" are based on either working directly against upstream trees or working against internal trees which are frequently synced with upstream. The specifics depend on how much of the work being done is related to NPI - New (HW) Product Introduction - where approval for public release comes only once we get fairly close to launch date.

2. Development for non-open platforms (Windows & others) - here our internal development practices reflect the amount of third party IP we are able to expose publicly, which is pretty darned close to zero. This is still the largest part of our business by far.

3. Code which is shared between #1 and #2 - there are relatively few examples of this, and they tend to be handled case-by-case:

a - Workstation OpenGL we plan on keeping closed and distributing in binary-only form

b - DAL/DC was developed largely in the open other than new HW support

c - Vulkan was developed with awareness of an open source requirement but was based on existing closed-source code and plans to continue leveraging work done on that closed source code even after open sourcing, so the initial implementation architected out third party IP where possible while still aligning with Vulkan launch plans

When you say "our internal development practices are incompatible" which of the 5 development practices I mentioned are you talking about ?

[bridgman]

Remember that the Linux workstation market is derived from the proprietary Unix workstation market, and most of the preferences/biases are inherited from there as well. The applications were often written a decade or more ago and are generally in maintenance mode. New apps are being written for DX, core OpenGL or (hopefully) Vulkan - it's the much older apps that are an issue here.

So far the general impression from Linux workstation customers is that most of them don't consider open vs closed source when making buying decisions. If you have information to the contrary (remember we are generally talking about large corporate customers here) I would be happy to listen to it.

[computerquip]

Because they used code, tools and/or information provided by other companies that do not want to have those parts open sourced?

Curiously, what other companies would have their hands on AMD IP that isn't already part of AMD?

[bridgman]

Curiously, what other companies would have their hands on AMD IP that isn't already part of AMD?

Devius is saying the opposite of you - talking about non-AMD IP that has been licensed to AMD for specific purposes which do not include open source Linux drivers.

[bridgman]

many words

You took my "free as in beer" statement about proprietary Unix vs Linux, generalized it into FLOSS, then started talking about the "free as in freedom" aspect of FLOSS - the part I was *not* talking about.

Anyways, I'm on vacation for the next 9 days so have fun...