O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Implementar o Vulkan

A Vulkan é uma API multiplataforma de baixa sobrecarga para gráficos 3D de alto desempenho. Assim como o OpenGL ES (GLES), o Vulkan oferece ferramentas para criar gráficos de alta qualidade em tempo real em apps. As vantagens de usar o Vulkan incluem reduções na sobrecarga da CPU e suporte à linguagem intermediário binário SPIR-V.

Para implementar o Vulkan, um dispositivo precisa incluir:

O carregador do Vulkan, fornecido pelo Android.
Um driver Vulkan, fornecido por SoCs, como IHVs de GPU, que implementa a API Vulkan. Para oferecer suporte à funcionalidade do Vulkan, o dispositivo Android precisa de hardware de GPU compatível com o Vulkan e o driver associado. A GPU também precisa ter suporte a GLES 3.1 e versões mais recentes. Consulte o fornecedor do SoC para solicitar suporte ao driver.

Se um dispositivo incluir um driver do Vulkan, ele precisará declarar os recursos do sistema FEATURE_VULKAN_HARDWARE_LEVEL e FEATURE_VULKAN_HARDWARE_VERSION, com versões que reflitam com precisão os recursos do dispositivo. Isso ajuda a garantir que o dispositivo esteja em conformidade com o Documento de definição de compatibilidade (CDD).

Loader do Vulkan

O carregador do Vulkan platform/frameworks/native/vulkan é a interface principal entre os apps Vulkan e o driver do Vulkan de um dispositivo. O carregador Vulkan está instalado em /system/lib[64]/libvulkan.so. O carregador oferece os pontos de entrada principais da API Vulkan, os pontos de entrada das extensões exigidos pelo CDD do Android e muitas outras extensões opcionais. As extensões de integração do sistema de janela (WSI, na sigla em inglês) são exportadas pelo carregador e implementadas principalmente no carregador, e não no driver. O carregador também oferece suporte à enumeração e ao carregamento de camadas que podem expor extensões adicionais e interceptar chamadas de API principais no caminho para o driver.

O NDK inclui uma biblioteca libvulkan.so stub para vinculação. A biblioteca exporta os mesmos símbolos que o carregador. Os apps chamam as funções exportadas da biblioteca libvulkan.so real para entrar nas funções de trampolim no carregador, que são enviadas para a camada ou o driver apropriado com base no primeiro argumento. A chamada vkGet*ProcAddr() retorna os ponteiros de função para os quais as trampolins são enviadas, ou seja, ela chama diretamente o código principal da API. Chamar pelos ponteiros de função, em vez dos símbolos exportados, é mais eficiente, porque pula a trampolim e o envio.

Enumeração e carregamento de drivers

Quando a imagem do sistema é criada, o Android espera que o sistema saiba quais GPUs estão disponíveis. O carregador usa o mecanismo HAL existente em hardware.h para descobrir e carregar o driver. Os caminhos preferenciais para drivers Vulkan de 32 e 64 bits são:

/vendor/lib/hw/vulkan.<ro.hardware.vulkan>.so
/vendor/lib/hw/vulkan.<ro.product.platform>.so
/vendor/lib64/hw/vulkan.<ro.hardware.vulkan>.so
/vendor/lib64/hw/vulkan.<ro.product.platform>.so

Observação:<ro.hardware.vulkan> e <ro.product.platform> são substituídos pelo valor da propriedade do sistema com esse nome. Para detalhes e locais alternativos compatíveis, consulte libhardware/hardware.c.

No Android 7.0 e versões mais recentes, o derivado hw_module_t do Vulkan encapsula uma única estrutura hw_module_t. Apenas um driver é aceito, e a string constante HWVULKAN_DEVICE_0 é transmitida para open().

