Announcement

Collapse
No announcement yet.

Nouveau Releases New Driver With PRIME Support

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

  • Nouveau Releases New Driver With PRIME Support

    Phoronix: Nouveau Releases New Driver With PRIME Support

    The xf86-video-nouveau 1.0.2 driver was released today to take advantage of the new capabilities of X.Org Server 1.13...

    http://www.phoronix.com/vr.php?view=MTE4MzA

  • #2
    Besides the RADEON drivers still not have this support.
    the last drivers release today in ppa's for ubuntu with xorg1.13 and up.
    Now, when using the xorg.conf and being specific with the radeon driver and pci device. The system boot well, didn't crash, didn't give error about link/atom bios crash. and i know the system can boot perfect. BUT i cant see the screen YET. If i type the password ( doing this in a blind way) everything load ( i can rear) But i cant See it. no error in xorg.log or dmesg.

    A BIG STEP AHEAD

    Comment


    • #3
      Originally posted by fritzls View Post
      Besides the RADEON drivers still not have this support.
      If you manage to be a bit specific about the exact versions of involved software you use you might want to file a bug report. I can't test it because my notebook only has one card but my xrandr from git says this:
      Code:
       ./xrandr --listproviders
      Providers: number : 1
      Provider 0: id: 88 cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 6 outputs: 3 associated providers: 0 name:radeon

      Comment


      • #4
        http://nouveau.freedesktop.org/wiki/FeatureMatrix
        http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/

        Seems it is only Dave Airlie, Adam Jackson, and Ben Skeggs working on nouveau.

        Wayland does still not work with nouveau on Ubuntu.

        Comment


        • #5
          Originally posted by phoronix View Post
          Phoronix: Nouveau Releases New Driver With PRIME Support

          The xf86-video-nouveau 1.0.2 driver was released today to take advantage of the new capabilities of X.Org Server 1.13...

          http://www.phoronix.com/vr.php?view=MTE4MzA
          Can someone explain if PRIME can be leveraged for heterogeneous gpu work?

          Comment


          • #6
            Originally posted by ChrisXY View Post
            If you manage to be a bit specific about the exact versions of involved software you use you might want to file a bug report. I can't test it because my notebook only has one card but my xrandr from git says this:
            Code:
             ./xrandr --listproviders
            Providers: number : 1
            Provider 0: id: 88 cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 6 outputs: 3 associated providers: 0 name:radeon
            It's not a bug at all. And i'm talking about AMD RADEON not NVIDI+bumblebe
            from what i Understand it's a behaviour.
            Radeon driver loads now perfect. but still not the output from intel card.
            Before, when the radeon driver loaded and didn't find the output monitor, he break giving a error and crashing the xorg. now the xorg load. didnt crash anymore. Just doesn't show nothing because there is not physical output from radeon ( output still being owned by the intel hardware).
            They are aware of this. Not rush with more one bug filled. Just wait they do the work they are being done.

            ho. About hardware. xrandr --listproviders didnt swork with this command --listproviders .
            but the hardware.
            01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Broadway [ATI Mobility Radeon HD 6800 Series] (prog-if 00 [VGA controller])
            Subsystem: Hewlett-Packard Company Device 159b
            Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
            Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
            Latency: 0, Cache Line Size: 64 bytes
            Interrupt: pin A routed to IRQ 53
            Region 0: Memory at a0000000 (64-bit, prefetchable) [size=256M]
            Region 2: Memory at c0700000 (64-bit, non-prefetchable) [size=128K]
            Region 4: I/O ports at 3000 [size=256]
            Expansion ROM at c0740000 [disabled] [size=128K]
            Capabilities: <access denied>
            Kernel driver in use: radeon
            Kernel modules: radeon

            00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
            Subsystem: Hewlett-Packard Company Device 159b
            Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
            Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
            Latency: 0
            Interrupt: pin A routed to IRQ 54
            Region 0: Memory at c0000000 (64-bit, non-prefetchable) [size=4M]
            Region 2: Memory at b0000000 (64-bit, prefetchable) [size=256M]
            Region 4: I/O ports at 4000 [size=64]
            Expansion ROM at <unassigned> [disabled]
            Capabilities: <access denied>
            Kernel driver in use: i915
            Kernel modules: i915

            Comment


            • #7
              Originally posted by fritzls View Post
              It's not a bug at all. And i'm talking about AMD RADEON not NVIDI+bumblebe
              from what i Understand it's a behaviour.
              Radeon driver loads now perfect. but still not the output from intel card.
              Before, when the radeon driver loaded and didn't find the output monitor, he break giving a error and crashing the xorg. now the xorg load. didnt crash anymore. Just doesn't show nothing because there is not physical output from radeon ( output still being owned by the intel hardware).
              They are aware of this. Not rush with more one bug filled. Just wait they do the work they are being done.

              So the drivers are PRIME-aware, in that multiple GPU's no longer causes an exception / crashes Xorg, but not PRIME-usable, in that output is still broken?

              Comment


              • #8
                Originally posted by Ericg View Post
                So the drivers are PRIME-aware, in that multiple GPU's no longer causes an exception / crashes Xorg, but not PRIME-usable, in that output is still broken?
                Yeap. Exact "So the drivers are PRIME-aware, in that multiple GPU's no longer causes an exception / crashes Xorg, but not PRIME-usable"

                A big step ahead from last years. Lets wait until RADEON driver get the prime ( or better ) support to. And AMD cards have a more mature way to play like NVIDIA.

                Funny is that linux is the oposite from Microsoft.
                At the release. Microsoft get the drive working, but late, when they stop to release drivers. Everything become fucked and you cant use your hardware anymore ( just look ahead IF manufacturer like hp will release some driver for WIN8. If same for the new one they are not ).

                Linux sometimes is slow to get some hardware support. but when this come. STAY THERE, STRONG.

                Comment


                • #9
                  Maybe Dave Airlie would know best, just because it was his work that lead us to RandR 1.5, but does anyone know how much work its going to be for the drivers to know when to switch between the two graphics cards? From what I've read through the articles now with Xorg 1.13 we can have both GPU's working together and their graphics buffers can be shared. Awesome. If one card isnt doing work, Xorg can issue power management commands to turn off the piece of hardware. Awesome.

                  On mac and windows, the OS can decide when a graphics load is heavy enough that it should switch from the integrated card to the discrete card. Does Xorg (or would it be possible with more refactoring / updating) have a way to detect which graphics card is better? Does it have a way to measure GFX load and set a threshold for when it should move the GFX load to the discrete card, turning it on in the process of a reasonable number of vsync's, or when the load is low enough that it can move b ack the integrated card and turn off the discrete card, also within a reasonable number of vsync's?

                  Not trying to discredit everyone's work on PRIME, i'm just trying to get a good feel of where the linux community truely stands on the issue of hybrid graphics at this point now that we have support for multiple GPU's.

                  Comment


                  • #10
                    Dude. to be honest.
                    I give another update now and play again with primus and mine AMD.

                    ./xrandr --listproviders
                    Provider 0: id: 144 cap: b nc: 2 no: 6 nap 0 name:Intel
                    Provider 1: id: 89 cap: d nc: 6 no: 4 nap 0 name:radeon

                    xrandr --setprovideroffloadsink 89 144
                    DRI_PRIME=1 glxinfo


                    OpenGL renderer string: Gallium 0.4 on AMD JUNIPER
                    OpenGL version string: 2.1 Mesa 9.0-devel
                    OpenGL shading language version string: 1.30


                    DRI_PRIME=0 glxinfo
                    OpenGL vendor string: Intel Open Source Technology Center
                    OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
                    OpenGL version string: 3.0 Mesa 9.0-devel
                    OpenGL shading language version string: 1.30
                    OpenGL extensions:

                    WTF. It's working......
                    Last edited by fritzls; 09-12-2012, 09:17 PM.

                    Comment


                    • #11
                      HaHaHa
                      I'm happy today...


                      root@arpia:/opt/xorg/bin# DRI_PRIME=0 glxgears
                      Running synchronized to the vertical refresh. The framerate should be
                      approximately the same as the monitor refresh rate.
                      303 frames in 5.0 seconds = 60.501 FPS
                      301 frames in 5.0 seconds = 60.006 FPS
                      ^C
                      root@arpia:/opt/xorg/bin# DRI_PRIME=1 glxgears
                      Running synchronized to the vertical refresh. The framerate should be
                      approximately the same as the monitor refresh rate.
                      8350 frames in 5.0 seconds = 1669.853 FPS
                      7808 frames in 5.0 seconds = 1561.494 FPS

                      Comment


                      • #12
                        Originally posted by fritzls View Post
                        HaHaHa
                        I'm happy today...
                        fritzl, which xf86-video-ati version are you using?

                        zzippy

                        Comment


                        • #13
                          Originally posted by zzippy View Post
                          fritzl, which xf86-video-ati version are you using?

                          zzippy
                          I'm using quantal with proposed enabled and last from xorg edgers ( the last update yesterday was the one turn everything working).

                          good to know that at last this work.
                          Not yet a GPU SWITCH, Still 2 cards working same time. But a good start.. Very good.

                          Comment


                          • #14
                            since using the ati with prime didnt return me 0 of error when starting compiz or unity by hand.
                            If someone here know what and where to change to turn this automatic when unity r compiz start in ubuntu. You are welcome. i'm lazy today to dig in it.

                            Comment


                            • #15
                              Hrm, thought you would run some X manually built to /opt/xorg? Sent you a pm ;-)

                              Comment

                              Working...
                              X