Announcement

Collapse
No announcement yet.

Intel Does Another Batch Of Linux 3.13 Graphics Changes

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

  • Intel Does Another Batch Of Linux 3.13 Graphics Changes

    Phoronix: Intel Does Another Batch Of Linux 3.13 Graphics Changes

    While the Linux 3.12 kernel hasn't even been released yet, going back to late August Intel has been plotting their graphics improvements for Linux 3.13. In September Intel was already sending in drm-next changes and they have done more rounds since. Another drm-next pull request was issued today for the Intel DRM driver...

    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
    Intel is not currently supporting proprietary OpenCL implementation for Linux in HD graphics. So there is no mature updated OpenCL implementation for Linux.
    Intel does not supporting QuickSync for Linux.
    If you buy an intel for use it on Linux, do not expect those features.
    I'm starting to lose enthusiasm with Intel.
    Last edited by YAFU; 24 October 2013, 11:22 PM.

    Comment


    • #3
      Originally posted by YAFU View Post
      Intel does not supporting QuickSync for Linux.
      There are any plans of support?

      Comment


      • #4
        Intel does not supporting QuickSync for Linux.
        Sure it does, it's called libva. As far as I know decoding is working well, but I don't know about the encoding.

        Comment


        • #5
          Originally posted by curaga View Post
          Sure it does, it's called libva. As far as I know decoding is working well, but I don't know about the encoding.
          Is libva officially maintained by intel?. If I ask in intel official forum on "libva", Would I get sooprte about it?


          So then I asked in the "appropriate channel", and got no answers.

          I do not find libva real examples to use in video encoding (h264). Nor do I find benchmarks or programs that support it for encoding.
          For now it seems to be more myth than real.

          Comment


          • #6
            When I've written "Would I get sooprte about it?", should be: "Would I get support about it?"

            I hate that the time allowed to edit a post is so short.

            *Sorry for my English
            Last edited by YAFU; 25 October 2013, 10:25 AM.

            Comment


            • #7
              Originally posted by YAFU View Post
              Is libva officially maintained by intel?. If I ask in intel official forum on "libva", Would I get sooprte about it?


              So then I asked in the "appropriate channel", and got no answers.

              I do not find libva real examples to use in video encoding (h264). Nor do I find benchmarks or programs that support it for encoding.
              For now it seems to be more myth than real.
              It's absolutely real. I'm running the latest git libva and libva-intel-driver on Gentoo, and it supports both decode and encode. I've only used it with decode so far. I had to patch mplayer with vaapi support (while at it I also reworked the realtime support) I'll upload the ebuild to my git overlay.

              Intel vainfo on IvyBridge:

              libva info: VA-API version 0.34.0
              libva info: va_getDriverName() returns 0
              libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
              libva info: Found init function __vaDriverInit_0_34
              libva info: va_openDriver() returns 0
              vainfo: VA-API version: 0.34 (libva 1.2.2.pre1)
              vainfo: Driver version: Intel i965 driver - 1.2.0
              vainfo: Supported profile and entrypoints
              VAProfileNone : VAEntrypointVideoProc
              VAProfileMPEG2Simple : VAEntrypointVLD
              VAProfileMPEG2Simple : VAEntrypointEncSlice
              VAProfileMPEG2Main : VAEntrypointVLD
              VAProfileMPEG2Main : VAEntrypointEncSlice
              VAProfileH264Baseline : VAEntrypointVLD
              VAProfileH264Baseline : VAEntrypointEncSlice
              VAProfileH264Main : VAEntrypointVLD
              VAProfileH264Main : VAEntrypointEncSlice
              VAProfileH264High : VAEntrypointVLD
              VAProfileH264High : VAEntrypointEncSlice
              VAProfileVC1Simple : VAEntrypointVLD
              VAProfileVC1Main : VAEntrypointVLD
              VAProfileVC1Advanced : VAEntrypointVLD
              VAProfileJPEGBaseline : VAEntrypointVLD


              On a somewhat related note, I've also been merging the linuxtv crystalhd driver with the in-kernel (staging) version, and ported the crystalhd vaapi driver to the latest libva code:

              libva info: VA-API version 0.34.0
              libva info: va_getDriverName() returns 0
              libva info: User requested driver 'crystalhd'
              libva info: Trying to open /usr/lib64/va/drivers/crystalhd_drv_video.so
              libva info: Found init function __vaDriverInit_0_34
              Running DIL (3.22.0) Version
              DtsDeviceOpen: Opening HW in mode 0
              libva info: va_openDriver() returns 0
              vainfo: VA-API version: 0.34 (libva 1.2.2.pre1)
              vainfo: Driver version: Broadcom Crystal HD Video Decoder 3.10.0.0
              vainfo: Supported profile and entrypoints
              VAProfileMPEG2Simple : VAEntrypointVLD
              VAProfileMPEG2Simple : VAEntrypointMoComp
              VAProfileMPEG2Main : VAEntrypointVLD
              VAProfileMPEG2Main : VAEntrypointMoComp
              VAProfileH264Baseline : VAEntrypointVLD
              VAProfileH264Main : VAEntrypointVLD
              VAProfileH264High : VAEntrypointVLD
              DtsAllocIoctlData Error

              Still a bug to track down here though. I'll post my kernel patch to lkml shortly anyway.

              As for app support, I'm not aware of anything yet making use of the libva encoding acceleration, I might take a look at hacking ffmpeg though, if there isn't anything there yet.

              Comment


              • #8
                Originally posted by s_j_newbury View Post
                It's absolutely real. I'm running the latest git libva and libva-intel-driver on Gentoo, and it supports both decode and encode. I've only used it with decode so far.
                I do not understand, you've been able or not able to encode in h264?
                For me until someone achieves h264 encoding without bugs, and with similar QuickSync performance, the Intel support for this is still a rumor, a myth. Something out there on the internet it is said that this is possible, but nobody has been able to do yet.
                And if this is possible, Intel should provide support to applications like ffmpeg so they can implement it.
                I clarify that my claim is about encoding.
                Last edited by YAFU; 26 October 2013, 03:50 PM.

                Comment


                • #9
                  Originally posted by YAFU View Post
                  I do not understand, you've been able or not able to encode in h264?
                  For me until someone achieves h264 encoding without bugs, and with similar QuickSync performance, the Intel support for this is still a rumor, a myth. Something out there on the internet it is said that this is possible, but nobody has been able to do yet.
                  And if this is possible, Intel should provide support to applications like ffmpeg so they can implement it.
                  I clarify that my claim is about encoding.
                  The "VAEntrypointEncSlice" entries are the clue it's available. It can be used right now to encode to h264 or avc from a raw YUV bitstream using "h264encode" or "avcencode" both of which get built along with libva. What I haven't done is try it.

                  Comment

                  Working...
                  X