[Mesa-dev] [PATCH 20/20 v4]] anv: Implement VK_ANDROID_native_buffer (v4)

[Tapani Pälli]

On 09/15/2017 01:06 AM, Chad Versace wrote:
> This implementation is correct (afaict), but takes two shortcuts
> regarding the import/export of Android sync fds.
> 
>    Shortcut 1. When Android calls vkAcquireImageANDROID to import a sync
>    fd into a VkSemaphore or VkFence, the driver instead simply blocks on
>    the sync fd, then puts the VkSemaphore or VkFence into the signalled
>    state. Thanks to implicit sync, this produces correct behavior (with
>    extra latency overhead, perhaps) despite its ugliness.
> 
>    Shortcut 2. When Android calls vkQueueSignalReleaseImageANDROID to export
>    a collection of wait semaphores as a sync fd, the driver instead
>    submits the semaphores to the queue, then returns sync fd -1, which
>    informs the caller that no additional synchronization is needed.
>    Again, thanks to implicit sync, this produces correct behavior (with
>    extra batch submission overhead) despite its ugliness.
> 
> I chose to take the shortcuts instead of properly importing/exporting
> the sync fds for two reasons:
> 
>    Reason 1. I've already tested this patch with dEQP and with demos
>    apps. It works. I wanted to get the tested patches into the tree now,
>    and polish the implementation afterwards.
> 
>    Reason 2. I want to run this on a 3.18 kernel (gasp!). In 3.18, i915
>    supports neither Android's sync_fence, nor upstream's sync_file, nor
>    drm_syncobj. Again, I tested these patches on Android with a 3.18
>    kernel and they work.
> 
> I plan to quickly follow-up with patches that remove the shortcuts and
> properly import/export the sync fds.
> 
> Non-Testing
> ===========
> I did not test at all using the Android.mk buildsystem. I probably
> broke it. Please test and review that.
> 
> Testing
> =======
> I tested with 64-bit ARC++ on a Skylake Chromebook and a 3.18 kernel.
> The following pass:
> 
>    a little spinning cube demo APK
>    dEQP-VK.info.*
>    dEQP-VK.api.smoke.*
>    dEQP-VK.api.info.instance.*
>    dEQP-VK.api.info.device.*
>    dEQP-VK.api.wsi.android.*
> 
> v2:
>    - Reject VkNativeBufferANDROID if the dma-buf's size is too small for
>      the VkImage.
>    - Stop abusing VkNativeBufferANDROID by passing it to vkAllocateMemory
>      during vkCreateImage. Instead, directly import its dma-buf during
>      vkCreateImage with anv_bo_cache_import(). [for jekstrand]
>    - Rebase onto Tapani's VK_EXT_debug_report changes.
>    - Drop `CPPFLAGS += $(top_srcdir)/include/android`. The dir does not
>      exist.
> 
> v3:
>    - Delete duplicate #include "anv_private.h". [per Tapani]
>    - Try to fix the Android-IA build in Android.vulkan.mk by following
>      Tapani's example in
>      <https://lists.freedesktop.org/archives/mesa-dev/2017-September/169602.html>.
>      But I truncated the added include path from
>      "frameworks/native/vulkan/include/hardware" to
>      "frameworks/native/vulkan/include", and inserted it *after*
>      $(MESA_TOP)/include/vulkan, so that #include <hardware/hwvulkan.h>
>      hopefully works in both the Autotools and Android.mk build.

Unfortunately this does not seem to do the trick, I can see Mesa include 
is before the frameworks one but I still get the errors. I'll try to 
figure out some cure.

build log: http://tpalli.kapsi.fi/vulkan.log

// Tapani