AMD Unleashes Initial AMDGPU Driver Support For GCN 1.0 / Southern Islands GPUs

[juno]

amdgpu seems to be getting support for all the cards currently supported by radeonsi. Doesn't that mean that eventually, radeonsi will disappear?

radeonsi is the hardware specific mesa driver (for OpenGL). amdgpu on the other side is the kernel/drm driver. Those amdgpu-supported cards are also using radeonsi.
The alternative (and at this time official) kernel driver for GCN Gen.1&2 (SI&CIK) is radeon. This also supports older cards like nothern islands and evergreen, so it won't just dissapear either

[bridgman]

radeonsi is the hardware specific mesa driver (for OpenGL). amdgpu on the other side is the kernel/drm driver. Those amdgpu-supported cards are also using radeonsi.

Right. Whether you use the radeon kernel driver (currently recommended for SI and CI) or the amdgpu kernel driver, the open source stack uses the same radeonsi Gallium3D driver for GL, CL and video decode/encode.

[Tomin]

Right. Whether you use the radeon kernel driver (currently recommended for SI and CI) or the amdgpu kernel driver, the open source stack uses the same radeonsi Gallium3D driver for GL, CL and video decode/encode.

I wonder how many times a week you need to repeat this.

[Xelix]

Thanks juno & bridgman for the clarification. I got confused with all those names .

[Berniyh]

- amdgpu fails to correctly render Shadow of Mordor on R9 390

Hm, wouldn't think that there is a significant difference, since they both use radeonsi?

- amdgpu (in Linux 4.6.0) isn't providing /sys/kernel/debug/dri/... files

root@orionis:~ $ ls -1 /sys/kernel/debug/dri/0
amdgpu_fence_info
amdgpu_gem_info
amdgpu_gtt
amdgpu_gtt_mm
amdgpu_pm_info
amdgpu_regs
amdgpu_ring_cp1
amdgpu_ring_cp2
amdgpu_ring_dma1
amdgpu_ring_dma2
amdgpu_ring_gfx
amdgpu_ring_uvd
amdgpu_ring_vce1
amdgpu_ring_vce2
amdgpu_sa_info
amdgpu_vram
amdgpu_vram_mm
bufs
clients
DP-1
DVI-D-1
gem_names
HDMI-A-1
name
ttm_page_pool
VGA-1
vm
vma

But yeah, that's on 4.5.4, not 4.6.0. And a lot of them are empty, no idea if they shouldn't be.

[nanonyme]

Right. Whether you use the radeon kernel driver (currently recommended for SI and CI) or the amdgpu kernel driver, the open source stack uses the same radeonsi Gallium3D driver for GL, CL and video decode/encode.

Now if only the kernel driver was called radeonsi and you could just say GCN->radeonsi without any confusions on kernel and userspace

[bridgman]

Now if only the kernel driver was called radeonsi and you could just say GCN->radeonsi without any confusions on kernel and userspace

Yeah, that's the funny part... if/when it takes over SI/CI upstream support from radeon then we really could call it radeonsi. In the past that would have been more confusing than the current naming.

That said, if we're going to do anything with names I want to start seeing fully qualified names, eg putting a 'k' in for kernel drivers, 'x' in for DDX's, 'p' for gallium3d pipe drivers and 'w' for gallium3d winsys. Maybe even 'l' for libdrm

[haagch]

As expected, without mesa/libdrm e.g. "DRI_PRIME=1 glxinfo" doesn't work. The message is funny though:

[FONT=monospace][COLOR=#000000]amdgpu: amdgpu_device_initialize failed. [/COLOR]
do_winsys_init: DRM version is 3.2.0 but this driver is only compatible with 2.12.0 (kernel 3.2) or later.[/FONT]

Should probably revise the "or later" part a bit.

I guess that's what's meant with "basic OpenGL".
Makes me hopeful that it will already just work with DRI_PRIME though.

Looks like the required changes for mesa and libdrm are coming:
SI support for amdgpu winsys: https://cgit.freedesktop.org/~mareko...g/?h=amdgpu-si
SI support for amdgpu in libdrm: https://cgit.freedesktop.org/~mareko...g/?h=amdgpu-si
SI support for xf86-video-amdgpu: https://cgit.freedesktop.org/~mareko...g/?h=amdgpu-si

It's not ready for use though, when trying to render something, it just hangs before doing anything. I think that's what mareko is debugging at the moment, based on the commit https://cgit.freedesktop.org/~mareko...0bc4d6e21ccdd1

As strace shows:

[FONT=monospace][COLOR=#000000]write(1, "before backend init\n", 20before backend init [/COLOR]
)   = 20
ioctl(6, DRM_IOCTL_VIA_ALLOCMEM, 0x7ffdefb4b2f0) = 0
ioctl(6, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x48, 0x28), 0x7ffdefb4b2f0) = 0
ioctl(6, DRM_IOCTL_TEGRA_GEM_MMAP, 0x7ffdefb4b400) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x100111000) = 0x7fd08c415000
ioctl(6, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x43, 0x18), 0x7ffdefb4b340) = 0
ioctl(6, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x44, 0x18), 0x7ffdefb4b320) = 0
ioctl(6, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x43, 0x18), 0x7ffdefb4b370) = 0
ioctl(6, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x49, 0x20)[/FONT]

A real problem is that intel graphics isn't stable on drm-next-4.8-wip, so even if SI on amdgpu were to work fine right now, I couldn't use it. It just randomly freezes the whole machine with nothing in the logs. It's also easily triggered by starting warcraft 3 in wine.

[haagch]

What if you disable intel graphics via pci api at boot.

http://superuser.com/questions/541854/disable-specific-pci-device-at-boot

Then I see nothing, because the radeon GPU is physically not connected to the display.

[haagch]

Then you could say to the system that let us play all the time. In windows you have some check box for that.

Wat.

I would not expect miracles from initial prototype driver in the case of switching mixed graphics. See the source code if amd has even tried that.

I actually expect that it works better, because (with dri3) there is no ddx involved. Just render nodes is all that is needed and it's already exposed as /dev/dri/renderD129.