Announcement

Collapse
No announcement yet.

VA-API Gallium3D State Tracker Added Back To Mesa

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

  • VA-API Gallium3D State Tracker Added Back To Mesa

    Phoronix: VA-API Gallium3D State Tracker Added Back To Mesa

    Last week I wrote about AMD working on a new VA-API state tracker for Gallium3D after the original VA-API support was dropped two years ago. That new state tracker has landed in mainline Mesa Git...

    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
    Hope this also fixes the screen flickering bug. And hopefully a horrid bug that the video gets garbled if you play it a second time.

    Comment


    • #3
      vainfo
      libva info: VA-API version 0.35.1
      libva info: va_getDriverName() returns 0
      libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
      libva info: Found init function __vaDriverInit_0_35
      libva info: va_openDriver() returns 0
      vainfo: VA-API version: 0.35 (libva 1.3.1)
      vainfo: Driver version: mesa gallium vaapi
      vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple : VAEntrypointVLD
      VAProfileMPEG2Main : VAEntrypointVLD
      VAProfileMPEG4Simple : VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple : VAEntrypointVLD
      VAProfileVC1Advanced : VAEntrypointVLD
      VAProfileH264Baseline : VAEntrypointVLD
      VAProfileH264Main : VAEntrypointVLD
      VAProfileH264High : VAEntrypointVLD
      For the first somewhat double non efficiant then vdpau, but at least it works Issue with vblank, halfed frame rate with it vblank disabled fine... who knows, might not like composite or opengl vo is unsupported with it [vo/opengl/vaapi] vaCopySurfaceGLX(): operation failed

      But g?t for the first try
      Last edited by dungeon; 01 October 2014, 07:21 PM.

      Comment


      • #4
        I still don't fully understand why they're working on both va-api and vdpau. It seems va-api is overall better (on paper) but I don't have any proof of that. I think it's nice they're working on stuff like this but honestly I'd rather them spend the attention toward either improving vdpau or continue working on the missing hardware and mesa openGL features.

        Comment


        • #5
          Some customers want VDPAU. Other customers want VA-API.

          What the industry obviously needs is a new standard for Linux video encode/decode that works for everyone.

          Test signature

          Comment


          • #6
            Originally posted by schmidtbag View Post
            I still don't fully understand why they're working on both va-api and vdpau. It seems va-api is overall better (on paper) but I don't have any proof of that. I think it's nice they're working on stuff like this but honestly I'd rather them spend the attention toward either improving vdpau or continue working on the missing hardware and mesa openGL features.
            I'm assuming some vendor is looking to provide an amd option as an alternative to their current intel solution, and wants AMD to provide the same API so they don't have to change how their software works.

            I doubt AMD would do this if no one was paying them. As you said, there's a lot of other stuff they could be doing instead.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              I still don't fully understand why they're working on both va-api and vdpau. It seems va-api is overall better (on paper) but I don't have any proof of that. I think it's nice they're working on stuff like this but honestly I'd rather them spend the attention toward either improving vdpau or continue working on the missing hardware and mesa openGL features.
              Well.. they are only just state-trackers on top of gallium video APIs, so at least the driver work is done once. And usable by other drivers.. if you want to expose your hw to as many apps as possible (given lack of standardization on a single video enc/dec API), this is the right way to do it.

              Comment


              • #8
                Originally posted by bridgman View Post
                Some customers want VDPAU. Other customers want VA-API.

                What the industry obviously needs is a new standard for Linux video encode/decode that works for everyone.

                So combine them into one piece of software.

                Comment


                • #9
                  Is this State Tracker now "XBMC" Compatible? I have the UVD1 and UVD2 Blocks in mind

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    Some customers want VDPAU. Other customers want VA-API.

                    What the industry obviously needs is a new standard for Linux video encode/decode that works for everyone.

                    Wasn't omx supposed to do this?

                    Comment

                    Working...
                    X