AMD Sends Out Linux Kernel Driver Support For Navi 12 GPUs

[phoronix]

Phoronix: AMD Sends Out Linux Kernel Driver Support For Navi 12 GPUs

While we've already seen the RADV Vulkan driver land their slated support for Navi 12 GPUs on top of the recently launched Radeon RX 5700 "Navi 10" graphics cards, today is the first time we're seeing patches from AMD to wire in the support to the AMDGPU DRM Linux kernel driver for this next iteration of Navi...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-AMDGPU-Kernel-Navi-12

[tildearrow]

Another... VCN... revision?
When Navi 12 hardware comes out can somebody from AMD point out the differences between this and VCN 2.0?

[Michael]

Another... VCN... revision?
When Navi 12 hardware comes out can somebody from AMD point out the differences between this and VCN 2.0?

One item that might be different is regarding the power gating for VCN on Navi 12. There was a patch mentioning explicitly the VCN power gating for Navi 12 but didn't have a chance yet to compare to see if there is indeed no power gating for VCN on Navi 10.

[xxmitsu]

Navi RDNA ISA documentation published: https://gpuopen.com/compute-product/...-architecture/

[tildearrow]

Navi RDNA ISA documentation published: https://gpuopen.com/compute-product/...-architecture/

Let's grab it before it gets removed! I remember back in 2017 when the Vega docs were published, and by September-October of that year I couldn't find them anymore.

[mannerov]

Navi RDNA ISA documentation published: https://gpuopen.com/compute-product/...-architecture/

Thanks for the link. We can deduce a lot of things from the ISA spec. I'm particularly happy with a number of aspects of the new architecture for compute operations:
. Maximum number of registers accessible by a workgroup seems to increase from 1024 (4 (queues) * 64 (wavefront) * 256 (max number of registers)) to 2048 ( 4 (SIMDs) * 32 (Wavefront) * 256 (max number of registers) * 4 (several wavefront per SIMD. A max of 1024 registers per SIMD)). I hope there is no restrictions on workgroups that reduce this number.
. Lower LDS latency (1 cycle if good access pattern !)
. More LDS accessible per workgroup: 64kb (was 16kb previously if my memory is right)

[bridgman]

The AMDs open source ROCm driver has no support at all for Navi and a github issue asking about this never got a single reply from AMD devs.
...
AMD has said that Vega (and GCN) will continue as compute focused parts.Arcturus (gfx908) is the next of these to be released and it already has support in ROCm, yet there is nothing from the devs mentioning Navi.

The github thread went off the rails before anyone from AMD could respond, and the question has been pretty much overtaken by events if you look at the upstream commit history:

https://cgit.freedesktop.org/~agd5f/...aging-drm-next

https://git.kernel.org/pub/scm/linux...drm/amd/amdkfd

Compute-oriented cards are still top priority but we want to be able to run the same code on all hardware as much as possible (at least for Linux... Windows compute runs over PAL).

[bridgman]

The problem at AMD seems to be a corporate one. Correct me if I'm wrong but it looks a lot like someone decided that trying to seriously compete with Nvidia was too hard and didn't meet their cost analysis.

With respect, you may be over-simplifying things. You are probably familiar with our financials so I'll just remind that right now any increased spending in one area means that we have to spend less in other areas, except to the extent that growth in (revenues x margins) allows us to hire more engineers over time.

We have had some growth recently and we are hiring as a consequence (go to AMD Careers then type "linux AND software" into the Keywords field) but until those people are hired and up to speed we have a relatively fixed ability to do things. In the meantime the highest priority for the people we have has to be made in areas where we are aiming for significant short term growth... it's probably obvious that the main ones right now are desktop/server CPU, mobile APU, gaming GPU and datacenter GPU.

It's great to say "you should have spent more" but do you have a recommendation for where we should have spent less in order to fund that, and are you confident that spending less in those areas would not have impacted the business we need in order to keep growing and fund the development you would like to see ?

Focusing on datacenter compute rather than desktop compute has advantages, but one of the downsides is that the progress we are making in the compute area is not as broadly visible as it would be if we focused on desktop compute instead. It does result in a perception problem but we are trying to address that by spending on engineering rather than marketing, eg bringing ROCm stack support to Navi.

Some of this (like documentation) can be helped by the community, but I'm not going my spend time on something that won't ever been seen, or will soon be deprecated (HC anyone?).

Regarding HC (assuming you mean the forward-looking C++ mode of hcc), my impression was that we were primarily moving our HIP focus from HCC to a native clang implementation. Our impression was that there was not much production usage of HC mode - do you disagree ?

Is your concern/criticism related to the HIP/hcc-to-HIP/clang transition or phasing out the HC mode of hcc ?

This RDNA GCN split seems good but I'm worried that the extra costs of maintaining this is going to slow or stall AMD's compute development.

Yep, fair... what I can say is that we made that decision in order to maximize our compute progress, not to hurt it.

Even if it doesn't, then it really isn't to much effort for someone at AMD to add a paragraph to a readme explaining the current situation. Commit history is not something anyone would make a purchasing decision based on.

Agreed, but we don't *want* people deciding to buy our products based on future availability of software. The current README is pretty clear re: which hardware is supported and Navi / GFX10 is not on the supported list:

https://github.com/RadeonOpenCompute...supported-gpus

Are you suggesting that we add an explicit "not supported" section to the README and put Navi / GFX10 there (which we could do) or are you suggesting that we add a section about future development plans ? That latter brings all kinds of problems.

[bridgman]

Wow, Thanks for the deep insight into AMDs decisions. That post alone is almost enough content for a Phoronix news item in it's own right.

I sure hope not. Every time that happens it gets harder for us to interact with the community. The goal of this kind of interaction is to make already-public information more useful/relevant/accessible by targetting specific questions/concerns, not to release new information.

If we have to treat every response like a press release despite not actually releasing any new info then our ability to interact goes quickly to near zero and the only communication would be through our PR teams.

My concern was with the phasing out of the HC mode of hcc. HC has many aspects, which in my opinion, are better than HIP/CUDA. The fact that it was deprecated is a shame. However some of it's good points are similar to aspects of SYCL. There are open-source projects to bring SYCL into clang and so this is a mitigation of sorts. I do understand that HC saw limited use, it's just a shame that some of it's better features couldn't be integrated into HIP in some way, rather than being lost.

Yep, that's fair. I don't think we want to lose that either. The main thing we are trying to do is move HIP work from hcc to HIP-clang AFAIK.

Your mention of commits in your last post made my think that Navi support was coming to ROCm, but you don't seem to be indicating that very strongly?

Correct. I am saying "we are working on Navi support for ROCm" not "Navi support is coming to ROCm". One is a statement about the present, which I can make with confidence, the other is a statement about the future.

I hate being so nit-picky, but that is a *very* important distinction and without it community interaction would rarely be possible.

The closest thing we (engineering) come to making statements about the future is releasing open source driver code before product launch, and we only do that after discussion with and approval from the business teams.

I think some clarification on Navi specifically would be helpful, although I understand why there would be various barriers to any mention of future plans (especially regarding unreleased products etc.) beyond this.

There's a big difference between saying "work is happening" and talking about the future, unfortunately. In any company, private or public, there is a high bar for making statements about future deliverables, and the bar is even higher for a public company.