AMD Ryzen 5 3400G Is Working Well On Linux

[CochainComplex]

.... padoka, which seems to be outdated by a large time margin to oibaf's....

I had always the impression that padoka is a bit more bleeding edge?

[stiiixy]

My 2200G (which I've had nothing but drama's with getting to work above two cores, but otherwise works perfectly on a B450 mobo) has the exact same output vdpauinfo output as Hibbelharry 's above. vainfo yielded the same results, excepting the version differances (I'm using padoka, which seems to be outdated by a large time margin to oibaf's, which I am about to test against a series of Mint kernels and soon-to-installed Ubuntu currents). All on Mint 19.3 Tina

[Djhg2000]

Yes, many users would like that, and requested in forums, on Reddit, etc. but AMD doesn't listen.
It could even be used in combination with a graphics card which provides acceleration. AMD reportedly ceased Radeon VII production due to lack of demand, but I think was rather poor product planning which sunk it. Radeon VII with the much requested SR-IOV support and Matisse with display controller (as SR-IOV will disable displays), that would have been a fantastic combination for developer workstations.

On the one hand I agree with the wish, on the other hand I don't think it wouldn't make much sense to actually do that until the mixed lithography I/O die concept had been proven. If AMD had launched Ryzen 3000 with a display controller on the I/O die then people not knowing any better would've speculated wildly about it being a compromise to fit a display controller in with every Ryzen 3000 model.

It's better if they take one step at a time and introduce an I/O die display controller with the Ryzen 4000 series. Considering the 3200G and 3400G still have a separate I/O die from the other Ryzen 3000 parts it would make even less sense for those other Ryzen 3000 parts to have an I/O die display controller. The APUs should clearly be the launch platform for such a feature and then it would be an "oh by the way, we didn't disable it for the regular Ryzen 4000 parts".

[Hibbelharry]

Please post the output of vainfo

Sure. Taken from my Ryzen 3400G HTPC setup

me@htpc:~$ vainfo
libva info: VA-API version 1.5.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_5
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.5 (libva 2.5.0)
vainfo: Driver version: Mesa Gallium driver 19.1.4 for AMD RAVEN (DRM 3.32.0, 5.2.0-10-generic, LLVM 8.0.1)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :    VAEntrypointVLD
      VAProfileMPEG2Main              :    VAEntrypointVLD
      VAProfileVC1Simple              :    VAEntrypointVLD
      VAProfileVC1Main                :    VAEntrypointVLD
      VAProfileVC1Advanced            :    VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:    VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:    VAEntrypointEncSlice
      VAProfileH264Main               :    VAEntrypointVLD
      VAProfileH264Main               :    VAEntrypointEncSlice
      VAProfileH264High               :    VAEntrypointVLD
      VAProfileH264High               :    VAEntrypointEncSlice
      VAProfileHEVCMain               :    VAEntrypointVLD
      VAProfileHEVCMain               :    VAEntrypointEncSlice
      VAProfileHEVCMain10             :    VAEntrypointVLD
      VAProfileJPEGBaseline           :    VAEntrypointVLD
      VAProfileVP9Profile0            :    VAEntrypointVLD
      VAProfileVP9Profile2            :    VAEntrypointVLD
      VAProfileNone                   :    VAEntrypointVideoProc

for your reference I went back to X11 and additionally fetched the output of vdpauinfo:

me@htpc:~$ vdpauinfo
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
-------------------------------------------
420    16384 16384  NV12 YV12
422    16384 16384  UYVY YUYV
444    16384 16384  Y8U8V8A8 V8U8Y8A8

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                    3 65536  4096  4096
MPEG2_MAIN                      3 65536  4096  4096
H264_BASELINE                  52 65536  4096  4096
H264_MAIN                      52 65536  4096  4096
H264_HIGH                      52 65536  4096  4096
VC1_SIMPLE                      1 65536  4096  4096
VC1_MAIN                        2 65536  4096  4096
VC1_ADVANCED                    4 65536  4096  4096
MPEG4_PART2_SP                  3 65536  4096  4096
MPEG4_PART2_ASP                 5 65536  4096  4096
DIVX4_QMOBILE                  --- not supported ---
DIVX4_MOBILE                   --- not supported ---
DIVX4_HOME_THEATER             --- not supported ---
DIVX4_HD_1080P                 --- not supported ---
DIVX5_QMOBILE                  --- not supported ---
DIVX5_MOBILE                   --- not supported ---
DIVX5_HOME_THEATER             --- not supported ---
DIVX5_HD_1080P                 --- not supported ---
H264_CONSTRAINED_BASELINE       0 65536  4096  4096
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---
HEVC_MAIN                      186 65536  4096  4096
HEVC_MAIN_10                   186 65536  4096  4096
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
R8G8B8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
R10G10B10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
B10G10R10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     -
INVERSE_TELECINE                 -
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y        48     4096
VIDEO_SURFACE_HEIGHT             y        48     4096
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y

