On 12/11/18 1:22 PM, Lionel Landwerlin wrote:
On 27/11/2018 10:53, Tapani Pälli wrote:
Use the anv_format address in formats table as implementation-defined
external format identifier for now. When adding YUV format support this
might need to change.

v2: code cleanup (Jason)
v3: set anv_format address as identifier
v4: setup suggestedYcbcrModel and suggested[X|Y]ChromaOffset
     as expected for HAL_PIXEL_FORMAT_NV12_Y_TILED_INTEL

Signed-off-by: Tapani Pälli <tapani.pa...@intel.com>
---
  src/intel/vulkan/anv_android.c | 106 +++++++++++++++++++++++++++++++++
  1 file changed, 106 insertions(+)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 916e76c93ff..54b62b9d02f 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -29,6 +29,8 @@
  #include <sync/sync.h>
  #include "anv_private.h"
+#include "vk_format_info.h"
+#include "vk_util.h"
  static int anv_hal_open(const struct hw_module_t* mod, const char* id, struct hw_device_t** dev);
  static int anv_hal_close(struct hw_device_t *dev);
@@ -96,6 +98,110 @@ anv_hal_close(struct hw_device_t *dev)
     return -1;
  }
+static VkResult
+get_ahw_buffer_format_properties(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferFormatPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   /* Get a description of buffer contents . */
+   AHardwareBuffer_Desc desc;
+   AHardwareBuffer_describe(buffer, &desc);
+
+   /* Verify description. */
+   uint64_t gpu_usage =
+      AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE |
+      AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT |
+      AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER;
+
+   /* "Buffer must be a valid Android hardware buffer object with at least
+    * one of the AHARDWAREBUFFER_USAGE_GPU_* usage flags."
+    */
+   if (!(desc.usage & (gpu_usage)))
+      return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   /* Fill properties fields based on description. */
+   VkAndroidHardwareBufferFormatPropertiesANDROID *p = pProperties;
+
+   p->format = vk_format_from_android(desc.format);
+
+   const struct anv_format *anv_format = anv_get_format(p->format);
+   p->externalFormat = (uint64_t) (uintptr_t) anv_format;
+
+   p->formatFeatures =
+      anv_get_image_format_features(&device->info, p->format,
+                                    anv_format, VK_IMAGE_TILING_OPTIMAL);


The Android documentation is not very clear about what the different usages mean for tiling.

But I would expect that DATA_BUFFER would mean linear. Am I wrong?

You are correct, will fix this.


+
+   /* "Images can be created with an external format even if the Android hardware +    *  buffer has a format which has an equivalent Vulkan format to enable +    *  consistent handling of images from sources that might use either category +    *  of format. However, all images created with an external format are subject +    *  to the valid usage requirements associated with external formats, even if
+    *  the Android hardware buffer’s format has a Vulkan equivalent."
+    *
+    * "The formatFeatures member *must* include
+    *  VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT and at least one of
+    *  VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT or
+    *  VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT"
+    */
+   p->formatFeatures |=
+      VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT;
+
+   /* "Implementations may not always be able to determine the color model, +    *  numerical range, or chroma offsets of the image contents, so the values +    *  in VkAndroidHardwareBufferFormatPropertiesANDROID are only suggestions. +    *  Applications should treat these values as sensible defaults to use in +    *  the absence of more reliable information obtained through some other
+    *  means."
+    */
+   p->samplerYcbcrConversionComponents.r = VK_COMPONENT_SWIZZLE_IDENTITY; +   p->samplerYcbcrConversionComponents.g = VK_COMPONENT_SWIZZLE_IDENTITY; +   p->samplerYcbcrConversionComponents.b = VK_COMPONENT_SWIZZLE_IDENTITY; +   p->samplerYcbcrConversionComponents.a = VK_COMPONENT_SWIZZLE_IDENTITY;
+
+   p->suggestedYcbcrModel = VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_601;
+   p->suggestedYcbcrRange = VK_SAMPLER_YCBCR_RANGE_ITU_FULL;
+
+   p->suggestedXChromaOffset = VK_CHROMA_LOCATION_MIDPOINT;
+   p->suggestedYChromaOffset = VK_CHROMA_LOCATION_MIDPOINT;
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_GetAndroidHardwareBufferPropertiesANDROID(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+   struct anv_physical_device *pdevice = &dev->instance->physicalDevice;
+
+   VkAndroidHardwareBufferFormatPropertiesANDROID *format_prop =
+      vk_find_struct(pProperties->pNext,
+                     ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_ANDROID);
+
+   /* Fill format properties of an Android hardware buffer. */
+   if (format_prop)
+      get_ahw_buffer_format_properties(device_h, buffer, format_prop);
+
+   const native_handle_t *handle =
+      AHardwareBuffer_getNativeHandle(buffer);
+   int dma_buf = (handle && handle->numFds) ? handle->data[0] : -1;


Do you need to handle more than one BO for yuv here?

Not at least yet. I'd prefer to land this series with support for only formats that deal with one BO. If in future we need support for more, this can be handled as a separate task.


+   if (dma_buf < 0)
+      return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   /* All memory types. */
+   uint32_t memory_types = (1ull << pdevice->memory.type_count) - 1;
+
+   pProperties->allocationSize = lseek(dma_buf, 0, SEEK_END);
+   pProperties->memoryTypeBits = memory_types;
+
+   return VK_SUCCESS;
+}
+
  VkResult
  anv_image_from_gralloc(VkDevice device_h,
                         const VkImageCreateInfo *base_info,


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to