Announcement

Collapse
No announcement yet.

The Linux 3.13 Kernel Is Already Super Exciting

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

  • #16
    Originally posted by djdoo View Post
    echo output nothing, /etc/profile nothing
    output of:

    Code:
    sudo updatedb
    locate libvdpau_
    ?

    Comment


    • #17
      You do realise that the Nvdia docs you and the Gentoo wiki are refering to are from 2010? So there you have your answer. Now can stop your witchhunt

      Comment


      • #18
        Originally posted by AnonymousCoward View Post
        You do realise that the Nvdia docs you and the Gentoo wiki are refering to are from 2010? So there you have your answer. Now can stop your witchhunt
        The Radeon section of the Gentoo wiki would've been updated when 3.11 came out a couple months ago.

        Arch also updated THEIR wiki and also mention setting the VDPAU_DRIVER environment variable for r600: https://wiki.archlinux.org/index.php...o_acceleration

        Also, here, Nvidia Docs from earlier this year: ftp://download.nvidia.com/XFree86/Li...DME/README.txt

        Control-F: "VDPAU_DRIVER"

        The VDPAU wrapper library is responsible for determining which vendor-specific
        driver to load for a given X11 display/screen. At present, it hard-codes
        "nvidia" as the driver. The environment variable VDPAU_DRIVER may be set to
        override this default. The actual library loaded will be
        libvdpau_${VDPAU_DRIVER}.so. Setting VDPAU_DRIVER to "trace" is not advised.
        Same message they included in the version from before.

        Comment


        • #19
          Only thing I can find that MAYBE would handle 'automatically' moving to a non-Nvidia VDPAU driver is: http://cgit.freedesktop.org/~aplattn...b09e6b3dcd981d

          But thats in his personal git tree, and im not sure it ever got merged mainline. Also, if it was supported by the other drivers and setting VDPAU_DRIVER was a non-issue, why wouldn't the documentation say so?

          Comment


          • #20
            Originally posted by Ericg View Post
            Only thing I can find that MAYBE would handle 'automatically' moving to a non-Nvidia VDPAU driver is: http://cgit.freedesktop.org/~aplattn...b09e6b3dcd981d

            But thats in his personal git tree, and im not sure it ever got merged mainline.
            It is in the mainline tree. And both ati and nouveau drivers correctly report their "second DRI2 name", which is used by libvdpau for selecting hardware-specific driver. Intel's X driver reports only one name, thus libvdpau falls back to default value (nvidia) if VDPAU_DRIVER is not set.

            There is a patch (http://lists.freedesktop.org/archive...st/031872.html) that can help avoid of VDPAU_DRIVER. But as you can see, no one was interested in merging it.

            Comment


            • #21
              That is the mainline libvdpau git repo... That it's under his name doesn't mean it's not official.

              Comment


              • #22
                Originally posted by Ericg View Post
                Also, if it was supported by the other drivers and setting VDPAU_DRIVER was a non-issue, why wouldn't the documentation say so?
                Documentation (you can get a copy with 'make doc' from libvdpau source) says: "The wrapper will implement this function by dynamically loading the appropriate back-end driver file mentioned above. Long-term, the wrapper will use a VDPAU-specific X extension to determine which back-end driver to load. Currently, the wrapper library hard-codes the driver name as "nvidia", although this can be overridden using the environment variable VDPAU_DRIVER."

                It's a bit outdated, since libvdpau already uses second DRI driver name to determine which driver to load. Both ati/radeon and nouveau drivers are built on top of Gallium3D which reports two (identical) names. But intel driver reports only one. That's why you don't need VDPAU_DRIVER for radeon or nouveau, but do need for intel. I've posted a patch that solves the issue, but it was never merged.

                Comment


                • #23
                  Originally posted by i-rinat View Post
                  Documentation (you can get a copy with 'make doc' from libvdpau source) says: "The wrapper will implement this function by dynamically loading the appropriate back-end driver file mentioned above. Long-term, the wrapper will use a VDPAU-specific X extension to determine which back-end driver to load. Currently, the wrapper library hard-codes the driver name as "nvidia", although this can be overridden using the environment variable VDPAU_DRIVER."

                  It's a bit outdated, since libvdpau already uses second DRI driver name to determine which driver to load. Both ati/radeon and nouveau drivers are built on top of Gallium3D which reports two (identical) names. But intel driver reports only one. That's why you don't need VDPAU_DRIVER for radeon or nouveau, but do need for intel. I've posted a patch that solves the issue, but it was never merged.
                  Hey its the first answer so far that makes sense. Thank you i-rinat, at least it explains why my systems (Intel based) act so oddly compared to other systems when it comes to vdpau. Its too bad that Intel is still sticking to to VA-API rather than joining everyone on VDPAU. But again, thank you i-rinat for making heads or tails of this

                  Comment


                  • #24
                    Originally posted by Ericg View Post
                    output of:

                    Code:
                    sudo updatedb
                    locate libvdpau_
                    ?
                    Output of locate libvdpau_
                    Code:
                    linux-13kf:/home/djdoo # locate libvdpau_
                    /usr/lib64/vdpau/libvdpau_r300.so
                    /usr/lib64/vdpau/libvdpau_r300.so.1
                    /usr/lib64/vdpau/libvdpau_r300.so.1.0.0
                    /usr/lib64/vdpau/libvdpau_r600.so
                    /usr/lib64/vdpau/libvdpau_r600.so.1
                    /usr/lib64/vdpau/libvdpau_r600.so.1.0.0
                    /usr/lib64/vdpau/libvdpau_radeonsi.so
                    /usr/lib64/vdpau/libvdpau_radeonsi.so.1
                    /usr/lib64/vdpau/libvdpau_radeonsi.so.1.0.0
                    /usr/lib64/vdpau/libvdpau_trace.so.1
                    /usr/lib64/vdpau/libvdpau_trace.so.1.0.0
                    /usr/lib64/vlc/plugins/codec/libvdpau_plugin.so
                    /usr/share/doc/packages/libvdpau_trace1
                    /usr/share/doc/packages/libvdpau_trace1/README

                    Comment


                    • #25
                      libvdpau queries the driver name via dri2 just like mesa:
                      http://cgit.freedesktop.org/~aplattn...b09e6b3dcd981d

                      Comment


                      • #26
                        Originally posted by agd5f View Post
                        libvdpau queries the driver name via dri2 just like mesa:
                        http://cgit.freedesktop.org/~aplattn...b09e6b3dcd981d
                        Yeah I saw that commit, its a shame that nothing can be done about Intel since they want to stick with VA-API *facepalm* Least it explains why my situation is so different from yours.

                        Doesn't explain why the Gentoo and Arch wikis still say you have to set VDPAU_DRIVER but oh well, not my problem anymore lol.

                        Comment


                        • #27
                          Originally posted by Ericg View Post
                          Yeah I saw that commit, its a shame that nothing can be done about Intel since they want to stick with VA-API *facepalm* Least it explains why my situation is so different from yours.

                          Doesn't explain why the Gentoo and Arch wikis still say you have to set VDPAU_DRIVER but oh well, not my problem anymore lol.
                          It's hard to much much faith in wiki's. Considering the pace of innovation around here, it take a really dedicated team to keep updated with detailed and correct information.

                          Comment

                          Working...
                          X