Announcement

Collapse
No announcement yet.

AMD Packs In More AMDGPU Features For Linux 4.15

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

  • AMD Packs In More AMDGPU Features For Linux 4.15

    Phoronix: AMD Packs In More AMDGPU Features For Linux 4.15

    The Linux 4.15 kernel is looking to be a very exciting update for AMDGPU DRM driver users...

    http://www.phoronix.com/scan.php?pag...-4.15-Features

  • #2
    vp9 please

    Comment


    • #3
      VP9 should be in UVD 6.3 hardware as of RX 4xx series and above. Isn't it yet supported? I had the first run of my RX 560 yesterday and no time to check anything but the basics yet.


      > - UVD video encode ring support on polaris

      Encode? I thought that was VCE's task? Could anyone explain that to a noob like me?
      Stop TCPA, stupid software patents and corrupt politicians!

      Comment


      • #4
        Originally posted by Adarion View Post
        Encode? I thought that was VCE's task? Could anyone explain that to a noob like me?
        H.265 encode is implemented as part of the UVD engine rather than VCE. The two engines are very similar. On Raven, the two separate engines (UVD and VCE) are replaced by a single engine (VCN).

        Comment


        • #5
          Originally posted by Adarion View Post
          VP9 should be in UVD 6.3 hardware as of RX 4xx series and above.
          I know it says so on Wikipedia ( https://en.wikipedia.org/wiki/Unifie..._Decoder#UVD_6 ) but I'm pretty certain it's wrong. It doesn't have VP9 hardware decoding. They cheated a bit and implemented a GPGPU/CPU based hybrid decoding for it, but that's on Windows only, and I wouldn't really call it proper hardware decoding.

          Comment


          • #6
            Hardly anyone has hardware decode for VP9 in a dedicated DSP. I'm more than happy they do it via OpenCL. VP9 outside of YouTube has virtually zero presence and won't have any in the future. Content producers in Hollywood have very little interest in VP9.

            Successor: from VP10 to AV1

            "VP10" redirects here. For other uses, see VP10 (disambiguation).


            On September 12, 2014, Google announced that development on VP10 had begun and that after the release of VP10 they plan to have an 18-month gap between releases of video formats.[91] In August 2015, Google began to publish code for VP10.[92]

            However, Google decided to incorporate VP10 into AOMedia Video 1 (AV1). The AV1 codec will use elements of VP10 as well as the experimental formats Daala (Xiph/Mozilla) and Thor (Cisco).[93][94][95] Accordingly, Google has stated that they will not deploy VP10 internally or officially release it, making VP9 the last of the VPx-based codecs to be released by Google.
            Thor is a royalty free video codec under development by Cisco Systems. The specifications of Thor were available in various Internet-Drafts.[1]

            On July 22, 2015, Thor was presented to the IETF as a candidate for their NETVC video standard.[2]Thor uses some Cisco elements that are also used by HEVC.[3] As part of the NETVC work, the Constrained Low-Pass Filter (CLPF) and motion compensation techniques used in Thor were tested in conjunction with the lapped transform coding techniques from the Daala codec.[4]

            On September 1, 2015, Cisco announced that the Alliance for Open Media would use elements of Thor to develop a royalty free video format, AOMedia Video 1.[5][6][7]
            We know hardware decode for HEVC is universal with Nvidia and AMD, to iOS A9 or newer for a few GPGPU generations and have x265 on Linux; and both Windows and OS X have hardware support. Only the latest Intel iGPUs Skylake or newer 6700/7700/8700 have support in hardware, but who would care knowing Google dropped VPx support for the future. Clearly, x265 was the right path to take.

            Thor doesn't stand a chance replacing HEVC. Get used to working with HEVC and in the near future HEIF if you work with Adobe, Pixelmator Pro, Affinity tools, etc. It doesn't mean you export specifically for HEIF as your final output, but if its 4K output drastically reduces file size w/o introducing noticeable artifacts then you can expect it to be extended in more browsers for large src support.

            https://en.wikipedia.org/wiki/High_E...ge_File_Format

            Digital cameras and smartphones

            To save storage space, HEIF-encapsulated HEVC-coded images can be used for compressing the full-resolution images while keeping a lower-resolution JPEG copy (e.g. at 4K resolution or below) for on-screen displaying purposes.

            Digital cameras and smartphones can use HEIF to achieve single-file packaging of burst photos, focal stacks, and exposure stacks. Similarly, simultaneously captured video and still images can be stored in the same HEIF file. HEIF also enables storage of any image collections into a single file, which can be shared easily. Web pages and Internet-connected image applications

            The picture element of HTML5.2 provides the capability of indicating multiple alternatives for the same image, out of which the web browser can select the one that best suits its purpose. A motivation for web pages and connected applications to start using HEIF is to reduce the web page and image content download times. Image editing

            Changing of the orientation and cropping are basic features of HEIF and require no re-encoding of the images. Additionally, HEIF introduces a framework for non-destructive editing operations, which can be specified by external specifications. This feature can be used by image editing applications so that the editing instructions are kept in the same file as the original image. Features

            HEIF files can store the following types of data:[7]
            • Image Items: storage of individual images, image properties and thumbnail(s).
            • Image Derivations: derived images are generated during run-time based on descriptions such as rotation, grid and overlay. These images depend on other images stored in the HEIF file. The storage overhead of derived images is small.
            • Image Sequences: storage of multiple time-related and/or temporally predicted images (like a burst-photo shot or cinemagraph animation), their properties and thumbnails. Different prediction options can be used in order to exploit the temporal and spatial similarities between the images. Hence, file sizes can be drastically reduced even when tens of images are stored in the same HEIF file.
            • Auxiliary Image Items: storage of image data which complements another image item. An alpha plane or a depth map are examples for such images. These data are not displayed as such, but used in various forms to complement another image item.
            • Image Metadata: storage of EXIF, XMP and similar metadata which accompany the images stored in the HEIF file.

            HEVC Image File Format

            • HEVC image players are required to support rectangular cropping and rotation by 90, 180, and 270 degrees. The primary use case for the mandatory support for rotation by 90 degrees is for the photo shooting situations in which the camera orientation is incorrectly detected or concluded. This requirement makes it possible to manually adjust the image or image sequence orientation afterwards without the need for re-encoding the image or image sequence. Similarly, cropping may be useful to enable post-shooting zoom without the need for re-encoding. As rotation by 90, 180, or 270 degrees as well as cropping are mandatory for all HEVC image file players, it is guaranteed that re-encoding is not required to carry out these operations.
            • Samples in image sequence tracks must be either intra-coded images or inter-picture predicted images with reference to only intra-coded images. These constraints of inter-picture prediction reduce the decoding latency for accessing any particular image within an HEVC image sequence track.

            Comment


            • #7
              Originally posted by Brisse View Post

              I know it says so on Wikipedia ( https://en.wikipedia.org/wiki/Unifie..._Decoder#UVD_6 ) but I'm pretty certain it's wrong. It doesn't have VP9 hardware decoding. They cheated a bit and implemented a GPGPU/CPU based hybrid decoding for it, but that's on Windows only, and I wouldn't really call it proper hardware decoding.
              Why is it on Windows only? It should be OS agnostic. What prevents it from being used on Linux?

              Comment


              • #8
                Originally posted by Marc Driftmeyer View Post
                Thor doesn't stand a chance replacing HEVC. Get used to working with HEVC
                I'd say forget about HEVC. It's DOA becauase of its costs. AV1 on the other hand is going to be supported in the hardware, but for that it has to be released first. A clear indication of how dead HEVC is, is the fact that MS backed AV1 despite having bottomless pockets.
                Last edited by shmerl; 10-09-2017, 02:31 PM.

                Comment


                • #9
                  Originally posted by shmerl View Post

                  Why is it on Windows only? It should be OS agnostic. What prevents it from being used on Linux?
                  It's software, which means it has to be ported to the linux driver, go through the open source legal dance, then they have to hook it up to the correct api (vaapi, openmax, vdpau, etc.). That's a lot more work than just 1 API on windows, and they don't have much manpower working on video decode for linux yet, so they're still in the making stuff work stage.

                  Comment


                  • #10
                    Originally posted by shmerl View Post
                    Why is it on Windows only? It should be OS agnostic. What prevents it from being used on Linux?
                    How can a HW <-> OS driver be OS-agnostic ?

                    Comment

                    Working...
                    X