It's Been Another Exciting Week Of RADV Development (Radeon Vulkan)

[bridgman]

Curses, moderated again.

In a perfect world the 30-seconds-between-posts rule would be waived if your previous post had just been moderated for no good reason

[bridgman]

I'm sorry, I probably didn't track the events good enough, I am confused. As I understand, there's a kernel driver, which is called AMDGPU, and which is open source. So, what is the second kernel driver in the quote "delta between current pro kernel driver and upstream kernel driver"?

Think of it as different versions of the same driver, where the kernel driver in the -PRO package has a bit of extra code that we can't have upstream yet, either because of timing (it's on the way up but not in a released kernel), lack of open source userspace driver that requires it (any functionality required by one of the -PRO userspace drivers but not by Mesa), or just because the nature of the change makes it non-upstreamable in its current form.

[bridgman]

I don't believe it... auto-moderated three posts out of three in the same thread.

EDIT - OK that's interesting... some of the "Replies below are on the next page" message may be bogus, since I received two on the same page now.

I have a nagging feeling that I may have already discovered this a month or two ago.

Btw what's happend with non-pro plans?

We dropped them

Seriously, the all-open driver was progressing sufficiently well that we weren't sure there would be a long-term need for a consumer-focused hybrid stack. On the other hand, the hybrid driver could be useful in some cases where the open stack was still weak, so we decided to start shipping the -PRO stack before we had all the FirePRO-specific features implemented.

If we still find we need a consumer-focused hybrid stack once the -PRO driver is finished and we have open source OpenCL & Vulkan we can revisit that, but a packaged-up (backported-via-KCL, installed-via-DKMS) version of the all-open stack seems like a more likely solution for the long term.

The complicating factors are always the same - requirement to support new HW on already-released distros, and the rule that we can not include kernel compatibility layer code in upstream drivers. Until one or both of those change we are always going to need some kind of out-of-tree driver solution, which IMO is something we and the community need to figure out how to change.

Consumer distros can often get by with newer kernel plus userspace packages, but enterprise distros generally need backporting and out-of-tree deployment via kernel modules.

[juno]

That diagram just shows how amdgpu-pro looks like in future perpective and nothing else

Am I just plain stupid or are you telling me the complete opposite of

that has *never* been the plan.

it does not tell anywhere that all-open will also run closed source parts

Oh, but the diagram does imply exactly that – if you don't need specific FirePRO functionality.

Right... it's the green bits.

Which are clearly labeled with "FirePRO".
If I may transcribe Jammy Zhou and Alex Deucher from this presentation, they are also clearly talking about same as all-open, except for css OpenGL and Workstation/FirePRO-specific features.

So, if you really "don't know where the idea [...] came from", this presentation is often used and quoted. It is implying that the css OpenGL runs on upstream drm driver and libdrm, without FirePRO features. If this really has never been part of the plan, I'd suggest to update this diagram and post it somewhere.
I think I don't have to remind anyone that there is basic customer, not pro/workstation functionality missing in upstream, which is in the pro driver. Like HDMI/DP audio.

[haagch]

Right... it's the green bits.

Non-upstream kernel & libdrm code is constantly being pushed upstream as we get open source userspace driver functionality that requires it, but as the current bits get pushed upstream there's a reasonable chance that new non-upstreamable bits will be added.

This image is also still not reality. It says the green bits are open source but "may not be upstream", but there is in fact no public source code for the changed libdrm and xf86-video-amdgpu yet.
Why doesn't AMD at least put the current code "as is" in the amdgpu-pro installer? Then people could at least create their own patches for the current version of their packages.

[dungeon]

Well reality can be this or that, but from the aspect of legality - everything is fine there

[dungeon]

Oh, but the diagram does imply exactly that – if you don't need specific FirePRO functionality.

Nope, it says there 'Stack Diagram:Pro' that does not mean all-open+closed or LEGO

[dungeon]

This image is also still not reality. It says the green bits are open source but "may not be upstream", but there is in fact no public source code for the changed libdrm and xf86-video-amdgpu yet.

Still, yet... yeah When AMD say something *will be* opensource that only means in undefined perspective, which also might mean that will not be too - so depending on the time for user X or user Y, it might mean this or that as always

So these are relative wording used They are also free to change plans even without notice, based on a requirements, what customers and bosses wants, etc...

[bridgman]

Oh, but the diagram does imply exactly that – if you don't need specific FirePRO functionality.

Have to disagree with this. There is nothing in the diagram that suggests running a PRO userspace driver without a PRO kernel driver will result in the userspace driver gracefully degrading functionality and AFAIK no plans to do so. If you mix & match components and the kernel driver is missing functionality then things could work, mostly work, or start failing on the first API call depending on how the code is written.
blow up
I believe current state is that OpenGL works OK with upstream driver and Vulkan has problems. Not sure about OpenCL - thought it also used -pro kernel driver functionality but seems to be running well for a number of users without it.

[bridgman]

Aww, I give up. That's the 4th unapproved post just in this thread.

This forum requires that you wait 30 seconds between posts. Please try again in 1 seconds.