<div dir="ltr"><div>On most hardware, there is a minimum pitch alignment for linear and any greater multiple of the alignment is fine.</div><div><br></div><div>On Navi, the pitch in bytes for linear must be align(width * bpp / 8, 256). That's because the hw computes the pitch from the width and doesn't allow setting a custom pitch. For that reason, multi-GPU sharing might not be possible if the other GPU doesn't align the pitch in exactly the same way.<br></div><div><br></div><div>Marek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 28, 2020 at 10:38 AM Simon Ser <<a href="mailto:contact@emersion.fr">contact@emersion.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There have suggestions to bake pitch alignment, address alignement,<br>
contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)<br>
constraints into modifiers. Last time this was brought up it seemed<br>
like the consensus was to not allow this. Document this in drm_fourcc.h.<br>
<br>
There are several reasons for this.<br>
<br>
- Encoding all of these constraints in the modifiers would explode the<br>
  search space pretty quickly (we only have 64 bits to work with).<br>
- Modifiers need to be unambiguous: a buffer can only have a single<br>
  modifier.<br>
- Modifier users aren't expected to parse modifiers.<br>
<br>
v2: add paragraph about aliases (Daniel)<br>
<br>
v3: fix unrelated changes sent with the patch<br>
<br>
Signed-off-by: Simon Ser <<a href="mailto:contact@emersion.fr" target="_blank">contact@emersion.fr</a>><br>
Reviewed-by: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch" target="_blank">daniel.vetter@ffwll.ch</a>><br>
Cc: Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>><br>
Cc: Bas Nieuwenhuizen <<a href="mailto:bas@basnieuwenhuizen.nl" target="_blank">bas@basnieuwenhuizen.nl</a>><br>
Cc: Dave Airlie <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>><br>
Cc: Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>><br>
---<br>
 include/uapi/drm/drm_fourcc.h | 15 +++++++++++++++<br>
 1 file changed, 15 insertions(+)<br>
<br>
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h<br>
index 490143500a50..f41fcb1ed63d 100644<br>
--- a/include/uapi/drm/drm_fourcc.h<br>
+++ b/include/uapi/drm/drm_fourcc.h<br>
@@ -58,6 +58,21 @@ extern "C" {<br>
  * may preserve meaning - such as number of planes - from the fourcc code,<br>
  * whereas others may not.<br>
  *<br>
+ * Modifiers must uniquely encode buffer layout. In other words, a buffer must<br>
+ * match only a single modifier. A modifier must not be a subset of layouts of<br>
+ * another modifier. For instance, it's incorrect to encode pitch alignment in<br>
+ * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel<br>
+ * aligned modifier. That said, modifiers can have implicit minimal<br>
+ * requirements.<br>
+ *<br>
+ * For modifiers where the combination of fourcc code and modifier can alias,<br>
+ * a canonical pair needs to be defined and used by all drivers. An example<br>
+ * is AFBC, where both ARGB and ABGR have the exact same compressed layout.<br>
+ *<br>
+ * Users see modifiers as opaque tokens they can check for equality and<br>
+ * intersect. Users musn't need to know to reason about the modifier value<br>
+ * (i.e. users are not expected to extract information out of the modifier).<br>
+ *<br>
  * Vendors should document their modifier usage in as much detail as<br>
  * possible, to ensure maximum compatibility across devices, drivers and<br>
  * applications.<br>
-- <br>
2.26.2<br>
<br>
<br>
</blockquote></div>