Implementar Vulkan

Vulkan é uma API de plataforma cruzada e baixa sobrecarga para gráficos 3D de alto desempenho. Assim como o OpenGL ES (GLES) , o Vulkan fornece ferramentas para criar gráficos de alta qualidade em tempo real em aplicativos. As vantagens de usar o Vulkan incluem reduções na sobrecarga da CPU e suporte para a linguagem SPIR-V Binary Intermediate .

Nota: Esta seção descreve a implementação do Vulkan; para obter detalhes sobre a arquitetura Vulkan, vantagens, API e outros recursos, consulte Arquitetura Vulkan .

Para implementar o Vulkan com sucesso, um dispositivo deve incluir:

• O carregador Vulkan, fornecido pelo Android.
• Um driver Vulkan, fornecido por SoCs como GPU IHVs, que implementa a API Vulkan . Para oferecer suporte à funcionalidade Vulkan, o dispositivo Android precisa de hardware de GPU compatível com Vulkan e do driver associado. A GPU também deve suportar GLES 3.1 e superior. Consulte seu fornecedor de SoC para solicitar suporte de driver.

Se um dispositivo incluir um driver Vulkan, o dispositivo 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).

Carregador Vulkan

A platform/frameworks/native/vulkan do carregador Vulkan é a interface principal entre os aplicativos Vulkan e o driver Vulkan de um dispositivo. O carregador Vulkan está instalado em /system/lib[64]/libvulkan.so . O carregador fornece os principais pontos de entrada da API Vulkan, os pontos de entrada das extensões exigidas pelo Android CDD e muitas extensões opcionais adicionais. As extensões Window System Integration (WSI) são exportadas pelo carregador e implementadas principalmente no carregador e não no driver. O carregador também suporta enumeração e carregamento de camadas que podem expor extensões adicionais e interceptar chamadas de API principais a caminho do driver.

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

Enumeração e carregamento de driver

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 preferidos 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

Nota: <ro.hardware.vulkan> e <ro.product.platform> são substituídos pelo valor da propriedade de sistema desse nome. Para obter detalhes e locais alternativos suportados, consulte libhardware/hardware.c .

No Android 7.0 e superior, o derivado Vulkan hw_module_t envolve uma única estrutura hw_module_t ; apenas um driver é suportado e a string constante HWVULKAN_DEVICE_0 é passada para open() .

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

Descoberta e carregamento de camadas

O carregador Vulkan oferece suporte à enumeração e 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 aplicativos podem incluir camadas em seu APK.

Ao usar camadas, lembre-se de que o modelo e as políticas de segurança do Android diferem significativamente de 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 (sem root), nem permite que código externo inspecione ou controle a memória, o estado do processo e assim por diante. Isso inclui a proibição de salvar core dumps, rastreamentos de API e assim por diante no disco para inspeção posterior. Somente camadas entregues como parte de aplicativos não depuráveis ​​são habilitadas em dispositivos de produção, e os drivers não devem fornecer funcionalidades que violem essas políticas.

Os casos de uso para camadas incluem:

• Camadas de tempo de desenvolvimento — Camadas de validação e correções para ferramentas de rastreamento/criação de perfil/depuração não devem ser instaladas na imagem do sistema de dispositivos de produção. Camadas de validação e correções para ferramentas de rastreamento/criação de perfil/depuração devem ser atualizáveis ​​sem uma imagem do sistema. Os desenvolvedores que desejam usar uma dessas camadas durante o desenvolvimento podem modificar o pacote do aplicativo, por exemplo, adicionando um arquivo ao diretório de bibliotecas nativas. Presume-se que os engenheiros IHV e OEM que desejam diagnosticar falhas no envio de aplicativos não modificáveis ​​tenham acesso a compilações de não produção (com raiz) da imagem do sistema, a menos que esses aplicativos sejam depuráveis. Para obter mais informações, consulte Camadas de validação Vulkan no Android .
• Camadas utilitárias — 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 camadas e versões dessas camadas para usar em seus aplicativos; aplicativos diferentes que usam a mesma camada ainda podem usar versões diferentes. Os desenvolvedores escolhem quais dessas camadas serão incluídas em seu pacote de aplicativos.
• Camadas injetadas (implícitas) — Inclui camadas como taxa de quadros, rede social e sobreposições de inicializador de jogos fornecidas pelo usuário ou algum outro aplicativo sem o conhecimento ou consentimento do aplicativo. Eles violam as políticas de segurança do Android e não são compatíveis.

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

