Announcement

Collapse
No announcement yet.

RadeonSI / GLAMOR Support Still M.I.A. From Ubuntu 13.10

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

  • #16
    Originally posted by CalcProgrammer1 View Post
    Yeah, GLAMOR library is finally in 13.10 but the radeon driver wasn't built with glamor support. Rebuilding it it's working fine for me now but there's still a bug with DRI PRIME and multi-GPU. Glamor is required to use DRI PRIME between an r600 APU and a radeonsi discrete GPU from what I've read but my radeonsi 7730M is being detected as r600 and DRI PRIME crashes X when used. I'm pretty disappointed in Ubuntu's package managing team for this screwup when all the code is ready to use, they just refuse to build it right. Can't wait for oibaf/xorg-edgers to start pushing 13.10 releases that have all the compile options set.
    any proof of this, like a bug on launchpad?

    The driver was rebuilt with glamor support, and I heard it worked at least for someone.. don't have the hw myself.

    Comment


    • #17
      Originally posted by CalcProgrammer1 View Post
      Rebuilding it it's working fine for me now but there's still a bug with DRI PRIME and multi-GPU. Glamor is required to use DRI PRIME between an r600 APU and a radeonsi discrete GPU from what I've read but my radeonsi 7730M is being detected as r600 and DRI PRIME crashes X when used.
      If it hasn't been done, you should report the bug. I have an Intel hd4000 and an Amd hd 7730M, and it is detected properly (though I don't use ubuntu).

      By curiosity, I'd like to see some logs showing the bug. It's hard for me to believe the hd7730M is recognized as r600 (yes both use the same DDX, but the DDX load them differently, so there shouldn't be issues).

      Comment


      • #18
        https://bugs.freedesktop.org/show_bug.cgi?id=70409

        I put in a bug report for the issue, see attached xorg log. When it lists the drivers it shows r600.

        [ 10291.957] (II) RADEON(0): [DRI2] Setup complete
        [ 10291.957] (II) RADEON(0): [DRI2] DRI driver: r600
        [ 10291.957] (II) RADEON(0): [DRI2] VDPAU driver: r600

        This is after the driver goes through initialization for both ARUBA (7660G) and VERDE (7730M). Also there is an error where EGL fails to initialize on the VERDE while it initializes successfully on ARUBA which is odd.

        Comment


        • #19
          Originally posted by CalcProgrammer1 View Post
          https://bugs.freedesktop.org/show_bug.cgi?id=70409

          I put in a bug report for the issue, see attached xorg log. When it lists the drivers it shows r600.

          [ 10291.957] (II) RADEON(0): [DRI2] Setup complete
          [ 10291.957] (II) RADEON(0): [DRI2] DRI driver: r600
          [ 10291.957] (II) RADEON(0): [DRI2] VDPAU driver: r600

          This is after the driver goes through initialization for both ARUBA (7660G) and VERDE (7730M). Also there is an error where EGL fails to initialize on the VERDE while it initializes successfully on ARUBA which is odd.
          ARUBA does use r600. I have a A8-5500 with 7560D and it uses r600. The Trinity (and Richland probably) IGPs all use it.
          The radeon driver might initialize both cards, but xorg is another matter:

          Code:
          [ 10285.686] (==) No device specified for screen "Default Screen Section".
          	Using the first device section listed.
          [ 10285.686] (**) |   |-->Device "7660G"
          Xorg is using the first card. I dont think you can use 2 cards at once in xorg, you should set it up specifically for one of them in xorg.conf based in the PCI ID.
          Notice the * in front of the first card (the IGP):

          Code:
          [ 10285.687] (II) xfree86: Adding drm device (/dev/dri/card0)
          [ 10285.688] (II) xfree86: Adding drm device (/dev/dri/card1)
          [ 10291.463] (--) PCI:*(0:0:1:0) 1002:9900:103c:1831 rev 0, Mem @ 0xd0000000/268435456, 0xf0400000/262144, I/O @ 0x00004000/256
          [ 10291.463] (--) PCI: (0:1:0:0) 1002:682f:103c:1831 rev 0, Mem @ 0xe0000000/268435456, 0xf0300000/262144, I/O @ 0x00003000/256, BIOS @ 0x????????/131072

          Comment


          • #20
            Originally posted by CalcProgrammer1 View Post
            see attached xorg log. When it lists the drivers it shows r600.

            [ 10291.957] (II) RADEON(0): [DRI2] Setup complete
            [ 10291.957] (II) RADEON(0): [DRI2] DRI driver: r600
            [ 10291.957] (II) RADEON(0): [DRI2] VDPAU driver: r600

            This is after the driver goes through initialization for both ARUBA (7660G) and VERDE (7730M).
            That is for the 7660 .... notice the index: Radeon(0) ... the index for the 7730 adapter is: Radeon(G0) ... as a side note, It used to be a case that they would have been indexed as Radeon(0) and Radeon(1), which I think is a little more clear ... don't recall when (or why) this change to "(Gn)" occurred.

            Also there is an error where EGL fails to initialize on the VERDE while it initializes successfully on ARUBA which is odd.
            Yes, that is problematic, and you can see the cascading effect:
            Code:
            [ 10291.955] (EE) RADEON(G0): Failed to create EGL context
            [ 10291.955] (EE) RADEON(G0): glamor detected, failed to initialize EGL.
            ..
            [ 10291.955] (II) RADEON(G0): KMS Color Tiling: disabled
            [ 10291.955] (II) RADEON(G0): KMS Color Tiling 2D: disabled
            ...
            [ 10291.957] (WW) RADEON(G0): Direct rendering disabled
            [ 10291.957] (II) RADEON(G0): Acceleration disabled

            Comment


            • #21
              Originally posted by gradinaruvasile View Post
              The radeon driver might initialize both cards, but xorg is another matter:

              Code:
              [ 10285.686] (==) No device specified for screen "Default Screen Section".
              	Using the first device section listed.
              [ 10285.686] (**) |   |-->Device "7660G"
              Xorg is using the first card.
              Indeed, Screen0 is comprised by the 7660 adapter ... the fact that it actually had a name is likely a user config of the xorg.conf.d file ... as no other user info was supplied, and automagic configuration continued:
              Code:
              [ 10285.686] (==) Automatically adding devices
              [ 10285.686] (==) Automatically enabling devices
              [ 10285.686] (==) Automatically adding GPU devices
              I dont think you can use 2 cards at once in xorg, you should set it up specifically for one of them in xorg.conf based in the PCI ID.
              • As you noted, the DRM configures both adapters, albeit the 1:1 adapter to Screen correspondence still applies, so by default X can only enable the first Screen (which is associated with adapter0)
              • What you have proposed is perfectly legitimate -- you would be setting up and enabling two distinct Screens (no passing windows between ... which is desirable in certain configurations) within the X Display
              • However, by the virtue of xrandr's provider objects capabilities ( a million and one thanks to Airlie -- You rock Dave!), you can now have two Screens joined seamlessly, and rather simply:
                Code:
                xrandr --setprovideroutputsource <prov-xid> <source-xid>
                Then use either xrandr itself, or one of the frontends (Kscreen is the easiest and clearest in relation to this) to turn on the output on the second adapter, so as to get the combined desktop
              In any regard, that wasn't what he was doing though; he was using the offload feature of provider objects ... i.e. offloading the 3D/GL rendering to the discrete SI adapter, and output that via the APU adapter. ... which actually reminds me of something

              Comment


              • #22
                CalcProgrammer1, from your bug report:
                adam@Adam-dv6z-7000:~$ xrandr --listproviders
                Providers: number : 3
                Provider 0: id: 0x6c cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 2 name:radeon
                Provider 1: id: 0x45 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 2 name:radeon
                Provider 2: id: 0x45 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 2 name:radeon

                adam@Adam-dv6z-7000:~$ xrandr --setprovideroffloadsink 0x45 0x6C
                I note that you are passing the old style of args. that were used ... specifically, you're using the provider ID as opposed to the prov-xid (as in X's ID for that provider). Check "xrandr --help" to see what your version specifies ... it may work for both (haven't tried), but newer xrandr allows for use of the simpler provider ID i.e.:
                Code:
                xrandr --setprovideroffloadsink 1 0
                Not sure why you have three Providers listed too.

                Comment


                • #23
                  Maybe the fact that Provider 0 (the IGP) has 3 "outputs" and the rest have 0 has something to do with it?
                  AFAIK these card combinations use the dedicated card only for processing and it has no physical video outputs as it is wired only internally, all the output is done by the IGP.

                  Comment


                  • #24
                    Originally posted by gradinaruvasile View Post
                    Maybe the fact that Provider 0 (the IGP) has 3 "outputs" and the rest have 0 has something to do with it?
                    AFAIK these card combinations use the dedicated card only for processing and it has no physical video outputs as it is wired only internally, all the output is done by the IGP.
                    It might very well be the case that no output is wired to the discrete 7730 adapter, but PowerXpress/Optimus laptops have proven to use a variety of configurations for the output connections (i.e. AFAIK, there is absolutely no standardization, and its pretty much up to the whims of the OEM) ... but I'm also open to the possibility that the reporting is completely bugged up on the second adapter ... trying to think if glamor not functioning for it would/might cause it to be reported twice as a Provider by xrandr ... but getting sleepy.

                    Comment


                    • #25
                      Originally posted by CalcProgrammer1 View Post
                      This is after the driver goes through initialization for both ARUBA (7660G) and VERDE (7730M). Also there is an error where EGL fails to initialize on the VERDE while it initializes successfully on ARUBA which is odd.
                      The 7660G uses exa, and the 7730M Glamor.

                      According to the logs, Glamor fails to initialize EGL. The possible cause of this is a Mesa version not compiled with the right flags, or Glamor itself compiled with special flags. Look at Glamor webpage, it is explained what is needed.

                      Comment


                      • #26
                        Originally posted by mannerov View Post
                        The 7660G uses exa, and the 7730M Glamor.
                        No, he has both of them set to use glamor:
                        Code:
                        [ 10291.492] (**) RADEON(0): Option "AccelMethod" "glamor"
                        ...
                        [ 10291.951] (**) RADEON(G0): Option "AccelMethod" "glamor"
                        ...
                        [ 10292.111] (II) RADEON(0): Use GLAMOR acceleration.
                        [ 10292.111] (II) RADEON(0): Acceleration enabled
                        According to the logs, Glamor fails to initialize EGL
                        yes, but only for the 7730 (see above posts, I already pointed this out)

                        The possible cause of this is a Mesa version not compiled with the right flags, or Glamor itself compiled with special flags. Look at Glamor webpage, it is explained what is needed.
                        Nope, not applicable, as its working for the r600 adapter.
                        Last edited by Tyler_K; 10-13-2013, 03:41 AM.

                        Comment


                        • #27
                          Originally posted by CalcProgrammer1 View Post
                          https://bugs.freedesktop.org/show_bug.cgi?id=70409

                          I put in a bug report for the issue, see attached xorg log. When it lists the drivers it shows r600.

                          [ 10291.957] (II) RADEON(0): [DRI2] Setup complete
                          [ 10291.957] (II) RADEON(0): [DRI2] DRI driver: r600
                          [ 10291.957] (II) RADEON(0): [DRI2] VDPAU driver: r600

                          This is after the driver goes through initialization for both ARUBA (7660G) and VERDE (7730M). Also there is an error where EGL fails to initialize on the VERDE while it initializes successfully on ARUBA which is odd.
                          the log doesn't prove much of the original issue you claimed. Make sure you have the stock driver and xdiagnose installed, then run 'ubuntu-bug xorg' and it'll attach all the relevant logs to the bugreport..

                          Comment


                          • #28
                            Originally posted by Tyler_K View Post
                            No, he has both of them set to use glamor
                            Right, I missed that.

                            It's strange that Glamor fails to create an egl context on the radeonsi card and not the r600 card. Maybe Mesa wasn't compiled with radeonsi support?

                            Comment


                            • #29
                              Yeah, I have glamor set as AccelMethod in my xorg.conf.d so both cards are using glamor and you can definitely tell a difference between EXA and glamor on the r600 card, it's MUCH smoother with glamor and 3d stuff doesn't lag at all now.

                              I didn't know about the 0 vs. G0 part so that makes sense. The discrete GPU has no outputs from my understanding, it is a muxless system and all the outputs on the laptop (LVDS for internal panel, VGA on the side, and HDMI on the side) are all connected to the APU's graphics processor. Therefore I expect it should not be tied to a Screen and rather just be an offload provider for rendering. Is there any way to list if Mesa has been built with radeonsi support? I'm pretty sure it has looking at the build scripts which appear to include radeonsi for amd64 platforms but I'd like to know if my binaries have it built in.

                              Comment


                              • #30
                                Originally posted by mannerov View Post
                                Maybe Mesa wasn't compiled with radeonsi support?
                                Good point. I was presupposing that radeonsi was actually being built. Glancing over Michael's article, I don't see indication of that. I'm not a Ubuntu user, so I wouldn't know what they're packaging. I could tell you how to check if the build flag was passed in the case of an rpm, but don't know what it is for deb. But in any, the --with-gallium-drivers="..." flag should contain a radeonsi target if the Mesa build is to include the driver.

                                As an even simpler check
                                Code:
                                ls /usr/lib*/dri | grep radeonsi
                                should reveal whether its present in the system (regardless, of whether the Mesa build included it or not).

                                Comment

                                Working...
                                X