AMD: Navi Speculation, Rumours and Discussion [2019-2020]

Any chance AMD will drop the confusing “dual compute unit” terminology for RDNA2? It seems the two CUs share an L0 instruction cache and scalar data cache but all other resources are CU specific. Not sure those two caches are worth the confusing name.

 

Actually they don't share L0. Each WGP can access the double the LDS because it is part of the WGP.
More Info on WGP mode from AMD's RDNA whitepaper.

 

However, the work-group processor mode allows using larger allocations of the LDS to boost performance for a single work-group

I wonder if CU can mix workgroups that use lots of LDS with others that use only a little bit? Probably.
I also wonder how this compares with NV which seems to have more LDS in general (Ampere increased it once more).

 

People with uncommon names (well, uncommon where they currently live) sometimes goes with more familiar name. When I was working with Koreans some more prominent people were using English names as their first names, because English is more cool or something. Considering it could be confusing for people in his vicinity he may just said something like "You can call me David" and here's that.

May be also because of etymology, some of my English and Americans clients call me Thomas because it would be my name in English. I don't know if it's the case for Devinder.

 

There is a good description of what it is from @bridgman

https://www.phoronix.com/forums/for...x/856534-amdgpu-questions?p=857850#post857850

 

It's a shame that only WCCFtech can get things right ...

 

That's true for HPC parts but RDNA and "gaming" Turing have the same LDS:ALU ratio of 1KB per FP ALU. They also share the same 4KB LDS per block/workgroup.

Support for higher maximum LDS allocations per workgroup makes sense but Nvidia seems to take a simpler approach. Still not clear to me why a dual CU isn't just a CU with 4 32-wide SIMDs with mode toggles for GCN compatibility. Maybe that's exactly what it is and the terminology is just wonky.

"Turing allows a single thread block to address the full 64 KB of shared memory. To maintain architectural compatibility, static shared memory allocations remain limited to 48 KB, and an explicit opt-in is also required to enable dynamic allocations above this limit."

 

They do share the instruction cache just not the vector L0.

Yes

 

Thanks to all for the clarity on the ACE nomenclature and cache structure.

For the more interesting part

Code:

drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
case CHIP_SIENNA_CICHLID:
    adev->gfx.me.num_me = 1;
    adev->gfx.me.num_pipe_per_me = 2;
    adev->gfx.me.num_queue_per_pipe = 1;

What is the main reasoning behind the increase of the GFX pipe to 2. Could the API calls theroretically be dispatched across multiple pipes.

I see the MES also got a bunch of updates for Sienna. It is would be really interesting to see this being put to action hopefully with the upcoming HW scheduling in Windows (seems to be not active based on some reports).

 

Some new "Sienna Cichlid" related commits in radeonSI MESA driver

• Phoronix.com - Radeon Navi 2 "Sienna Cichlid" Published For AMD's OpenGL Driver
• freedesktop.org/mesa - radeonsi: add support for Sienna Cichlid

EDIT: Corrected Phoronix link.

Some interesting stuff:

ac_gpu_info.c

Code:

if (info->chip_class >= GFX10_3)
        info->max_wave64_per_simd = 16;
    else if (info->chip_class == GFX10)
        info->max_wave64_per_simd = 20;
    else if (info->family >= CHIP_POLARIS10 && info->family <= CHIP_VEGAM)
        info->max_wave64_per_simd = 8;

 

I CTRL-Fed the RDNA whitepaper.

 

So, according to that commit, in Sienna there is 16-entry wavefront controller per SIMD, right?

 

Another interesting bit.

PHP:

if (ASICREV_IS_SIENNA_M(chipRevision))
            {
                m_settings.supportRbPlus   = 1;
                m_settings.dccUnsup3DSwDis = 0;
            }


I figured RB could mean a rendering backend.

 

Yeah, that's my conclusion as well. I guess 20 was too much for Navi, so they've shrank it to shave off some transistors.

 

Or they’ve managed to reduce pipeline latency and/or increase ILP such that 16 wavefronts per SIMD is enough to hide typical latencies.

For reference Turing allocates 8 wavefronts per SIMD down from 16 in Volta/Pascal. Ampere is back up to 16.

 

Does the M in ASICREV_IS_SIENNA_M mean that it will be a mobile part?

 

I haven't even notice it.

Code:

#define ASICREV_IS_VEGA10_M(r)         ASICREV_IS(r, VEGA10)
#define ASICREV_IS_VEGA10_P(r)         ASICREV_IS(r, VEGA10)

Vega 10 has never been released as a mobile part, right? There are some chips with V. I really can't find logic behind it, maybe Value, Mid and Performance?

Edit: oh, and Vega M is apparently P.

Code:

#define ASICREV_IS_VEGAM_P(r)          ASICREV_IS(r, VEGAM)

 

I found some old tweet by komachi which says that M stands for "Mainstream" , unless things have changed. But it could indicate that Sienna Cichlid may not be the "Big Navi" that we're looking for. ¯\_(ツ)_/¯

 

After seeing 128-bit bus I didn't ever think it is. I wonder why they pushed this one into the driver before Big Navi.