Para aplicativos 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 camadas sejam portadas com alterações no ambiente de construção entre o Android e outras plataformas. Para obter detalhes sobre a interface entre as camadas e o carregador, consulte Arquitetura das interfaces do carregador Vulkan . As camadas de validação mantidas pelo Khronos estão hospedadas em Vulkan Validation Layers .

Versões e recursos da API Vulkan

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

Versão Android	Versão Vulkan
Andróide 13	Vulcano 1.3
Android 9	Vulcano 1.1
Android 7	Vulcano 1.0

Visão geral da funcionalidade do Vulkan 1.3

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

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

• Suporte para instâncias de renderização de passagem única
• Suporte para encerrar imediatamente uma invocação de shader
• Granularidade mais fina sobre criação, compartilhamento e controle de pipeline

O Vulkan 1.3 também inclui vários recursos menores e melhorias de usabilidade da API. Todas as alterações feitas na API Vulkan principal com revisão secundária 1.3 podem ser encontradas em Core Revisions (Vulkan 1.3) .

Visão geral da funcionalidade do Vulkan 1.2

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 informações adicionais que podem ser consultadas em um driver de dispositivo. Vulkan 1.2 tem os mesmos requisitos de hardware que Vulkan 1.0 e 1.1; toda a implementação está no driver gráfico específico do SoC, não na estrutura.

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

O Vulkan 1.2 também inclui vários recursos menores e melhorias de usabilidade da API. Todas as alterações feitas na API principal do Vulkan com revisão secundária 1.2 podem ser encontradas em Core Revisions (Vulkan 1.2) .

Visão geral da funcionalidade do Vulkan 1.1

O Vulkan 1.1 inclui suporte para 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 é compatível com um dispositivo e o utilizem efetivamente quando for necessário. O Vulkan 1.1 tem os mesmos requisitos de hardware do Vulkan 1.0, mas a maior parte da implementação está no driver gráfico específico do SOC, não na estrutura.

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

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

O Vulkan 1.1 também inclui vários recursos menores e melhorias de usabilidade da API. Todas as alterações feitas na API principal do Vulkan com revisão secundária 1.1 podem ser encontradas em Core Revisions (Vulkan 1.1) .

Escolha o suporte Vulkan

Os dispositivos Android devem suportar o conjunto de recursos Vulkan mais avançado disponível, desde que suportem ABI de 64 bits e não tenham pouca memória.

Dispositivos lançados com Android 13 e superior devem suportar Vulkan 1.3.

Os dispositivos lançados através do Android 10 devem suportar Vulkan 1.1.

Outros dispositivos podem suportar opcionalmente Vulkan 1.3, 1.2 e 1.1.

Suporta uma versão Vulkan

Um dispositivo Android suporta uma versão Vulkan se as seguintes condições forem atendidas:

1. Adicione um driver Vulkan que suporte a versão Vulkan de interesse (deve ser uma versão Vulkan 1.3, 1.1 ou 1.0) juntamente com os requisitos adicionais de CDD da versão Android. Como alternativa, atualize um driver Vulkan existente com um número de versão Vulkan inferior.
   Observação: para Android 14 e superior, todos os dispositivos compatíveis com Vulkan devem ter drivers Vulkan 1.1. Consulte os requisitos de CDD do Android 14 para obter mais informações.
2. Para Vulkan 1.3 ou 1.1, certifique-se de que o recurso do sistema retornado pelo gerenciador de pacotes retorne true para a versão correta do Vulkan.
   • Para Vulkan 1.3, o recurso é PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000) .
   • Para Vulkan 1.1, o recurso é PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000) .
   O gerenciador de pacotes retornará true para Vulkan 1.3 e Vulkan 1.1 adicionando uma regra, mostrada a seguir, a um arquivo device.mk apropriado.
   • Adicione o seguinte para 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 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
     

