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

[agd5f]

???
in

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/871675-amd-unleashes-initial-amdgpu-driver-support-for-gcn-1-0-southern-islands-gpus?p=877125#post877125

you have Curaçao/Pitcairn NOT Tahiti.

All VCE 1.0 parts (SI, Trinity/Richland) parts use the same VCE firmware.

[dammarin]

Thank you for taking the time to help me out with this.

I tried Mint 17.3, removing quiet splash from the kernel line. I got some interesting output now. First it detects 6 monitor outputs which look like this:

Connector 2:
DP-3
HPD3
DDC: 0x6530 0x6530 0x6534 ...
Encoders:
DFP3: INTERNAL_UNIPHY2

These seem to be the 6 Thunderbolt/DP outputs. What I find interesting is that I don't think I see the HDMI output here. The monitor is connected via HDMI btw.

Then:

radeon 000:02:00.0: No connectors reported connected with modes
[drm] Cannot find any critic or sizes - going 1024x768
[drm] fb mappable at 0x80479000
[drm] vram apper at 0x80000000
[drm] size 3145728
[drm] fb depth  is 24
[drm] pitch is 4096
radeon 0000:02:00.0: fb1: radeondrmfb frame buffer device
radeon 0000:02:00.0: registered panic notifier
[drm] Initializad radeon 2.40.0 20080528 for 0000:02:00.0 on minor 0
fb: switching to radeondrmfb from EFI VGA

and this is where it stalls.

I like how it wants to set a 1024x768 res. The console is at 1080p on a 1080p screen.

[dammarin]

After adding TAHITI_vce.bin to Ubuntu 14.04.4, the error goes away, but the boot still stalls at the same spot without any meaningful messages. :-( Will try Ubuntu 16.04 next.

[dammarin]

Ubuntu 16.04 does the exact same thing as Mint 17.3 above. I dug out a DP->HDMI cable, but the result is still the same :-(

[papu]

then ¿which version of these components i need to get gcn1.0 support on my curaçao pro r9 270 video card ?
(in braketes the current version i am using)

kernel(4.6.4-gentoo), xorg-server(1.18.4), llvm(3.8.1), mesa(12.0.1), libdrm(2.4.69), drivers(xf86-video-ati-7.7.0), others?...

thanks so much.

[haagch]

Obligatory disclaimer that the driver is not finished and may not be usable at all so far.

First you need the drm-next-4.8-wip-si branch from this kernel repository: https://cgit.freedesktop.org/~agd5f/...ext-4.8-wip-si
In the config, set CONFIG_DRM_AMDGPU_SI=y.
But with only that branch you will likely not be able to render anything with mesa because it will hang. A clever user (?) has figured out how to make at least the hang go away, so you need to apply this patch: https://github.com/flto/linux/commit...4048304c.patch

With the kernel alone you can run some "offscreen tests", but not use mesa yet.
For that there are a couple of amdgpu-si branches that are mostly just wiring already existing things up and adding pciids:
Mesa: https://cgit.freedesktop.org/~mareko...g/?h=amdgpu-si
libdrm: https://cgit.freedesktop.org/~mareko...g/?h=amdgpu-si
amdgpu: https://cgit.freedesktop.org/~mareko...g/?h=amdgpu-si

Then, if xf86-video-ati is installed, uninstall it. X will hang on startup if it is installed and you try to run your GPU with amdgpu.

Then, blacklist radeon. Create
/etc/modprobe.d/graphicdrivers.conf
with

install radeon /bin/false

I did not try running an X server on my GPU, but I'm pretty sure I heard someone say that it's buggy. I just used it with PRIME. xonotic and csgo work, bioshock causes TTM errors and then it requires a reboot.
I did not try much more, because right now power management doesn't seem to be working for anyone who has tried it so everything is pretty slow. But now that rendering with mesa works, we'll probably see something usable very soon once Alex Deucher is back.

As for the question:
xorg-server needs no changes, just the xf86-video-amdgpu driver. Maybe it just works with modesetting even, but I don't know.
llvm needs no change either, but might just as well update it to the latest development version when you're testing cutting edge stuff anyway.

Obligatory repeating of the disclaimer that the driver is still largely broken and not fit for anything but satisfying your curiosity about its current state.

[bridgman]

What haagch said... if you are not working on the driver as a developer or (whatever comes before alpha) tester then please stay with the radeon stack that gets installed by default. The GCN 1.0 support for amdgpu is still in development and not ready for general use.

[papu]

ok then i need at less kernerl4.8 , new mesa and amdgpu drivers with the kernel amd gpu options actived( all they?)



i don't know what are cik and userptr options...


and in my case have to change
VIDEO_CARDS="radeon radeonsi" to VIDEO_CARDS="amdgpu radeonsi" in my make.conf from gentoo.

[haagch]

ok then i need at less kernerl4.8 , new mesa and amdgpu drivers

Specifically the repositories and branches I mentioned. The code is not merged anywhere else. It's still in the "bring-up" phase. Once the developers have something that works reliably enough to be widely tested, it will become available in upstream mesa, libdrm, xf86-video-amdgpu and the kernel.

with the kernel amd gpu options actived( all they?)

https://i.imgur.com/4GH1B3m.png

i don't know what are cik and userptr options...

CIK is the codename for the GCN 1.1. Whether that is enabled or not makes no difference for your GPU. You only need CONFIG_DRM_AMDGPU_SI.
userptr is just some feature. Something about sharing pointers to buffers in userspace memory with the GPUs. Not sure what it's used for, but there's no reason not to enable it.

No idea about gentoo.

Is there a specific reason you want to test this? It seriously isn't all ready yet...

Maybe for testing Vulkan? That's what I tried at least. With the amdgpu-si libdrm branch this happens:

vulkaninfo: symbol lookup error: /amdgpu//usr/lib/x86_64-linux-gnu/amdvlk64.so: undefined symbol: amdgpu_get_marketing_name

The modified libdrm and xf86-video-amdgpu from the amdgpu-pro are still not available, so there's no way to merge these two together. It may be possible to implement the missing functions yourself, but that gets into the area of unreasonably much work for what simply isn't ready yet.

[bridgman]

FYI userptr is about taking an OS-allocated buffer (eg via malloc/mmap) and turning it into a graphics driver buffer so the GPU can operate on it.

It's interesting because sometimes the OS decides to move physical pages around underneath OS-allocated buffers (and the GPU doesn't normally read CPU page tables) so you need to plant an MMU notifier and then kinda go bottom-up through the driver stack on a mapping change instead of top-down fixing everything up. IIRC locking order issues make it really fun.