<div dir="ltr"><div>One other comment (that I don't know what patch to make it on):  I think we want to disallow the MUTABLE_FORMAT create bit with at least the CCS modifier.  Also, the CCS modifier needs to only be usable with CCS-supported formats.  You may have already thought of those two things but I wanted to get it out of my brain.<br><br></div>--Jason<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 7, 2017 at 12:38 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Nov 7, 2017 at 6:48 AM, Chad Versace <span dir="ltr"><<a href="mailto:chadversary@chromium.org" target="_blank">chadversary@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Incremental implementation of VK_EXT_image_drm_format_modifi<wbr>er.<br>
---<br>
 src/intel/vulkan/anv_formats.<wbr>c | 45 ++++++++++++++++++++++++++++++<wbr>+++++++-----<br>
 1 file changed, 40 insertions(+), 5 deletions(-)<br>
<br>
diff --git a/src/intel/vulkan/anv_formats<wbr>.c b/src/intel/vulkan/anv_formats<wbr>.c<br>
index dc46fdb5425..d6eeb9d1c45 100644<br>
--- a/src/intel/vulkan/anv_formats<wbr>.c<br>
+++ b/src/intel/vulkan/anv_formats<wbr>.c<br>
@@ -813,6 +813,7 @@ static VkResult<br>
 anv_get_image_format_properti<wbr>es(<br>
    struct anv_physical_device *physical_device,<br>
    const VkPhysicalDeviceImageFormatInf<wbr>o2KHR *info,<br>
+   const VkPhysicalDeviceImageDrmFormat<wbr>ModifierInfoEXT *drm_info,<br>
    VkImageFormatProperties *pImageFormatProperties,<br>
    VkSamplerYcbcrConversionImageF<wbr>ormatPropertiesKHR *pYcbcrImageFormatProperties)<br>
 {<br>
@@ -826,14 +827,34 @@ anv_get_image_format_propertie<wbr>s(<br>
    if (format == NULL)<br>
       goto unsupported;<br>
<br>
+   uint64_t drm_format_mod = DRM_FORMAT_MOD_INVALID;<br>
+   if (drm_info) {<br>
+      assert(info->tiling == VK_IMAGE_TILING_DRM_FORMAT_MOD<wbr>IFIER_EXT);<br>
+      drm_format_mod = drm_info->drmFormatModifier;<br>
+   }<br>
+<br>
    VkFormatFeatureFlags format_feature_flags =<br>
       get_image_format_features(dev<wbr>info, info->format, format, info->tiling,<br>
-                                DRM_FORMAT_MOD_INVALID);<br>
+                                drm_format_mod);<br>
+<br>
+   /* The core Vulkan spec places strict constraints on the image capabilities<br>
+    * advertised here. For example, the core spec requires that<br>
+    *     maxMipLevels == log2(maxWidth) + 1<br>
+    * when tiling is VK_IMAGE_TILING_OPTIMAL; and requires that<br>
+    *     maxExtent >= VkPhysicalDeviceLimits::maxIma<wbr>geDimension${N}D.<br>
+    * However, the VK_EXT_image_drm_format_modifi<wbr>er specification grants the<br>
+    * implementation the freedom to further restrict the image capabilities<br>
+    * when tiling is VK_IMAGE_TILING_DRM_FORMAT_MOD<wbr>IFIER_EXT.<br></blockquote><div><br></div></div></div><div>How about adding one extra paragraph here saying that we choose to only support "simple" 2D images.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+    */<br>
<br>
    switch (info->type) {<br>
    default:<br>
       unreachable("bad VkImageType");<br>
    case VK_IMAGE_TYPE_1D:<br>
+      /* We reject 1D images with modifiers due to FUD */<br></blockquote><div><br></div></span><div>We could support 1D but meh.  Just use a texture buffer instead.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+      if (drm_info)<br>
+         goto unsupported;<br>
+<br>
       maxExtent.width = 16384;<br>
       maxExtent.height = 1;<br>
       maxExtent.depth = 1;<br>
@@ -848,10 +869,20 @@ anv_get_image_format_propertie<wbr>s(<br>
       maxExtent.width = 16384;<br>
       maxExtent.height = 16384;<br>
       maxExtent.depth = 1;<br>
-      maxMipLevels = 15; /* log2(maxWidth) + 1 */<br>
-      maxArraySize = 2048;<br>
+<br>
+      if (drm_info) {<br>
+         maxMipLevels = 1;<br>
+         maxArraySize = 1;<br>
+      } else {<br>
+         maxMipLevels = 15; /* log2(maxWidth) + 1 */<br>
+         maxArraySize = 2048;<br>
+      }<br>
       break;<br>
    case VK_IMAGE_TYPE_3D:<br>
+      /* We reject 3D images with modifiers due to FUD */<br></blockquote><div><br></div></span><div>I have neither uncertainty nor doubt, but I do have a very healthy helping of fear. :-)  Let's just go with a global comment above and drop the ones that make us look like cowards. :-P</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+      if (drm_info)<br>
+         goto unsupported;<br>
+<br>
       maxExtent.width = 2048;<br>
       maxExtent.height = 2048;<br>
       maxExtent.depth = 2048;<br>
@@ -976,7 +1007,7 @@ VkResult anv_GetPhysicalDeviceImageForm<wbr>atProperties(<br>
       .flags = createFlags,<br>
    };<br>
<br>
-   return anv_get_image_format_propertie<wbr>s(physical_device, &info,<br>
+   return anv_get_image_format_propertie<wbr>s(physical_device, &info, NULL,<br>
                                           pImageFormatProperties, NULL);<br>
 }<br>
<br>
@@ -1009,6 +1040,7 @@ VkResult anv_GetPhysicalDeviceImageForm<wbr>atProperties2KHR(<br>
 {<br>
    ANV_FROM_HANDLE(anv_physical_d<wbr>evice, physical_device, physicalDevice);<br>
    const VkPhysicalDeviceExternalImageF<wbr>ormatInfoKHR *external_info = NULL;<br>
+   const VkPhysicalDeviceImageDrmFormat<wbr>ModifierInfoEXT *drm_info = NULL;<br>
    VkExternalImageFormatPropertie<wbr>sKHR *external_props = NULL;<br>
    VkSamplerYcbcrConversionImageF<wbr>ormatPropertiesKHR *ycbcr_props = NULL;<br>
    VkResult result;<br>
@@ -1019,6 +1051,9 @@ VkResult anv_GetPhysicalDeviceImageForm<wbr>atProperties2KHR(<br>
       case VK_STRUCTURE_TYPE_PHYSICAL_DEV<wbr>ICE_EXTERNAL_IMAGE_FORMAT_INFO<wbr>_KHR:<br>
          external_info = (const void *) s;<br>
          break;<br>
+      case VK_STRUCTURE_TYPE_PHYSICAL_DEV<wbr>ICE_IMAGE_DRM_FORMAT_MODIFIER_<wbr>INFO_EXT:<br>
+         drm_info = (const void *) s;<br>
+         break;<br>
       default:<br>
          anv_debug_ignored_stype(s->sTy<wbr>pe);<br>
          break;<br>
@@ -1041,7 +1076,7 @@ VkResult anv_GetPhysicalDeviceImageForm<wbr>atProperties2KHR(<br>
    }<br>
<br>
    result = anv_get_image_format_propertie<wbr>s(physical_device, base_info,<br>
-               &base_props->imageFormatPrope<wbr>rties, ycbcr_props);<br>
+               drm_info, &base_props->imageFormatProper<wbr>ties, ycbcr_props);<br>
    if (result != VK_SUCCESS)<br>
       goto fail;<br>
<span class="m_-2708994088044397590HOEnZb"><font color="#888888"><br>
--<br>
2.13.0<br>
<br>
______________________________<wbr>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</font></span></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>