O derivado hw_device_t do Vulkan corresponde a um único driver que pode oferecer suporte a vários dispositivos físicos. A estrutura hw_device_t pode ser estendida para exportar as funções vkGetGlobalExtensionProperties(), vkCreateInstance() e vkGetInstanceProcAddr(). O loader pode encontrar todas as outras funções VkInstance(), VkPhysicalDevice() e vkGetDeviceProcAddr() chamando o vkGetInstanceProcAddr() da estrutura hw_device_t.

Descoberta e carregamento de camadas

O carregador do Vulkan oferece suporte à enumeração e ao carregamento de camadas que podem expor extensões adicionais e interceptar chamadas de API principais a caminho do driver. O Android não inclui camadas na imagem do sistema. No entanto, os apps podem incluir camadas no APK.

Ao usar camadas, lembre-se de que as políticas e o modelo de segurança do Android são muito diferentes dos que são usados por outras plataformas. Em particular, o Android não permite carregar código externo em um processo não depurável em dispositivos de produção (não enraizados), nem permite que o código externo inspecione ou controle a memória, o estado do processo e assim por diante. Isso inclui a proibição de salvar despejos de núcleo, traces da API e assim por diante, no disco para inspeção posterior. Somente as camadas entregues como parte de apps não depuráveis são ativadas em dispositivos de produção, e os drivers não podem fornecer funcionalidades que violem essas políticas.

Os casos de uso de camadas incluem:

Camadas no desenvolvimento: as camadas de validação e shims para ferramentas de rastreamento/criação de perfil/depuração não podem ser instaladas na imagem do sistema de dispositivos de produção. As camadas de validação e shims para ferramentas de rastreamento/criação de perfil/depuração precisam ser atualizáveis sem uma imagem do sistema. Os desenvolvedores que querem usar uma dessas camadas durante o desenvolvimento podem modificar o pacote do app, por exemplo, adicionando um arquivo ao diretório de bibliotecas nativas. Engenheiros de IHV e OEM que querem diagnosticar falhas no envio de apps não modificáveis têm acesso a builds de não produção (com acesso root) da imagem do sistema, a menos que esses apps sejam depuráveis. Para mais informações, consulte Camadas de validação do Vulkan no Android.
Camadas de utilitários: essas camadas expõem extensões, como uma camada que implementa um gerenciador de memória para a memória do dispositivo. Os desenvolvedores escolhem as camadas e as versões delas para usar no app. Apps diferentes que usam a mesma camada ainda podem usar versões diferentes. Os desenvolvedores escolhem qual dessas camadas enviar no pacote do app.
Camadas injetadas (implícitas): incluem camadas como frame rate, rede social e sobreposições da tela de início do jogo fornecidas pelo usuário ou por outro app sem o conhecimento ou consentimento do app. Eles violam as políticas de segurança do Android e não têm suporte.

Para apps não depuráveis, o carregador procura camadas apenas no diretório de biblioteca nativa do app e tenta carregar qualquer biblioteca com um nome que corresponda a um padrão específico (por exemplo, libVKLayer_foo.so).

Para apps depuráveis, o carregador procura camadas em /data/local/debug/vulkan e tenta carregar qualquer biblioteca que corresponda a um padrão específico.

O Android permite que as camadas sejam portadas com mudanças no ambiente de build entre o Android e outras plataformas. Para saber mais sobre a interface entre as camadas e o carregador, consulte Arquitetura das interfaces do carregador do Vulkan. As camadas de validação mantidas pelo Khronos são hospedadas em Camadas de validação do Vulkan (link em inglês).

Versões e recursos da API do Vulkan

A tabela a seguir lista as versões da API do Vulkan para várias versões do Android.

Versão do Android	Versão do Vulkan
Android 13	Vulkan 1.3
Android 9	Vulkan 1.1
Android 7	Vulkan 1.0

Visão geral da funcionalidade do Vulkan 1.3

