Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by dammarin View Post
    ... that one has TAHITI_vce.bin in /lib/firmware/radeon.

    14.04 gave me the TAHITI_vce.bin error. I just booted the same 14.04.4 USB stick on a different computer and there is no such file in /lib/firmware/radeon (there are some TAHITI files, though: ce, mc, mc2, me, pfp, rlc, smc and uvd).
    ???
    in
    https://www.phoronix.com/forums/foru...125#post877125
    you have Curaçao/Pitcairn NOT Tahiti.

    Comment


    • #92
      Originally posted by drSeehas View Post
      ???
      in
      https://www.phoronix.com/forums/foru...125#post877125
      you have Curaçao/Pitcairn NOT Tahiti.
      All VCE 1.0 parts (SI, Trinity/Richland) parts use the same VCE firmware.

      Comment


      • #93
        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:

        Code:
        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:
        Code:
        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.

        Comment


        • #94
          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.

          Comment


          • #95
            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 :-(

            Comment


            • #96
              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.
              Last edited by papu; 25 July 2016, 10:21 AM.

              Comment


              • #97
                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
                Code:
                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.

                Comment


                • #98
                  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.
                  Test signature

                  Comment


                  • #99
                    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.
                    Last edited by papu; 26 July 2016, 06:44 AM.

                    Comment


                    • Originally posted by papu View Post
                      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.

                      Originally posted by papu View Post
                      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:
                      Code:
                      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.

                      Comment

                      Working...
                      X