Announcement

Collapse
No announcement yet.

AOM AV1 Encoder Sees Big Boost With Additional AVX2 Optimization

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

  • AOM AV1 Encoder Sees Big Boost With Additional AVX2 Optimization

    Phoronix: AOM AV1 Encoder Sees Big Boost With Additional AVX2 Optimization

    It should come as little surprise in general but making use of Advanced Vector Extensions (AVX) for multimedia encode/decode is a big deal for performance. While one could hope that by 2020 most open-source encoders were already extensively utilizing AVX(2), that isn't yet the case with the latest being AOM-AV1 picking up another optimization...

    http://www.phoronix.com/scan.php?pag...1-Another-AVX2

  • #2
    Originally posted by phoronix View Post
    Phoronix: AOM AV1 Encoder Sees Big Boost With Additional AVX2 Optimization

    While one could hope that by 2020 most open-source encoders were already extensively utilizing AVX(2), that isn't yet the case with the latest being AOM-AV1 picking up another optimization...

    http://www.phoronix.com/scan.php?pag...1-Another-AVX2
    Maybe because video/audio codecs are much heavier on computation than general software.

    While in general software developers write custom assembly just for the hottest functions, video codecs perform have a big part of code in functions that could be considered **hot**.

    Comment


    • #3
      Worth noting that I'd imagine the primary goal of AOM-AV1, being the reference encoder, would be correctness, with performance as more of a second tier. With that in mind, the slow speed and lack of large scale effort dedicated to stuff like AVX2 makes sense, while other implementations such as Intel's can prioritize performance and still use AOM-AV1 as a point of reference.

      Comment


      • #4
        That optimized code is yielding an 8.96x gain compared to the conventional C code without the AVX2 optimization.
        so before this, they weren't even using SSE? and Intel's Celeron and Pentium processors are still stuck with slow C code?

        Comment


        • #5
          Originally posted by re:fi.64 View Post
          Worth noting that I'd imagine the primary goal of AOM-AV1, being the reference encoder, would be correctness, with performance as more of a second tier. With that in mind, the slow speed and lack of large scale effort dedicated to stuff like AVX2 makes sense, while other implementations such as Intel's can prioritize performance and still use AOM-AV1 as a point of reference.
          I don't know if one can consider AOM-AV1 just a "reference encoder":
          • It started from the sources of what would be VP10, the VP9 successor, if Google didn't formed AOM with their allies.
          • The base source code was pretty mature and stable at time of development.
          • The AV1 spec was built from the source code. For a reference implementation one can expect the opposite to happen.
          • It got optimizations and usability development even before the codec was released as 1.0.
          • People still continue to improve the codec and the source code development didn't stop even that it already can be considered good enough for a reference implementation and also there are some others concurrent implementations.

          Comment


          • #6
            Why does this need to be manual and not let to the compiler?

            Comment


            • #7
              I don't understand why Michael always writes these condescending and offending pieces of shittalk whenever some software project isn't up to his imaginary standard.

              "Oh it's just sad that this library has so bad performance, it's already 2020 after all!"

              Just have a look at what piece of shit this forum is, unacceptable for even year 2010, and let's talk again.

              Comment


              • #8
                Originally posted by re:fi.64 View Post
                Worth noting that I'd imagine the primary goal of AOM-AV1, being the reference encoder, would be correctness, with performance as more of a second tier. With that in mind, the slow speed and lack of large scale effort dedicated to stuff like AVX2 makes sense, while other implementations such as Intel's can prioritize performance and still use AOM-AV1 as a point of reference.
                The problem is, unlike decoder, you cannot really have a "reference encoder".

                A reference decoder is well defined, all decoder must match the output of this reference.
                However, for encoder, things are getting tricky. Even for a relatively simple encoding algorithm we can still discover more efficient but still compliant encoders.

                Consider the open nature of AV1, I think a better role for this reference encoder is like x264, i.e., the first choice for almost everyone.

                Comment

                Working...
                X