Announcement

Collapse
No announcement yet.

The Linux 3.13 Kernel Is Already Super Exciting

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

  • The Linux 3.13 Kernel Is Already Super Exciting

    Phoronix: The Linux 3.13 Kernel Is Already Super Exciting

    The merge window hasn't even officially opened yet on the Linux 3.13 kernel but it's already super exciting and I can't wait for the new code to start hitting mainline and to benchmark these massive changes to the Linux kernel. Here's just a few things to expect so far but it's already gearing up to be a super exciting release and perhaps the best of 2013...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I wonder what exactly what does ?radeon HDMI audio? means. Does it support compressed audio and multichannel uncompressed audio or is it only stereo PCM audio?

    Comment


    • #3
      Originally posted by Figueiredo View Post
      I wonder what exactly what does ?radeon HDMI audio? means. Does it support compressed audio and multichannel uncompressed audio or is it only stereo PCM audio?
      There are two parts to hdmi audio, the GPU side and the alsa side. Both parts should support everything requires for multi-channel and hbr audio in 3.13.

      Comment


      • #4
        Originally posted by agd5f View Post
        There are two parts to hdmi audio, the GPU side and the alsa side. Both parts should support everything requires for multi-channel and hbr audio in 3.13.
        Hey Alex, quick question for ya. User mentioned that UVD support was kinda in disarray, with it crashing the driver, or X, or rendering incorrectly, etc. I don't have a laptop I use frequently enough to test it myself, so I just gotta ask: Is UVD (stability and 'correctness' wise) still a work in progress or should it be pretty rock solid?
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #5
          Originally posted by Ericg View Post
          Hey Alex, quick question for ya. User mentioned that UVD support was kinda in disarray, with it crashing the driver, or X, or rendering incorrectly, etc. I don't have a laptop I use frequently enough to test it myself, so I just gotta ask: Is UVD (stability and 'correctness' wise) still a work in progress or should it be pretty rock solid?
          There are always corner cases, it's been stable for me a most other users I've talked to for a while now.

          Comment


          • #6
            Originally posted by agd5f View Post
            There are always corner cases, it's been stable for me a most other users I've talked to for a while now.
            Of course there's corner cases, there always will be lol. I was just curious about 'in general', which you answered, so thanks

            Oh, any luck on pressuring Nvidia to release a VDPAU update that doesn't hardcode the default library to the be libvdpau_$NVIDIA.so ? Read somewhere that they were working on it, and given that Radeon now uses VDPAU, Nvidia uses VDPUA, Nouveau uses VDPAU, and Intel can use VDPAU via libvdpau-va-gl, one would think it would be a little higher on the priority list...

            To me, and maybe I'm the odd-man-out here, its a non-obvious barrier to entry that users have to set the VDPAU_DRIVER= environment variable in order to get hardware acceleration to work if they are using anything except the closed source Nvidia driver.
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #7
              Originally posted by Ericg View Post
              Of course there's corner cases, there always will be lol. I was just curious about 'in general', which you answered, so thanks

              Oh, any luck on pressuring Nvidia to release a VDPAU update that doesn't hardcode the default library to the be libvdpau_$NVIDIA.so ? Read somewhere that they were working on it, and given that Radeon now uses VDPAU, Nvidia uses VDPUA, Nouveau uses VDPAU, and Intel can use VDPAU via libvdpau-va-gl, one would think it would be a little higher on the priority list...

              To me, and maybe I'm the odd-man-out here, its a non-obvious barrier to entry that users have to set the VDPAU_DRIVER= environment variable in order to get hardware acceleration to work if they are using anything except the closed source Nvidia driver.
              Something must be wrong in your setup. Multiple vdpau libs have worked fine for ages. I've never had to force the VDPAU_DRIVER env var.

              Comment


              • #8
                Actual PowerXpress power management for discrete laptop Radeon cards is probably the thing I'm most excited about. I can clock *down* my 7970M (while only using the Intel IGP) but I can't actually turn it off (when I try to use vgaswitcheroo it causes my machine to lock up).

                Comment


                • #9
                  Originally posted by agd5f View Post
                  Something must be wrong in your setup. Multiple vdpau libs have worked fine for ages. I've never had to force the VDPAU_DRIVER env var.
                  Not sure, running F19 now and I used to be running Arch.

                  Originally posted by http://wiki.gentoo.org/wiki/VDPAU#Radeon_specific_install_steps;
                  By default applications such as mplayer,vlc,vdpauinfo,... make VDPAU specific calls via libvdpau library. This library then dynamically loads appropriate back-end driver ( VDPAU driver specific to your hardware read more...). At the time of writing the mechanism to automatically decide which back-end driver needs to be loaded was not established. Currently libvdpau is hardcoded to load nvidia backend driver. It means that VDPAU will not work properly on Radeon cards. The only possible way to change that behavior is by specifying the correct back-end driver manually.
                  Originally posted by https://wiki.archlinux.org/index.php/VDPAU#Configuration;
                  The libvdpau-va-gl driver (for Intel Graphics or AMD Catalyst) needs to be enabled manually. To enable it, create the following file:
                  Code:
                  /etc/profile.d/vdpau_vaapi.sh
                  
                  #!/bin/sh
                  export VDPAU_DRIVER=va_gl
                  And Nvidia's own documentation...

                  Originally posted by ftp://download.nvidia.com/XFree86/Linux-x86/256.35/README/vdpausupport.html;
                  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.
                  You can test to see if its PROPERLY loading vdpau by running 'vdpauinfo' for example on mine...

                  Code:
                  [egriffith@eric-laptop ~]$ echo $VDPAU_DRIVER
                  
                  [egriffith@eric-laptop ~]$ 
                  [egriffith@eric-laptop ~]$ vdpauinfo
                  display: :0   screen: 0
                  Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
                  Error creating VDPAU device: 1
                  [egriffith@eric-laptop ~]$
                  But if I install libvdpau-va-gl which is the Intel VA-API ---> VDPAU bindings then it reports all the usual info.

                  Might want to check your machines, Alex...
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #10
                    This post is gonna come off kinda arrogant, and I really don't mean it to, Alex. All the respect meant.

                    To me one of the three things is here...

                    Either:

                    1) You're mistaken about not having set the variable forever ago and you actually did.
                    2) You really didn't set the variable... in which case I'm now questioning whether radeon VDPAU+UVD actually DOES work like you think it does, and as well as you think it does...
                    or
                    3) Nvidia silently updated VDPAU a long time ago, no one ever saw it, no one at Nvidia ever said anything, and the documentation never got updated.

                    I don't know, I'm neither a kernel or a VDPAU dev, I just know what I'm reading from fairly reputable sources.
                    All opinions are my own not those of my employer if you know who they are.

                    Comment

                    Working...
                    X