O Vulkan 1.3 canoniza várias extensões anteriormente opcionais na funcionalidade principal do Vulkan. Grande parte dessa funcionalidade está incluída com a intenção de aumentar o controle e a granularidade sobre a interface de programação do Vulkan. As instâncias de renderização de uma única passagem não precisam mais de objetos de renderização de uma única passagem ou framebuffers. O número total de objetos de estado do pipeline pode ser reduzido, e a sincronização na API é revisada. A Vulkan 1.3 tem os mesmos requisitos de hardware que a Vulkan 1.2, 1.1 e 1.0, com a maioria da implementação no driver de gráficos específico do SoC, e não no framework.

Os recursos mais importantes do Vulkan 1.3 para Android são:

Suporte a instâncias de passagem de renderização de passagem única
Suporte para encerrar imediatamente uma invocação de sombreador
Mais granularidade para criação, compartilhamento e controle de pipelines

A Vulkan 1.3 também inclui vários recursos menores e melhorias na usabilidade da API. Todas as mudanças feitas na API principal do Vulkan com revisão secundária 1.3 podem ser encontradas em Revisões principais (Vulkan 1.3).

Visão geral da funcionalidade do Vulkan 1.2

O Vulkan 1.2 adiciona vários recursos e extensões que simplificam a superfície da API. Isso inclui um modelo de memória unificado e outras informações que podem ser consultadas em um driver de dispositivo. O Vulkan 1.2 tem os mesmos requisitos de hardware do Vulkan 1.0 e 1.1. Toda a implementação está no driver de gráficos específico do SoC, não no framework.

O recurso mais importante do Vulkan 1.2 para Android é o suporte ao armazenamento de 8 bits.

O Vulkan 1.2 também inclui vários recursos menores e melhorias na usabilidade da API. Todas as mudanças feitas na API Vulkan principal com a revisão menor 1.2 podem ser encontradas em Revisões principais (Vulkan 1.2).

Visão geral da funcionalidade do Vulkan 1.1

O Vulkan 1.1 inclui suporte à interoperabilidade de memória/sincronização, o que permite que os OEMs ofereçam suporte ao Vulkan 1.1 em dispositivos. Além disso, a interoperabilidade de memória/sincronização permite que os desenvolvedores determinem se o Vulkan 1.1 tem suporte em um dispositivo e o usem de maneira eficaz quando isso acontece. O Vulkan 1.1 tem os mesmos requisitos de hardware do Vulkan 1.0, mas a maior parte da implementação está no driver de gráficos específico do SOC, não no framework.

Os recursos mais importantes do Vulkan 1.1 para Android são:

Suporte para importar e exportar buffers de memória e objetos de sincronização fora do Vulkan (para interoperabilidade com câmera, codecs e GLES)
Compatibilidade com formatos YCbCr

O Vulkan 1.1 também inclui vários recursos menores e melhorias de usabilidade da API. Todas as mudanças feitas na API principal do Vulkan com a revisão menor 1.1 podem ser encontradas em Revisões principais (Vulkan 1.1).

Escolher o suporte ao Vulkan

Os dispositivos Android precisam oferecer suporte ao conjunto de recursos mais avançado do Vulkan disponível, desde que ofereçam suporte a uma ABI de 64 bits e não tenham pouca memória.

Os dispositivos lançados com o Android 13 e versões mais recentes precisam oferecer suporte ao Vulkan 1.3.

Os dispositivos que são iniciados pelo Android 10 precisam oferecer suporte ao Vulkan 1.1.

Outros dispositivos podem oferecer suporte opcional ao Vulkan 1.3, 1.2 e 1.1.

Suporte a uma versão do Vulkan

Um dispositivo Android oferece suporte a uma versão do Vulkan se as seguintes condições forem atendidas:

Adicione um driver Vulkan compatível com a versão do Vulkan de interesse (ela precisa ser a versão 1.3, 1.1 ou 1.0) com os requisitos do CDD adicionais da versão do Android. Como alternativa, atualize um driver Vulkan existente com um número de versão mais baixo.
Observação:no Android 14 e versões mais recentes, todos os dispositivos compatíveis com Vulkan precisam ter drivers Vulkan 1.1. Consulte os requisitos do CDD do Android 14 para mais informações.
Para a Vulkan 1.3 ou 1.1, verifique se o recurso do sistema retornado pelo gerenciador de pacotes retorna true para a versão correta do Vulkan.
- Para o Vulkan 1.3, o recurso é PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000).
- Para o Vulkan 1.1, o recurso é PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000).
O gerenciador de pacotes vai retornar true para o Vulkan 1.3 e o Vulkan 1.1 adicionando uma regra, mostrada a seguir, a um arquivo device.mk adequado.
- Adicione o seguinte para o Vulkan 1.3:
```
PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.vulkan.version-1_3.xml:
$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.vulkan.version.xml
```
- Adicione o seguinte para o Vulkan 1.1:
```
PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.vulkan.version-1_1.xml:
$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.vulkan.version.xml
```

Perfil de referência do Android (ABP, na sigla em inglês)

Encorajamos todos os dispositivos Android a estarem com o perfil de referência do Android 2022 mais recente, conforme descrito no guia de perfil de referência do Android.

Qualquer dispositivo que ofereça suporte ao Android 14 ou versões mais recentes e à API Vulkan precisa atender a todas as funcionalidades definidas no perfil de referência do Android de 2021. A lista completa de funcionalidades necessárias é enumerada no arquivo json do perfil do Vulkan, mas um subconjunto importante das funcionalidades necessárias inclui:

Texturas compactadas por ASTC e ETC.
Espaços de cores variáveis até VK_EXT_swapchain_colorspace.
Sombra de amostras e interpolação multiamostra usando sampleRateShading.

Integração do sistema de janelas (WSI, na sigla em inglês)

No libvulkan.so, o driver implementa estas extensões de integração de sistema de janelas (WSI, na sigla em inglês):

VK_KHR_surface
VK_KHR_android_surface
VK_KHR_swapchain
VK_KHR_driver_properties, implementado para Vulkan 1.1 apenas no Android 10
VK_GOOGLE_display_timing, implementado para qualquer versão do Vulkan no Android 10

Os objetos VkSurfaceKHR e VkSwapchainKHR e todas as interações com ANativeWindow são processadas pela plataforma e não são expostas aos drivers. A implementação da WSI depende da extensão VK_ANDROID_native_buffer, que precisa ser compatível com o driver. Essa extensão é usada apenas pela implementação da WSI e não é exposta a apps.

Flags de uso do Gralloc

As implementações do Vulkan podem precisar que os buffers de swapchain sejam alocados com flags de uso de Gralloc privadas definidas pela implementação. Ao criar uma cadeia de troca, o Android pede ao driver para traduzir as flags de uso de formato e imagem solicitadas em flags de uso do Gralloc, chamando:

typedef enum VkSwapchainImageUsageFlagBitsANDROID {
    VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID = 0x00000001,
    VK_SWAPCHAIN_IMAGE_USAGE_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF
} VkSwapchainImageUsageFlagBitsANDROID;
typedef VkFlags VkSwapchainImageUsageFlagsANDROID;

VkResult VKAPI vkGetSwapchainGrallocUsage2ANDROID(
    VkDevice                          device,
    VkFormat                          format,
    VkImageUsageFlags                 imageUsage,
    VkSwapchainImageUsageFlagsANDROID swapchainUsage,
    uint64_t*                         grallocConsumerUsage,
    uint64_t*                         grallocProducerUsage
);

Os parâmetros format e imageUsage são retirados da estrutura VkSwapchainCreateInfoKHR. O driver precisa preencher *grallocConsumerUsage e *grallocProducerUsage com as flags de uso do Gralloc necessárias para o formato e o uso. Os flags de uso retornados pelo driver são combinados com os flags de uso solicitados pelo consumidor da cadeia de troca ao alocar buffers.