Observação: alguns aplicativos podem depender de uma versão Vulkan mais avançada do que a disponível em um dispositivo. Neste caso, esses aplicativos não serão executados no dispositivo. Por exemplo, aplicativos que exigem Vulkan 1.1 não serão executados em dispositivos que suportam apenas Vulkan 1.0. Alguns aplicativos podem não exigir uma versão mais recente do Vulkan, mas podem fornecer recursos adicionais ou melhor desempenho quando a versão mais recente estiver presente no dispositivo.

Perfil de base do Android (ABP)

Recomendamos que todos os dispositivos Android estejam em conformidade com o perfil Android Baseline 2022 mais recente, conforme descrito no guia do perfil Android Baseline .

Qualquer dispositivo compatível com Android 14 ou superior e a API Vulkan deve cumprir todas as funcionalidades definidas no perfil Android Baseline 2021 . A lista completa de funcionalidades necessárias é enumerada no arquivo json do perfil Vulkan, mas um subconjunto principal da funcionalidade necessária inclui:

• Texturas compactadas através de ASTC e ETC.
• Espaços de cores variáveis ​​por meio de VK_EXT_swapchain_colorspace .
• Amostra de sombreamento e interpolação multisample por meio de sampleRateShading .

Integração de sistema de janelas (WSI)

Em libvulkan.so , o driver implementa as seguintes extensões WSI (integração de sistema de janelas):

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

Os objetos VkSurfaceKHR e VkSwapchainKHR e todas as interações com ANativeWindow são manipulados pela plataforma e não são expostos aos drivers. A implementação do WSI depende da extensão VK_ANDROID_native_buffer , que deve ser suportada pelo driver; esta extensão é usada apenas pela implementação WSI e não é exposta a aplicativos.

Sinalizadores de uso Gralloc

As implementações do Vulkan podem precisar que buffers de swapchain sejam alocados com sinalizadores de uso Gralloc privados definidos pela implementação. Ao criar uma cadeia de troca, o Android pede ao driver para traduzir o formato solicitado e os sinalizadores de uso de imagem em sinalizadores de uso 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 obtidos da estrutura VkSwapchainCreateInfoKHR . O driver deve preencher *grallocConsumerUsage e *grallocProducerUsage com os sinalizadores de uso Gralloc necessários para o formato e uso. Os sinalizadores de uso retornados pelo driver são combinados com os sinalizadores 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 superior descontinuam vkGetSwapchainGrallocUsageANDROID() , mas ainda chama 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 sinalizadores de uso de swapchain ou sinalizadores de uso de Gralloc estendidos.

Imagens apoiadas por Gralloc

VkNativeBufferANDROID é uma estrutura de extensão vkCreateImage para criar uma imagem apoiada por um buffer Gralloc. VkNativeBufferANDROID é fornecido para vkCreateImage() na cadeia de estrutura VkImageCreateInfo . As chamadas para vkCreateImage() com VkNativeBufferANDROID acontecem durante a chamada para vkCreateSwapchainKHR . A implementação WSI aloca o número de buffers nativos solicitados para o swapchain 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 suportada por Gralloc, VkImageCreateInfo possui 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 superior, a plataforma fornece uma estrutura de extensão VkSwapchainImageCreateInfoKHR na cadeia VkImageCreateInfo fornecida a vkCreateImage quando qualquer sinalizador de uso de imagem de swapchain é necessário para o swapchain. A estrutura de extensão contém os sinalizadores de uso da imagem swapchain:

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

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

No Android 10 e superior, a plataforma suporta VK_KHR_swapchain v70, portanto, o aplicativo Vulkan é capaz de criar um VkImage apoiado pela memória swapchain. O aplicativo primeiro chama vkCreateImage com uma estrutura VkImageSwapchainCreateInfoKHR encadeada à estrutura VkImageCreateInfo . Em seguida, o aplicativo chama vkBindImageMemory2(KHR) com uma estrutura VkBindImageMemorySwapchainInfoKHR encadeada à estrutura VkBindImageMemoryInfo . O imageIndex especificado na estrutura VkBindImageMemorySwapchainInfoKHR deve ser um índice de imagem swapchain válido. Enquanto isso, a plataforma fornece uma estrutura de extensão VkNativeBufferANDROID com as informações de buffer Gralloc correspondentes para a cadeia VkBindImageMemoryInfo , para que o driver saiba com qual buffer Gralloc vincular o VkImage .

