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

[BNieuwenhuizen]

The commits that were reverted here were responsible: https://github.com/BNieuwenhuizen/me...resting-revert but there's something more going on because with later commits it still produced hangs and it hasn't been bisected yet.

That said, it could also be a different problem on SI.

Unlikely that these are the cause on SI. Since https://github.com/airlied/mesa/comm...54fbbd3cb1f396 (with trivial fix https://github.com/airlied/mesa/comm...4190d90eb96fdb), SI uses a different CS submission process than CIK+. And before these patches, pretty much anything was possible for SI, as we used CIK+ packets for submission.

Also, don't expect that much performance improvement since the previous benchmarks. We have been working on HiZ, fast clears and DCC, but none of them are enabled by default yet, as they don't work correctly in all cases for now.

[bridgman]

In theory pro driver should work with open libdrm and ddx this is how i understand this amdgpu+/-pro mess, but life is life.

"Will sometimes work" is more accurate than "should work". The pro stack is likely to have libdrm functions that are not yet upstream, which are required by the userspace drivers.

What "should work" going forward (we're not testing it today) is open source userspace drivers with the kernel driver from the pro stack... IOW we are making support for Mesa one of the requirements for the PRO kernel driver and libdrm.

[bridgman]

Auggh. Moderated and can't edit. Always at the bottom of a page.

Bleah.

Anyways, frosth what you described is kinda the opposite of what "should work" - we are going to be testing upstream userspace with the amdgpu-pro kernel driver and libdrm, but there is no commitment for amdgpu-pro userspace to work with upstream kernel and libdrm. Sometimes it will work, sometimes it won't, depending on the delta between current pro kernel driver and upstream kernel driver.

I don't know where the idea of amdgpu-pro just being a couple of closed source drivers that ran over the upstream all-open stack came from, but that has *never* been the plan. It keeps echoing around the internet anyways though.

I do expect that we will approach that state over time, but until we say otherwise we strongly recommend using the entire -pro stack including kernel drivers.

[airlied]

We just rebased onto master so might explain it looking like lots of new stuff

[frosth]

Argh! Yes, bridgman your word brings the truth. a) Probably i mixed some infos from late 2014 about pro and non-pro drivers both with closed sources opengl stack b) the truth is i care about amdgpu-pro less.
So you have right, AMD never promis amdgpu-pro works ootb with upstream.
Btw , what's happend with closed "non-pro" driver?

[frosth]

bridgman Yes, you have right AMD never promises -pro will work with upstream. I've mixed some info from late 2014 about closed amdgpu non-pro driver.
Btw what's happend with non-pro plans?

[frosth]

Unapproved again.....argh!!!

[frosth]

Yes, bridgman you have a right, AMD never promises -pro works with upstream, i've mixed some info from late 2014 about closed amdgpu non-pro driver.
Btw what's happend with plans about that driver?

[frosth]

Hahaha now i did some spam just because i thought my posts went to hell.
i join to "unapproved again" team now 😀

[darkbasic]

I don't know where the idea of amdgpu-pro just being a couple of closed source drivers that ran over the upstream all-open stack came from, but that has *never* been the plan. It keeps echoing around the internet anyways though.

I do expect that we will approach that state over time, but until we say otherwise we strongly recommend using the entire -pro stack including kernel drivers.

If PRO will not work with upstream drm and libdrm it will be no better than Catalyst, it will end up being the very same shit.