Announcement

Collapse
No announcement yet.

Nouveau's Gallium3D Driver Gets Video Boost

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

  • Nouveau's Gallium3D Driver Gets Video Boost

    Phoronix: Nouveau's Gallium3D Driver Gets Video Boost

    Younes Manton, the student developer that has been working on Generic GPU Video Decoding that allows video decoding to be done universally in the GPU's shaders with any Gallium3D driver, has made some more progress on the NVIDIA front. We last talked about the state of Gallium3D video decoding back in September when Manton's video decoding method was working, but at an awfully slow pace. Now with his work on the Gallium3D-based Nouveau driver for NVIDIA hardware, he has achieved more promising results. Thanks to the latest code in Gallium3D and an improvement in Nouveau's winsys layer, those using this community-developed driver can now play 1080p video clips...

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

  • #2
    cant wait till ati drivers are ported to gallium3d combined with kms and r600/700 having full support!
    2009 is going to rock!

    Comment


    • #3
      Yeah, a status update on Radeon + GEM/KMS/DRI2/Gallium3D would be nice (or have I missed something that was posted recently?). GEM is a dependency for all of them as far as I know, and Fedora 10 back in November was already running KMS stable for me, so some pieces should work I think.

      Comment


      • #4
        Heh, it seems my old FX5200 might still be useful for something after all

        Comment


        • #5
          Great work!

          Does this confirm that this is the right (=best/easiest/most effective) way to go also for amd/ati?

          Comment


          • #6
            It's definitely the easiest way, but unfortunately, while it takes a load off the CPU, it doesn't do much for power consumption, because it *does* put a substantial load on the GPU. It would be nice for people who want to watch DVDs on laptops, etc, to take advantage of fixed-function video decode hardware, but that's a lot harder, because it's non-generic and would have to be reverse-engineered.

            In the case of AMD/ATI, they may be able to open specs for UVD2 for the more recent cards, but they're skittish about revealing too much about the DRM in their cards for fear of having their Windows certification revoked.

            For now, the generic approach is the easiest and most practical, but it isn't low power and may not work as well on older/low end cards.
            Last edited by TechMage89; 01-19-2009, 03:20 PM.

            Comment


            • #7
              @TechMage: Modern Graphics-Cards are several times faster than the NV40s this is currently beeing developed on. So if those cards are capable of playing back 1080p, modern cards could probably do so even when running at the lowest power-level (powerplay for ATi, don't know what it's called for nVidia), in contrast to a CPU which would most likely need to run at it's highest powerlevel. So I'd say you'll still end up saving power.

              Comment


              • #8
                Originally posted by Zhick View Post
                @TechMage: Modern Graphics-Cards are several times faster than the NV40s this is currently beeing developed on. So if those cards are capable of playing back 1080p, modern cards could probably do so even when running at the lowest power-level (powerplay for ATi, don't know what it's called for nVidia), in contrast to a CPU which would most likely need to run at it's highest powerlevel. So I'd say you'll still end up saving power.

                The problem being that with most (all?) open drivers dynamic clocking is currently a no-go. Not to mention the other stuff the card is doing at the same time i.e. compositing drawing widgets (exa). KDE4 (Qt4) + firefox gets all laggy when my clocks drop on my 8600m.

                Then there is the fact that for h.264 (which is what most people care about accelerating) puts a significant load on decoding with the cpu meaning not much power is saved. What it does do is help ensure that the video won't stall on higher bit rates. You could consider it more like gpu assisted decoding.

                Comment


                • #9
                  Can anyone tell me, if this are the keys technologies?

                  Code:
                             | GEM | KMS | DRI2 | Gallium3D
                  -----------+-----+-----+------+-----------
                  Radeon     |     |  x  |      |
                  -----------+-----+-----+------+-----------
                  RadeonHD   |     |  x  |      |
                  -----------+-----+-----+------+-----------
                  OpenChrome |     |     |      |
                  -----------+-----+-----+------+-----------
                  Nouveau    |     |     |      |     x
                  -----------+-----+-----+------+-----------
                  Intel      |  x  |  x  |   x  |
                  -----------+-----+-----+------+-----------
                  Last edited by Louise; 01-19-2009, 08:02 PM.

                  Comment


                  • #10
                    Intel does DRI2. KMS too, but it's still in heavy development, so you need stuff from git. Don't know about Gallium.

                    Comment


                    • #11
                      Originally posted by whizse View Post
                      Intel does DRI2. KMS too, but it's still in heavy development, so you need stuff from git. Don't know about Gallium.
                      Thanks

                      But isn't GEM suppose to replace DRI2 for all drivers?

                      Comment


                      • #12
                        No, I don't think that's the right way to think about it, there's a good explanation by bridgman in this thread.

                        Anyway, according to this blog entry, it seems Intel is doing quite well when it comes to Gallium3D too:

                        Early 2008 the state was that the first real world driver, an older Intel one, was working quite well. It might take a while until Gallium3D really enters the stage.

                        Comment


                        • #13
                          GEM is a requirement for both KMS and Gallium.

                          Intel has all three, although their Gallium driver is still experimental.

                          ATI has working GEM and KMS in experimental branches (neither is a function of the Xorg driver, so radeon vs radeonhd doesn't matter.) Experimental DRI2 Also exists in radeon branches, I believe. Work has started on Gallium, but it doesn't yet produce any useful result.

                          Nouveau has experimental GEM, KMS, and Gallium, although all of it is still very incomplete and not really ready for end-users yet.

                          Comment


                          • #14
                            Originally posted by whizse View Post
                            No, I don't think that's the right way to think about it, there's a good explanation by bridgman in this thread.

                            Anyway, according to this blog entry, it seems Intel is doing quite well when it comes to Gallium3D too:
                            okay, I gor it all mixed up a bit =)

                            So Gallium3D should replace Mesa?

                            GEM replace TTM (for gfx cards without dedicated gfx ram) ?

                            And there is no replacement for DRI2?

                            Comment


                            • #15
                              It should be more like
                              Code:
                                                | KMS       | Memory Manager | DRI2   | Gallium3D |
                              +-----------------+-----------+----------------+--------+-----------+
                              | RadeonHD/Radeon | DEV       | GEM/TTM        | DEV    | DEV       |
                              +-----------------+-----------+----------------+--------+-----------+
                              | Openchrome      | NO        | TTM            | NO     | NO        |
                              +-----------------+-----------+----------------+--------+-----------+
                              | Nouveau         | DEV(NV50) | GEM/TTM        | NO     | DEV       |
                              +-----------------+-----------+----------------+--------+-----------+
                              | Intel           | MERGED    | GEM            | MERGED | DEV       |
                              +-----------------+-----------+----------------+--------+-----------+
                              Radeon/RadeonHD are just separate DDX drivers they share dri/drm code

                              Also GEM or TTM is a requirement for KMS/DRI2/G3D, however TTM isn't in the kernel so GEM is required to have it merged

                              Comment

                              Working...
                              X