[chithanh]

Actually, I'd welcome a display controller on the I/O die even without a proper GPU die.

Yes, many users would like that, and requested in forums, on Reddit, etc. but AMD doesn't listen.
It could even be used in combination with a graphics card which provides acceleration. AMD reportedly ceased Radeon VII production due to lack of demand, but I think was rather poor product planning which sunk it. Radeon VII with the much requested SR-IOV support and Matisse with display controller (as SR-IOV will disable displays), that would have been a fantastic combination for developer workstations.

[Djhg2000]

It has been suggested by various media outlets (mock-up below originally from AdoredTV), but so far nothing from AMD which indicates the existence of such a product:


That would require that there is a display controller on the Matisse I/O chiplet, but as far as I can tell nobody has identified one from the die shots yet. Thus, at least until next generation I/O chiplet, that seems unlikely.

Actually, I'd welcome a display controller on the I/O die even without a proper GPU die. Most of the time when you need an integrated display output on a high end part it's for things like updating UEFI out of the case or fixing GPU drivers. Basically something that would turn those display outputs which are on every AM4 motherboard anyway into something like a DisplayLink equivalent.

Embedded Ryzen shows limit as DCI 4K so 4096x2160 per single display, so limited by movie projector industry standards



Navi is year 2018 (since it have DSC 1.2a, in turn that is DP 1.4a), but when i see year 2016. on a chip like on this APU i don't ask more, instead i assume the same as it was

Once you see year 2019. on a chip, maybe you can assume to be up to date by the standards of that year

Too low, too bad...

I had worked occasionally on HiDPI displays, 4k, with 2x scaling, therefore effective "resolution", or desktop space is, FullHD. However, it look much sharper and easier to read.

Having support for 5k, with HiDPI, it would yield effective resolution, or desktop space, of QHD. However, with much sharper look. That would have had been great to work on.

I wish to have 5k display with 184 DPI for HiDPI with exactly 2x scale (easier for web scaling computation, and non HiDPI-compatible software scaling).

[muncrief]

And for the TUF Gaming X570-PLUS there was a BIOS update a week or so ago with "Update AGESA 1.0.0.3 Patch ABB to improve compatibility" So that should take care of it as long as you update.

Ah, thank you Michael and dungeon. I thought things had been fixed but like I said after I bought everything and began to look into the state of Ryzen 3000 on Linux I was confused.

But hey, I get confused quite easily now

[chithanh]

Die space. Space that is taken up for GPU cores is space that could be used for CPU cores.

Does it have to be on the same die? Couldn't the GPU be just another chiplet in the same package?

It has been suggested by various media outlets (mock-up below originally from AdoredTV), but so far nothing from AMD which indicates the existence of such a product:


That would require that there is a display controller on the Matisse I/O chiplet, but as far as I can tell nobody has identified one from the die shots yet. Thus, at least until next generation I/O chiplet, that seems unlikely.

[Michael]

I'm finally replacing my aging FX-6300 based system with Ryzen, and ordered a Ryzen 7 3700X as part of the new system. It's on back order and won't be here until September 3rd, but now I'm confused as to whether or not it's going to work with Linux. I thought all the problems had been solved but after looking around I'm seeing a lot of conflicting information. The motherboard is an ASUS TUF Gaming X570-Plus, and the memory is the CORSAIR Vengeance LPX 16GB (2 x 8).

I know this article is about a different CPU, but I thought I'd use the superior brains here to give me a definitive answer. So does anyone know if it's going to work with Manjaro? And if not, what will I need to do to make it work?

And for the TUF Gaming X570-PLUS there was a BIOS update a week or so ago with "Update AGESA 1.0.0.3 Patch ABB to improve compatibility" So that should take care of it as long as you update.