O Android 7.x chama uma versão anterior de VkSwapchainImageUsageFlagsANDROID(), chamada vkGetSwapchainGrallocUsageANDROID(). O Android 8.0 e versões mais recentes descontinuaram vkGetSwapchainGrallocUsageANDROID(), mas ainda chamam vkGetSwapchainGrallocUsageANDROID() se vkGetSwapchainGrallocUsage2ANDROID() não for fornecido pelo driver:

VkResult VKAPI vkGetSwapchainGrallocUsageANDROID(
    VkDevice            device,
    VkFormat            format,
    VkImageUsageFlags   imageUsage,
    int*                grallocUsage
);

vkGetSwapchainGrallocUsageANDROID() não oferece suporte a flags de uso de swapchain ou flags de uso estendidas do Gralloc.

Imagens apoiadas por Gralloc

VkNativeBufferANDROID é uma estrutura de extensão de vkCreateImage para criar uma imagem apoiada por um buffer do Gralloc. O VkNativeBufferANDROID é fornecido para vkCreateImage() na cadeia de estrutura VkImageCreateInfo. As chamadas para vkCreateImage() com VkNativeBufferANDROID acontecem durante a chamada para vkCreateSwapchainKHR. A implementação da WSI aloca o número de buffers nativos solicitados para a cadeia de troca e, em seguida, cria um VkImage para cada um:

typedef struct {
    VkStructureType             sType; // must be VK_STRUCTURE_TYPE_NATIVE_BUFFER_ANDROID
    const void*                 pNext;

    // Buffer handle and stride returned from gralloc alloc()
    buffer_handle_t             handle;
    int                         stride;

    // Gralloc format and usage requested when the buffer was allocated.
    int                         format;
    int                         usage;
    // Beginning in Android 8.0, the usage field above is deprecated and the
    // usage2 struct below was added. The usage field is still filled in for
    // compatibility with Android 7.0 drivers. Drivers for Android 8.0
    // should prefer the usage2 struct, especially if the
    // android.hardware.graphics.allocator HAL uses the extended usage bits.
    struct {
        uint64_t                consumer;
        uint64_t                producer;
    } usage2;
} VkNativeBufferANDROID;

Ao criar uma imagem com suporte do Gralloc, o VkImageCreateInfo tem os seguintes dados:

  .sType               = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO
  .pNext               = the above VkNativeBufferANDROID structure
  .imageType           = VK_IMAGE_TYPE_2D
  .format              = a VkFormat matching the format requested for the gralloc buffer
  .extent              = the 2D dimensions requested for the gralloc buffer
  .mipLevels           = 1
  .arraySize           = 1
  .samples             = 1
  .tiling              = VK_IMAGE_TILING_OPTIMAL
  .usage               = VkSwapchainCreateInfoKHR::imageUsage
  .flags               = 0
  .sharingMode         = VkSwapchainCreateInfoKHR::imageSharingMode
  .queueFamilyCount    = VkSwapchainCreateInfoKHR::queueFamilyIndexCount
  .pQueueFamilyIndices = VkSwapchainCreateInfoKHR::pQueueFamilyIndices

No Android 8.0 e versões mais recentes, a plataforma fornece uma estrutura de extensão VkSwapchainImageCreateInfoKHR na cadeia VkImageCreateInfo fornecida para vkCreateImage quando qualquer flag de uso de imagem de swapchain é necessária para a swapchain. A estrutura de extensão contém as flags de uso de imagem da cadeia de troca:

