An error occurred fetching the project authors.
  1. 09 Jul, 2022 3 commits
  2. 28 Jun, 2022 1 commit
  3. 21 Apr, 2022 1 commit
  4. 12 Apr, 2022 2 commits
  5. 24 Feb, 2022 1 commit
  6. 16 Dec, 2021 1 commit
  7. 24 Nov, 2021 1 commit
  8. 23 Nov, 2021 1 commit
  9. 28 Oct, 2021 1 commit
  10. 16 Aug, 2021 1 commit
  11. 23 Jul, 2021 1 commit
  12. 27 May, 2021 1 commit
  13. 22 Jan, 2021 1 commit
  14. 12 Jan, 2021 1 commit
  15. 16 Nov, 2020 1 commit
  16. 13 Nov, 2020 2 commits
  17. 30 Oct, 2020 1 commit
    • Bas Nieuwenhuizen's avatar
      drm/fourcc: Add AMD DRM modifiers. · 8ba16d59
      Bas Nieuwenhuizen authored
      This adds modifiers for GFX9+ AMD GPUs.
      
      As the modifiers need a lot of parameters I split things out in
      getters and setters.
        - Advantage: simplifies the code a lot
        - Disadvantage: Makes it harder to check that you're setting all
                        the required fields.
      
      The tiling modes seem to change every generation, but the structure
      of what each tiling mode is good for stays really similar. As such
      the core of the modifier is
       - the tiling mode
       - a version. Not explicitly a GPU generation, but splitting out
         a new set of tiling equations.
      
      Sometimes one or two tiling modes stay the same and for those we
      specify a canonical version.
      
      Then we have a bunch of parameters on how the compression works.
      Different HW units have different requirements for these and we
      actually have some conflicts here.
      
      e.g. the render backends need a specific alignment but the display
      unit only works with unaligned compression surfaces. To work around
      that we have a DCC_RETILE option where both an aligned and unaligned
      compression surface are allocated and a writer has to sync the
      aligned surface to the unaligned surface on handoff.
      
      Finally there are some GPU parameters that participate in the tiling
      equations. These are constant for each GPU on the rendering/texturing
      side. The display unit is very flexible however and supports all
      of them :|
      
      Some estimates:
       - Single GPU, render+texture: ~10 modifiers
       - All possible configs in a gen, display: ~1000 modifiers
       - Configs of actually existing GPUs in a gen: ~100 modifiers
      
      For formats with a single plane everything gets put in a separate
      DRM plane. However, this doesn't fit for some YUV formats, so if
      the format has >1 plane, we let the driver pack the surfaces into
      1 DRM plane per format plane.
      
      This way we avoid X11 rendering onto the frontbuffer with DCC, but
      still fit into 4 DRM planes.
      Signed-off-by: default avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      8ba16d59
  18. 26 Oct, 2020 1 commit
  19. 20 Oct, 2020 1 commit
  20. 09 Oct, 2020 1 commit
  21. 27 Jul, 2020 1 commit
  22. 06 Jul, 2020 1 commit
  23. 03 Jul, 2020 1 commit
    • Neil Armstrong's avatar
      drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression · d6528ec8
      Neil Armstrong authored
      Amlogic uses a proprietary lossless image compression protocol and format
      for their hardware video codec accelerators, either video decoders or
      video input encoders.
      
      It considerably reduces memory bandwidth while writing and reading
      frames in memory.
      
      The underlying storage is considered to be 3 components, 8bit or 10-bit
      per component, YCbCr 420, single plane :
      - DRM_FORMAT_YUV420_8BIT
      - DRM_FORMAT_YUV420_10BIT
      
      This modifier will be notably added to DMA-BUF frames imported from the V4L2
      Amlogic VDEC decoder.
      
      This introduces the basic layout composed of:
      - a body content organized in 64x32 superblocks with 4096 bytes per
        superblock in default mode.
      - a 32 bytes per 128x64 header block
      
      This layout is tranferrable between Amlogic SoCs supporting this modifier.
      
      The Memory Saving option exist changing the layout superblock size to save memory when
      using 8bit components pixels size.
      
      Finally is also adds the Scatter Memory layout, meaning the header contains IOMMU
      references to the compressed frames content to optimize memory access
      and layout.
      
      In this mode, only the header memory address is needed, thus the content
      memory organization is tied to the current producer execution and cannot
      be saved/dumped neither transferrable between Amlogic SoCs supporting this
      modifier.
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Tested-by: default avatarKevin Hilman <khilman@baylibre.com>
      Reviewed-by: default avatarKevin Hilman <khilman@baylibre.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200703080728.25207-2-narmstrong@baylibre.com
      d6528ec8
  24. 19 Jun, 2020 2 commits
  25. 22 May, 2020 1 commit
    • James Jones's avatar
      drm: Generalized NV Block Linear DRM format mod · 82c8c4dd
      James Jones authored
      Builds upon the existing NVIDIA 16Bx2 block linear
      format modifiers by adding more "fields" to the
      existing parameterized
      DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier
      macro that allow fully defining a unique-across-
      all-NVIDIA-hardware bit layout using a minimal
      set of fields and values.  The new modifier macro
      DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D is
      effectively backwards compatible with the existing
      macro, introducing a superset of the previously
      definable format modifiers.
      
      Backwards compatibility has two quirks.  First,
      the zero value for the "kind" field, which is
      implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK
      macro, must be special cased in drivers and
      assumed to map to the pre-Turing generic kind of
      0xfe, since a kind of "zero" is reserved for
      linear buffer layouts on all GPUs.
      
      Second, it is assumed backwards compatibility
      is only needed when running on Tegra GPUs, and
      specifically Tegra GPUs prior to Xavier.  This
      is based on two assertions:
      
      -Tegra GPUs prior to Xavier used a slightly
       different raw bit layout than desktop GPUs,
       making it impossible to directly share block
       linear buffers between the two.
      
      -Support for the existing block linear modifiers
       was incomplete, making them useful only for
       exporting buffers created by nouveau and
       importing them to Tegra DRM as framebuffers for
       scan out.  There was no support for adding
       framebuffers using format modifiers in nouveau,
       nor importing dma-buf/PRIME GEM objects into
       nouveau userspace drivers with modifiers in Mesa.
      
      Hence it is assumed the prior modifiers were not
      intended for use on desktop GPUs, and as a
      corollary, were not intended to support sharing
      block linear buffers across two different NVIDIA
      GPUs.
      
      v2:
        - Added canonicalize helper function
      
      v3:
        - Added additional bit to compression field to
          support Tesla (NV5x,G8x,G9x,GT1xx,GT2xx) class
          chips.
      Signed-off-by: default avatarJames Jones <jajones@nvidia.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      82c8c4dd
  26. 08 May, 2020 1 commit
  27. 07 Jan, 2020 1 commit
  28. 23 Dec, 2019 1 commit
  29. 18 Oct, 2019 1 commit
  30. 04 Oct, 2019 1 commit
  31. 21 Mar, 2019 1 commit
    • Maarten Lankhorst's avatar
      drm/fourcc: Fix conflicting Y41x definitions · ff01e697
      Maarten Lankhorst authored
      There has unfortunately been a conflict with the following 3 commits:
      
      commit e9961ab9
      Author: Ayan Kumar Halder <ayan.halder@arm.com>
      Date:   Fri Nov 9 17:21:12 2018 +0000
          drm: Added a new format DRM_FORMAT_XVYU2101010
      
      commit 7ba0fee2
      Author: Brian Starkey <brian.starkey@arm.com>
      Date:   Fri Oct 5 10:27:00 2018 +0100
      
          drm/fourcc: Add AFBC yuv fourccs for Mali
      
      and
      
      commit 50bf5d7d
      Author: Swati Sharma <swati2.sharma@intel.com>
      Date:   Mon Mar 4 17:26:33 2019 +0530
      
          drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
      
      Unfortunately gcc didn't warn about the redefinitions, because the
      double defines were the set to same value, and gcc apparently no longer
      warns about that.
      
      Fix this by using new XYVU for i915, without alpha, and making the
      Y41x definitions match msdn, with alpha.
      
      Fortunately we caught it early, and the conflict hasn't even landed in
      drm-next yet.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Brian Starkey <Brian.Starkey@arm.com>
      Cc: Swati Sharma <swati2.sharma@intel.com>
      Cc: Ayan Kumar Halder <ayan.halder@arm.com>
      Cc: malidp@foss.arm.com
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Liviu Dudau <Liviu.Dudau@arm.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190319121702.6814-1-maarten.lankhorst@linux.intel.com
      Acked-by: Jani Nikula <jani.nikula@intel.com> #irc
      Acked-by: default avatarSean Paul <sean@poorly.run>
      Reviewed-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      ff01e697
  32. 13 Mar, 2019 1 commit
  33. 12 Mar, 2019 2 commits
    • Ayan Kumar Halder's avatar
      drm: Added a new format DRM_FORMAT_XVYU2101010 · e9961ab9
      Ayan Kumar Halder authored
      This new format is supported by DP550 and DP650
      
      Changes since v3 (series):
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarAyan Kumar halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291758/?series=57895&rev=1
      e9961ab9
    • Brian Starkey's avatar
      drm/fourcc: Add AFBC yuv fourccs for Mali · 7ba0fee2
      Brian Starkey authored
      As we look to enable AFBC using DRM format modifiers, we run into
      problems which we've historically handled via vendor-private details
      (i.e. gralloc, on Android).
      
      AFBC (as an encoding) is fully flexible, and for example YUV data can
      be encoded into 1, 2 or 3 encoded "planes", much like the linear
      equivalents. Component order is also meaningful, as AFBC doesn't
      necessarily care about what each "channel" of the data it encodes
      contains. Therefore ABGR8888 and RGBA8888 can be encoded in AFBC with
      different representations. Similarly, 'X' components may be encoded
      into AFBC streams in cases where a decoder expects to decode a 4th
      component.
      
      In addition, AFBC is a licensable IP, meaning that to support the
      ecosystem we need to ensure that _all_ AFBC users are able to describe
      the encodings that they need. This is much better achieved by
      preserving meaning in the fourcc codes when they are combined with an
      AFBC modifier.
      
      In essence, we want to use the modifier to describe the parameters of
      the AFBC encode/decode, and use the fourcc code to describe the data
      being encoded/decoded.
      
      To do anything different would be to introduce redundancy - we would
      need to duplicate in the modifier information which is _already_
      conveyed clearly and non-ambigiously by a fourcc code.
      
      I hope that for RGB this is non-controversial.
      (BGRA8888 + MODIFIER_AFBC) is a different format from
      (RGBA8888 + MODIFIER_AFBC).
      
      Possibly more controversial is that (XBGR8888 + MODIFIER_AFBC)
      is different from (BGR888 + MODIFIER_AFBC). I understand that in some
      schemes it is not the case - but in AFBC it is so.
      
      Where we run into problems is where there are not already fourcc codes
      which represent the data which the AFBC encoder/decoder is processing.
      To that end, we want to introduce new fourcc codes to describe the
      data being encoded/decoded, in the places where none of the existing
      fourcc codes are applicable.
      
      Where we don't support an equivalent non-compressed layout, or where
      no "obvious" linear layout exists, we are proposing adding fourcc
      codes which have no associated linear layout - because any layout we
      proposed would be completely arbitrary.
      
      Some formats are following the naming conventions from [2].
      
      The summary of the new formats is:
       DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V.
       DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then
                              V. No defined linear encoding.
       DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y)
                         then V. 10-bit samples in 16-bit words.
       DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha.
       DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by
                         interleaved U-then-V plane. 10-bit samples in
                         16-bit words.
       DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then
                                V. No defined linear encoding
       DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U
                                 then V. No defined linear encoding
      
      Please also note that in the absence of AFBC, we would still need to
      add Y410, Y210 and P210.
      
      Full rationale follows:
      
      YUV 444 8-bit, 1-plane
      ----------------------
       The currently defined AYUV format encodes a 4th alpha component,
       which makes it unsuitable for representing a 3-component YUV 444
       AFBC stream.
      
       The proposed[1] XYUV format which is supported by Mali-DP in linear
       layout is also unsuitable, because the component order is the
       opposite of the AFBC version, and it encodes a 4th 'X' component.
      
       DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed,
       YUV 444 8-bit format, with the component order which our HW expects to
       encode/decode. It conforms to the same naming convention as the
       existing packed YUV 444 format.
       The naming here is meant to be consistent with DRM_FORMAT_AYUV and
       DRM_FORMAT_XYUV[1]
      
      YUV 444 10-bit, 1-plane
      -----------------------
       There is no currently-defined YUV 444 10-bit format in
       drm_fourcc.h, irrespective of number of planes.
      
       The proposed[1] XVYU2101010 format which is supported by Mali-DP in
       linear layout uses the wrong component order, and also encodes a 4th
       'X' component, which doesn't match the AFBC version of YUV 444
       10-bit which we support.
      
       DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of
       alpha.  This format is supported with linear layout by Mali GPUs. The
       naming follows[2].
      
       There is no "obvious" linear encoding for a 3-component 10:10:10
       packed format, and so DRM_FORMAT_VUY101010 defines a component
       order, but not a bit encoding. Again, the naming is meant to be
       consistent with DRM_FORMAT_AYUV.
      
      YUV 422 8-bit, 1-plane
      ----------------------
       The existing DRM_FORMAT_YUYV (and the other component orders) are
       single-planar YUV 422 8-bit formats. Following the convention of
       the component orders of the RGB formats, YUYV has the correct
       component order for our AFBC encoding (Y followed by U followed by
       V). We can use YUYV for AFBC YUV 422 8-bit.
      
      YUV 422 10-bit, 1-plane
      -----------------------
       There is no currently-defined YUV 422 10-bit format in drm_fourcc.h
      
       DRM_FORMAT_Y210 is analogous to YUYV, but with 10-bits per sample
       packed into the upper 10-bits of 16-bit samples. This format is
       supported in both linear and AFBC by Mali GPUs.
      
      YUV 422 10-bit, 2-plane
      -----------------------
       The recently defined DRM_FORMAT_P010 format is a 10-bit semi-planar
       YUV 420 format, which has the correct component ordering for an AFBC
       2-plane YUV 420 buffer. The linear layout contains meaningless padding
       bits, which will not be encoded in an AFBC stream.
      
      YUV 420 8-bit, 1-plane
      ----------------------
       There is no currently defined single-planar YUV 420, 8-bit format
       in drm_fourcc.h. There's differing opinions on whether using the
       existing fourcc-implied n_planes where possible is a good idea or
       not when using modifiers.
      
       For me, it's much more "obvious" to use NV12 for 2-plane AFBC and
       YUV420 for 3-plane AFBC. This keeps the aforementioned separation
       between the AFBC codec settings (in the modifier) and the pixel data
       format (in the fourcc). With different vendors using AFBC, this helps
       to ensure that there is no confusion in interoperation. It also
       ensures that the AFBC modifiers describe AFBC itself (which is a
       licensable component), and not implementation details which are not
       defined by AFBC.
      
       The proposed[1] X0L0 format which Mali-DP supports with Linear layout
       is unsuitable, as it contains a 4th 'X' component, and our AFBC
       decoder expects only 3 components.
      
       To that end, we propose a new YUV 420 8-bit format. There is no
       "obvious" linear encoding for a 3-component 8:8:8, 420, packed format,
       and so DRM_FORMAT_YUV420_8BIT defines a component order, but not a
       bit encoding. I'm happy to hear different naming suggestions.
      
      YUV 420 8-bit, 2-, 3-plane
      --------------------------
       These already exist, we can use NV12 and YUV420.
      
      YUV 420 10-bit, 1-plane
      -----------------------
       As above, no current definition exists, and X0L2 encodes a 4th 'X'
       channel.
      
       Analogous to DRM_FORMAT_YUV420_8BIT, we define DRM_FORMAT_YUV420_10BIT.
      
      [1] https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html
      [2] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats
      
      Changes since RFC v1:
       - Fix confusing subsampling vs bit-depth X:X:X notation in
         descriptions (danvet)
       - Rename DRM_FORMAT_AVYU1101010 to DRM_FORMAT_Y410 (Lisa Wu)
       - Add drm_format_info structures for the new formats, using the
         new 'bpp' field for those with non-integer bytes-per-pixel
       - Rebase, including Juha-Pekka Heikkila's format definitions
      
      Changes since RFC v2:
      - Rebase on top of latest changes in drm-misc-next
      - Change the description of DRM_FORMAT_P210 in __drm_format_info and
      drm_fourcc.h so as to make it consistent with other DRM_FORMAT_PXXX
      formats.
      
      Changes since v3:
      - Added the ack
      - Rebased on the latest drm-misc-next
      Signed-off-by: default avatarBrian Starkey <brian.starkey@arm.com>
      Signed-off-by: default avatarAyan Kumar Halder <ayan.halder@arm.com>
      Reviewed-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Acked-by: default avatarAlyssa Rosenzweig <alyssa@rosenzweig.io>
      Link: https://patchwork.freedesktop.org/patch/291759/?series=57895&rev=1
      7ba0fee2
  34. 05 Mar, 2019 1 commit