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...

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

  • #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?

        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.

            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...

                  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.

                    Comment


                    • #11
                      Originally posted by Ericg View Post
                      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.
                      My vdpauinfo:
                      Code:
                       djdoo@linux-13kf:~> vdpauinfo
                      display: :0   screen: 0
                      API version: 1
                      Information string: G3DVL VDPAU Driver Shared Library version 1.0
                      
                      Video surface:
                      
                      name   width height types
                      -------------------------------------------
                      420    16384 16384  NV12 YV12 
                      422    16384 16384  UYVY YUYV 
                      444    16384 16384  Y8U8V8A8 V8U8Y8A8 
                      
                      Decoder capabilities:
                      
                      name               level macbs width height
                      -------------------------------------------
                      MPEG1                 0  9216  2048  1152
                      MPEG2_SIMPLE          3  9216  2048  1152
                      MPEG2_MAIN            3  9216  2048  1152
                      H264_BASELINE        41  9216  2048  1152
                      H264_MAIN            41  9216  2048  1152
                      H264_HIGH            41  9216  2048  1152
                      VC1_SIMPLE            1  9216  2048  1152
                      VC1_MAIN              2  9216  2048  1152
                      VC1_ADVANCED          4  9216  2048  1152
                      
                      Output surface:
                      
                      name              width height nat types
                      ----------------------------------------------------
                      B8G8R8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
                      R8G8B8A8         16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
                      R10G10B10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
                      B10G10R10A2      16384 16384    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
                      
                      Bitmap surface:
                      
                      name              width height
                      ------------------------------
                      B8G8R8A8         16384 16384
                      R8G8B8A8         16384 16384
                      R10G10B10A2      16384 16384
                      B10G10R10A2      16384 16384
                      A8               16384 16384
                      
                      Video mixer:
                      
                      feature name                    sup
                      ------------------------------------
                      DEINTERLACE_TEMPORAL             -
                      DEINTERLACE_TEMPORAL_SPATIAL     -
                      INVERSE_TELECINE                 -
                      NOISE_REDUCTION                  y
                      SHARPNESS                        y
                      LUMA_KEY                         -
                      HIGH QUALITY SCALING - L1        -
                      HIGH QUALITY SCALING - L2        -
                      HIGH QUALITY SCALING - L3        -
                      HIGH QUALITY SCALING - L4        -
                      HIGH QUALITY SCALING - L5        -
                      HIGH QUALITY SCALING - L6        -
                      HIGH QUALITY SCALING - L7        -
                      HIGH QUALITY SCALING - L8        -
                      HIGH QUALITY SCALING - L9        -
                      
                      parameter name                  sup      min      max
                      -----------------------------------------------------
                      VIDEO_SURFACE_WIDTH              y        48     2048
                      VIDEO_SURFACE_HEIGHT             y        48     1152
                      CHROMA_TYPE                      y  
                      LAYERS                           y         0        4
                      
                      attribute name                  sup      min      max
                      -----------------------------------------------------
                      BACKGROUND_COLOR                 y  
                      CSC_MATRIX                       y  
                      NOISE_REDUCTION_LEVEL            y      0.00     1.00
                      SHARPNESS_LEVEL                  y     -1.00     1.00
                      LUMA_KEY_MIN_LUMA                y  
                      LUMA_KEY_MAX_LUMA                y
                      opensuse 12.3 kernel 3.12 final Mesa 10 and libvdpau-r600 package installed

                      Comment


                      • #12
                        Originally posted by djdoo View Post
                        opensuse 12.3 kernel 3.12 final Mesa 10 and libvdpau-r600 package installed
                        Whats the output of

                        echo $VDPAU_DRIVER ?

                        or check /etc/profile.d to see if there's anything that automatically sets VDPAU_DRIVER to be r600 once you've installed the "libvdpau-r600" package

                        Comment


                        • #13
                          Just to make it clear, is PowerXPress making it into 3.13?

                          Comment


                          • #14
                            Originally posted by Ericg View Post
                            Whats the output of

                            echo $VDPAU_DRIVER ?

                            or check /etc/profile.d to see if there's anything that automatically sets VDPAU_DRIVER to be r600 once you've installed the "libvdpau-r600" package
                            echo output nothing, /etc/profile nothing

                            Comment


                            • #15
                              Just to make it clear that i'm not on a like witch-hunt, Djdoo & Alex, I'm not saying with some like iron grip of surety that you guys -are wrong.- But SOMETHING is wrong, maybe its you guys, maybe its Fedora / Arch / Gentoo / Nvidia's docs (First two being my distros of choice, and Gentoo being in there because I referenced their wiki), but someone, somewhere, changed something and didn't update the docs, or DIDN'T do something they should have.

                              And I'm now really curious to figure out what exactly DID happen with this, and would LOVE to find out.

                              Comment

                              Working...
                              X