typedef struct {
    VkStructureType                        sType; // must be VK_STRUCTURE_TYPE_SWAPCHAIN_IMAGE_CREATE_INFO_ANDROID
    const void*                            pNext;

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

No Android 10 e versões mais recentes, a plataforma oferece suporte à VK_KHR_swapchain v70. Assim, o app Vulkan pode criar um VkImage apoiado pela memória de cadeia de troca. Primeiro, o app chama vkCreateImage com uma estrutura VkImageSwapchainCreateInfoKHR encadeada à estrutura VkImageCreateInfo. Em seguida, o app chama vkBindImageMemory2(KHR) com uma estrutura VkBindImageMemorySwapchainInfoKHR encadeada à estrutura VkBindImageMemoryInfo. O imageIndex especificado na estrutura VkBindImageMemorySwapchainInfoKHR precisa ser um índice de imagem de cadeia de troca válido. Enquanto isso, a plataforma fornece uma estrutura de extensão VkNativeBufferANDROID com as informações do buffer Gralloc correspondente à cadeia VkBindImageMemoryInfo. Assim, o driver sabe qual buffer Gralloc vincular ao VkImage.

Adquirir imagens

vkAcquireImageANDROID adquire a propriedade de uma imagem de cadeia de troca e importa uma cerca nativa sinalizada externamente em um objeto VkSemaphore e um objeto VkFence:

VkResult VKAPI vkAcquireImageANDROID(
    VkDevice            device,
    VkImage             image,
    int                 nativeFenceFd,
    VkSemaphore         semaphore,
    VkFence             fence
);

vkAcquireImageANDROID() é chamado durante vkAcquireNextImageKHR para importar uma cerca nativa nos objetos VkSemaphore e VkFence fornecidos pelo app. No entanto, os objetos de semáforo e de cerca são opcionais nessa chamada. O driver também pode usar essa oportunidade para reconhecer e processar qualquer mudança externa no estado do buffer Gralloc. Muitos drivers não precisam fazer nada aqui. Essa chamada coloca o VkSemaphore e VkFence no mesmo estado pendente, como se fosse sinalizado por vkQueueSubmit. Assim, as filas podem aguardar no semáforo e o app pode aguardar na cerca.

Ambos os objetos são sinalizados quando a cerca nativa subjacente é sinalizada. Se a cerca nativa já tiver sido sinalizada, o semáforo estará no estado sinalizado quando essa função retornar. O driver assume a propriedade do descritor de arquivo da cerca e o fecha quando não é mais necessário. O driver precisa fazer isso mesmo que nenhum objeto de semáforo ou cerca seja fornecido ou mesmo que vkAcquireImageANDROID falhe e retorne um erro. Se fenceFd for -1, é como se a fronteira nativa já tivesse sido indicada.

Imagens da versão

vkQueueSignalReleaseImageANDROID prepara uma imagem de cadeia de troca para uso externo, cria uma cerca nativa e programa a sinalização da cerca nativa depois que os semáforos de entrada forem sinalizados:

VkResult VKAPI vkQueueSignalReleaseImageANDROID(
    VkQueue             queue,
    uint32_t            waitSemaphoreCount,
    const VkSemaphore*  pWaitSemaphores,
    VkImage             image,
    int*                pNativeFenceFd
);

vkQueuePresentKHR() chama vkQueueSignalReleaseImageANDROID() na fila fornecida. O driver precisa produzir uma cerca nativa que não sinalize até que todos os semáforos waitSemaphoreCount em pWaitSemaphores sejam sinalizados, e qualquer trabalho adicional necessário para preparar image para a apresentação seja concluído.

Se os semáforos de espera (se houver) já tiverem sido sinalizados e queue já estiver ocioso, o driver poderá definir *pNativeFenceFd como -1 em vez de um descritor de arquivo de cerca nativa real, indicando que não há nada a ser esperado. O autor da chamada é proprietário e fecha o descritor de arquivo retornado em *pNativeFenceFd.

Muitos drivers podem ignorar o parâmetro de imagem, mas alguns podem precisar preparar estruturas de dados do lado da CPU associadas a um buffer Gralloc para uso por consumidores de imagens externos. A preparação do conteúdo do buffer para uso por consumidores externos precisa ser feita de forma assíncrona como parte da transição da imagem para VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.

Se a imagem foi criada com VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, o driver precisa permitir que vkQueueSignalReleaseImageANDROID() seja chamado repetidamente sem chamadas intermediárias para vkAcquireImageANDROID().

Suporte a imagem compartilhável e apresentável

Alguns dispositivos podem compartilhar a propriedade de uma única imagem entre o pipeline de exibição e a implementação do Vulkan para minimizar a latência. No Android 9 e versões mais recentes, o loader anuncia condicionalmente a extensão VK_KHR_shared_presentable_image com base na resposta do driver a uma chamada para vkGetPhysicalDeviceProperties2.

Se o driver não oferecer suporte ao Vulkan 1.1 ou à extensão VK_KHR_physical_device_properties2, o carregador não anunciará o suporte a imagens compartilháveis e apresentáveis. Caso contrário, o carregador consulta os recursos do driver chamando vkGetPhysicalDeviceProperties2() e incluindo a seguinte estrutura na cadeia VkPhysicalDeviceProperties2::pNext:

typedef struct {
    VkStructureType sType; // must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENTATION_PROPERTIES_ANDROID
    const void*     pNext;
    VkBool32        sharedImage;
} VkPhysicalDevicePresentationPropertiesANDROID;

Se o driver puder compartilhar a propriedade de uma imagem com o sistema de exibição, ele definirá o membro sharedImage como VK_TRUE.

Validação

Os OEMs podem testar a implementação do Vulkan usando o CTS, que inclui o seguinte:

Testes de conformidade do Khronos Vulkan no módulo CtsDeqpTestCases, que inclui testes de API funcional para Vulkan 1.0, 1.1, 1.2 e 1.3.
O módulo CtsGraphicsTestCases, que testa se o dispositivo está configurado corretamente para os recursos do Vulkan compatíveis.

Flag de recurso do Vulkan

Um dispositivo compatível com o Android 11 ou versões mais recentes e com a API Vulkan precisa expor uma flag de recursos, android.software.vulkan.deqp.level. O valor dessa sinalização de recurso é uma data codificada como um valor inteiro. Ele especifica a data associada aos testes dEQP do Vulkan em que o dispositivo afirma ser aprovado.

Uma data no formato AAAA-MM-DD é codificada como um número inteiro de 32 bits da seguinte maneira:

Os bits 0 a 15 armazenam o ano
Os bits 16 a 23 armazenam o mês
Os bits 24 a 31 armazenam o dia.

O valor mínimo permitido para a flag de recurso é 0x07E30301, que corresponde à data de 01/03/2019, que é a data associada aos testes dEQP do Vulkan para o Android 10. Se a sinalização de recurso tiver pelo menos esse valor, o dispositivo alega ser aprovado em todos os testes dEQP do Vulkan do Android 10.

O valor 0x07E40301 corresponde à data de 01/03/2020, que é a data associada aos testes de dEQP do Vulkan para o Android 11. Se a flag do recurso for pelo menos esse valor, o dispositivo vai alegar que passou em todos os testes do Vulkan dEQP do Android 11.

O valor 0x07E60301 corresponde à data 2022-03-01, que é a data associada aos testes de dEQP do Vulkan para o Android 13. Se o flag de recurso tiver pelo menos esse valor, o dispositivo será considerado aprovado em todos os testes dEQP do Vulkan do Android 13.

Um dispositivo que expõe uma flag de recurso específica (por exemplo 0x07E30301, 0x07E40301, 0x07E60301) afirma que passou em todos os testes dEQP do Android Vulkan dessa flag de recurso (Android 10, Android 11 e Android 13, respectivamente). Esse dispositivo pode passar nos testes de dEQP do Vulkan de uma versão mais recente do Android.

O dEQP do Vulkan faz parte do CTS do Android. No Android 11 e versões mais recentes, o componente do executor de teste dEQP do CTS reconhece a flag de recurso android.software.vulkan.deqp.level e ignora todos os testes dEQP do Vulkan que, de acordo com essa flag de recurso, o dispositivo não declara ter suporte. Esses testes são informados como triviais.