Adquirir imagens

vkAcquireImageANDROID adquire a propriedade de uma imagem swapchain e importa uma cerca nativa sinalizada externamente para um objeto VkSemaphore existente e um objeto VkFence existente:

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

vkAcquireImageANDROID() é chamado durante vkAcquireNextImageKHR para importar uma cerca nativa para os objetos VkSemaphore e VkFence fornecidos pelo aplicativo (no entanto, os objetos semáforo e cerca são opcionais nesta chamada). O driver também pode aproveitar esta oportunidade para reconhecer e tratar quaisquer alterações externas no estado do buffer Gralloc; muitos motoristas não precisarão fazer nada aqui. Essa chamada coloca VkSemaphore e VkFence no mesmo estado pendente como se fosse sinalizado por vkQueueSubmit , para que as filas possam esperar no semáforo e o aplicativo possa esperar em cima do muro.

Ambos os objetos são sinalizados quando a cerca nativa subjacente sinaliza; se a cerca nativa já tiver sinalizado, então o semáforo estará no estado sinalizado quando esta função retornar. O driver assume a propriedade do descritor do arquivo fence e fecha o descritor do arquivo fence quando não é mais necessário. O driver deve fazer isso mesmo que nenhum semáforo ou objeto fence seja fornecido, ou mesmo se vkAcquireImageANDROID falhar e retornar um erro. Se fenceFd for -1, é como se a cerca nativa já estivesse sinalizada.

Liberar imagens

vkQueueSignalReleaseImageANDROID prepara uma imagem swapchain para uso externo, cria uma cerca nativa e programa a cerca nativa para ser sinalizada após os semáforos de entrada terem sinalizado:

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

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

Se os semáforos de espera (se houver) já sinalizaram e queue já está ociosa, o driver pode definir *pNativeFenceFd como -1 em vez de um descritor de arquivo de cerca nativo real, indicando que não há nada pelo que esperar. O chamador possui 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 imagem externos. A preparação do conteúdo do buffer para uso por consumidores externos deve 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 deverá permitir que vkQueueSignalReleaseImageANDROID() seja chamado repetidamente sem a intervenção de chamadas para vkAcquireImageANDROID() .

Suporte compartilhado para imagem 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 posteriores, o carregador 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 suportar Vulkan 1.1 ou a extensão VK_KHR_physical_device_properties2 , o carregador não anunciará suporte para imagens apresentáveis ​​compartilhadas. 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 sua implementação Vulkan usando CTS, que inclui o seguinte:

• Testes de conformidade Khronos Vulkan no módulo CtsDeqpTestCases , que incluem testes funcionais de API 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 Vulkan que ele suporta.

Sinalizador de recurso Vulkan

Um dispositivo compatível com Android 11 ou superior e compatível com a API Vulkan é necessário para expor um sinalizador de recurso, android.software.vulkan.deqp.level . O valor deste sinalizador de recurso é uma data, codificada como um valor inteiro. Ele especifica a data associada aos testes Vulkan dEQP que o dispositivo afirma ter passado.

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

• Bits 0-15 armazenam o ano
• Os bits 16-23 armazenam o mês
• Bits 24-31 armazenam o dia

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

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

O valor 0x07E60301 corresponde à data 01/03/2022, que é a data associada aos testes Vulkan dEQP para Android 13. Se o sinalizador de recurso for pelo menos esse valor, o dispositivo afirma ter passado em todos os testes Vulkan dEQP do Android 13.

Um dispositivo que expõe um sinalizador de recurso específico ( ou seja , 0x07E30301 , 0x07E40301 , 0x07E60301 ) afirma passar em todos os testes Android Vulkan dEQP desse sinalizador de recurso (Android 10, Android 11, Android 13, respectivamente). Este dispositivo pode passar nos testes Vulkan dEQP de uma versão posterior do Android.

Vulkan dEQP faz parte do Android CTS. A partir do Android 11, o componente executor de testes dEQP do CTS está ciente do sinalizador de recurso android.software.vulkan.deqp.level e ignora quaisquer testes Vulkan dEQP que, de acordo com esse sinalizador de recurso, o dispositivo não afirma oferecer suporte. Esses testes são relatados como sendo triviais.