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

Vulkan é uma sobrecarga de baixa API multiplataforma para 3D de alto desempenho gráficos. Como o OpenGL ES (GLES), O Vulkan fornece ferramentas para criar aplicativos gráficos em tempo real nos apps. As vantagens de usar o Vulkan incluem reduções no uso de CPU sobrecarga e suporte para a linguagem binário intermediário SPIR-V.

Para implementar o Vulkan, o dispositivo precisa incluir:

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

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

Carregador do Vulkan

O carregador do Vulkan platform/frameworks/native/vulkan é o interface principal entre apps Vulkan e o driver Vulkan de um dispositivo. O Vulkan O carregador está instalado em /system/lib[64]/libvulkan.so. O carregador fornece os principais pontos de entrada da API do Vulkan, os pontos de entrada das extensões exigidos pelo CDD do Android e muitas outras extensões opcionais. Janela As extensões de integração do sistema (WSI) são exportadas pelo carregador e principalmente implementado no carregador em vez de no driver. O carregador também oferece suporte enumerar e carregar camadas que podem expor mais extensões e interceptar chamadas de API principais a caminho do driver.

O NDK inclui uma biblioteca libvulkan.so de stub para criar links. A biblioteca exporta os mesmos símbolos que o carregador. Os apps chamam as funções exportada da biblioteca libvulkan.so real para inserir funções trampolim no carregador, que as enviam ao servidor camada ou driver com base no primeiro argumento. O vkGet*ProcAddr() call retorna os ponteiros da função para os quais os trampolins enviam (ou seja, ele chama diretamente para o código principal da API). Como chamar pela função ponteiros, em vez dos símbolos exportados, é mais eficiente, pois pula o trampolim e envia.

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

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

No Android 7.0 e versões mais recentes, a derivada hw_module_t do Vulkan encapsula um único struct hw_module_t. somente um driver é aceito, e a string constante HWVULKAN_DEVICE_0 é transmitido para open().

A derivada hw_device_t do Vulkan corresponde a um único compatível com vários dispositivos físicos. A A estrutura de hw_device_t pode se estender à exportação vkGetGlobalExtensionProperties(), vkCreateInstance() e vkGetInstanceProcAddr(). O carregador pode encontrar todos os outros 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 da motorista. O Android não inclui camadas na imagem do sistema. No entanto, podem incluir camadas no APK.

Ao usar camadas, lembre-se de que o modelo de segurança e as políticas do Android são muito diferentes das outras plataformas. Especificamente, o Android não permite carregar código externo em um processo não depurável na produção (sem acesso root) nem permite que códigos externos inspecionem ou controlem a integridade do processo memória, estado e assim por diante. Isso inclui a proibição de salvar arquivos de despejo traces e assim por diante para o disco para inspeção posterior. Somente as camadas entregues como parte do os apps não depuráveis são ativados em dispositivos de produção, e os drivers não podem fornecer funcionalidade que viola essas políticas.

Os casos de uso de camadas incluem:

Camadas de tempo de desenvolvimento: validação camadas e shims para ferramentas de rastreamento/criação de perfil/depuração não devem ser instaladas em a imagem do sistema dos dispositivos de produção. Camadas e paliativos de validação para as ferramentas de rastreamento/criação de perfil/depuração devem ser atualizáveis sem um sistema imagem. Desenvolvedores que querem usar um dessas camadas durante o desenvolvimento pode modificar o pacote do app, por exemplo, adicionando um arquivo ao diretório de bibliotecas nativas. engenheiros de IHV e OEMs que quer diagnosticar falhas no envio de aplicativos não modificáveis sejam considerados acesso a builds de não produção (com acesso root) da imagem do sistema, a menos que esses apps são depuráveis. Para mais informações, consulte as Camadas de validação da 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 versões dessas camadas para usar aplicativo apps diferentes que usam a mesma camada ainda podem usar versões diferentes. Os desenvolvedores escolhem quais dessas camadas enviar em suas do pacote do app.
Camadas injetadas (implícitas): inclui camadas como: sobreposições de frame rate, rede social e inicializador do jogo fornecidas pelo usuário ou algum outro app sem o conhecimento ou consentimento dele. Esses violam as políticas de segurança do Android e não têm suporte.

Para aplicativos não depuráveis, o carregador procura camadas somente no do diretório da biblioteca nativa do app e tenta carregar qualquer biblioteca com um nome correspondentes 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 correspondente de acordo com um padrão específico.

O Android permite a portabilidade de camadas com mudanças de ambiente de build entre Android e outras plataformas. Para mais detalhes sobre a interface entre as camadas e a carregador, consulte Arquitetura das interfaces do carregador do Vulkan. A administração do Khronos as camadas de validação são hospedadas Camadas de validação da Vulkan.

Versões e recursos da API do Vulkan

A tabela abaixo 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
No Android 7	Vulkan versão 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 a interface de programação do Vulkan. As instâncias de passagem de renderização de passagem única não precisam mais para renderizar objetos de passagem ou framebuffers. o número total de objetos de estado do pipeline pode ser reduzido; na API é revisada. O Vulkan 1.3 tem os mesmos requisitos de hardware do 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 no framework.

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

Compatibilidade com instâncias de passagem de renderização de passagem única
Suporte ao encerramento imediato de uma invocação de sombreador
Mais granularidade para criação, compartilhamento e controle de pipelines

O Vulkan 1.3 também inclui vários recursos menores e melhorias de usabilidade da API. Todas as alterações feitas na API principal do Vulkan com uma pequena revisão 1.3, pode ser encontrada 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 informações adicionais que podem ser consultadas em um driver de dispositivo. O Vulkan 1.2 tem os mesmos requisitos de hardware que o Vulkan 1.0 e 1.1. todas as implementação está no driver gráfico específico do SoC, não no framework.

O recurso mais importante do Vulkan 1.2 para Android é o suporte a 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 uma pequena revisão 1.2, pode ser encontrada em Revisões principais (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, que é permite que OEMs ofereçam suporte ao Vulkan 1.1 em dispositivos. Além disso, a interoperabilidade de memória/sincronização permite que os desenvolvedores para determinar se um dispositivo oferece suporte ao Vulkan 1.1 e usá-lo de maneira eficaz quando ele for usado. O Vulkan 1.1 tem os mesmos requisitos de hardware que o Vulkan 1.0, mas a maioria implementação está no driver gráfico específico do SOC, não no framework.

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 sincronização objetos de 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 alterações feitas na API principal do Vulkan com a revisão 1.1 secundária, pode ser encontrada em Revisões principais (Vulkan 1.1).

Escolher o suporte ao Vulkan

Os dispositivos Android precisam ser compatíveis com o conjunto de recursos mais avançado do Vulkan disponível, desde que oferecem suporte a ABI de 64 bits e não têm 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 lançados até o Android 10 precisam oferecer suporte ao Vulkan 1.1.

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

Oferecer 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:

Adicionar um driver do Vulkan com suporte à versão do Vulkan de interesse (precisa ser uma das versões do Vulkan) 1.3, 1.1 ou 1.0) junto com os requisitos de CDD adicionais dos Versão do Android. Como alternativa, atualize um driver do Vulkan com um número de versão anterior do Vulkan.
Observação:no Android 14 e versões mais recentes, Os dispositivos compatíveis com Vulkan precisam ter drivers Vulkan 1.1. Confira o Android 14 Requisitos do CDD para mais informações informações.
Para o Vulkan 1.3 ou 1.1, verifique se o recurso do sistema retornado pelo gerenciador de pacotes retorna true para a versão vulkan correta.
- 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, para um arquivo device.mk apropriado.
- 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)

Incentivamos todos os dispositivos Android a seguir o perfil de referência do Android 2022 mais recente descritos na Guia do perfil de referência do Android.

Qualquer dispositivo com suporte ao Android 14 ou mais recente e à API Vulkan precisa que cumprem todas as funcionalidades definidas Perfil de referência do Android 2021. A lista completa das funcionalidades necessárias está enumerados no arquivo de perfil json do Vulkan, mas um subconjunto importante dos elementos funcionalidade inclui:

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

Integração do sistema de janela (WSI)

No libvulkan.so, o driver implementa o seguinte: extensões de integração do 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 em Somente Android 10
VK_GOOGLE_display_timing, implementado para qualquer versão do Vulkan no Android 10

Os objetos VkSurfaceKHR e VkSwapchainKHR e todos os as interações com ANativeWindow são processadas pela plataforma e não são aos motoristas. A implementação da WSI depende das VK_ANDROID_native_buffer, que precisa ser compatível com o driver. esta extensão é usada somente pela implementação da WSI e não é exposta a apps.

Sinalizações de uso do Gralloc

As implementações do Vulkan podem precisar que buffers de cadeia de troca sejam alocados com sinalizações de uso particulares definidas pela implementação do Gralloc. Ao criar uma cadeia de troca, O Android pede para o motorista traduzir o formato e o uso da imagem solicitados para 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 recebidos a estrutura VkSwapchainCreateInfoKHR. O motorista precisa preencher *grallocConsumerUsage e *grallocProducerUsage com as sinalizações de uso do Gralloc necessárias para o formato e o uso da infraestrutura. As sinalizações de uso retornadas pelo driver são combinadas com o uso sinalizações solicitadas pelo consumidor da cadeia de troca ao alocar buffers.

O Android 7.x chama uma versão anterior de VkSwapchainImageUsageFlagsANDROID(), chamado vkGetSwapchainGrallocUsageANDROID(). O Android 8.0 e versões mais recentes foram descontinuados. vkGetSwapchainGrallocUsageANDROID(), mas ainda faz chamadas vkGetSwapchainGrallocUsageANDROID() se O valor de vkGetSwapchainGrallocUsage2ANDROID() não é fornecido pelo motorista:

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

O vkGetSwapchainGrallocUsageANDROID() não é compatível com o uso de cadeia de troca ou flags de uso estendidas do Gralloc.

Imagens apoiadas por Gralloc

VkNativeBufferANDROID é uma extensão do vkCreateImage para criar uma imagem com o suporte de um buffer Gralloc. VkNativeBufferANDROID é fornecido a vkCreateImage() em VkImageCreateInfo em cadeia de estrutura. As ligações para vkCreateImage() com VkNativeBufferANDROID são realizadas 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 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 em versões mais recentes, a plataforma oferece uma Estrutura de extensão VkSwapchainImageCreateInfoKHR na VkImageCreateInfo rede foi fornecida para vkCreateImage quando alguma sinalização de uso da imagem da cadeia de troca for necessária para ela. A estrutura da extensão contém as sinalizações de uso da 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 em versões mais recentes, VK_KHR_swapchain v70, para que o app Vulkan possa criar um VkImage apoiado pela memória de cadeia de troca. Primeiro, o app chama vkCreateImage com um VkImageSwapchainCreateInfoKHR encadeada à estrutura VkImageCreateInfo. Depois, o app chama vkBindImageMemory2(KHR) com uma Estrutura VkBindImageMemorySwapchainInfoKHR encadeada ao VkBindImageMemoryInfo. O imageIndex especificado na estrutura VkBindImageMemorySwapchainInfoKHR precisa ser um índice de imagem de cadeia de troca válido. Enquanto isso, a plataforma oferece estrutura de extensão VkNativeBufferANDROID com a Informações do buffer do Gralloc para a cadeia VkBindImageMemoryInfo. o driver sabe com qual buffer do Gralloc vincular o VkImage.

Adquirir imagens

vkAcquireImageANDROID adquire a propriedade de uma imagem de cadeia de troca e importa uma fronteira nativa sinalizada externamente para uma entrada Objeto VkSemaphore e um objeto VkFence atual:

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

vkAcquireImageANDROID() é chamado durante vkAcquireNextImageKHR para importar um fronteira nativa entre os objetos VkSemaphore e VkFence fornecidos pelo aplicativo (no entanto, os objetos semáforo e de cerca são (opcional nesta chamada). O motorista também pode usar essa oportunidade para reconhecer e processar alterações externas no estado do buffer do Gralloc. muitos motoristas não vão não é preciso fazer nada. 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 aguardar no isolamento.

Ambos os objetos são sinalizados quando a cerca nativa subjacente sinaliza se a cerca nativa já sinalizou, o semáforo está na área quando a função retornar. O motorista assume a propriedade do arquivo da cerca descritor e fecha o descritor de arquivo de limite quando não é mais necessário. O motorista deverá fazer isso mesmo se não for fornecido um objeto semântico ou de limite, ou mesmo se vkAcquireImageANDROID falha e retorna um erro. Se fenceFd é -1, é como se a cerca nativa já estivesse sinalizou.

Imagens da versão

vkQueueSignalReleaseImageANDROID prepara uma imagem de cadeia de troca para uso externo, cria uma cerca nativa e programa a cerca nativa para ser sinalizada depois os semáforos de entrada sinalizaram:

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

vkQueuePresentKHR() chama vkQueueSignalReleaseImageANDROID() na fila fornecida. O motorista precisa produzir uma cerca nativa que não sinalize até que todos os waitSemaphoreCount semáforos em pWaitSemaphores e qualquer trabalho adicional necessário para prepare image para a apresentação completa.

Se os semáforos de espera (se houver) já estiverem sinalizados, e queue for já estiver inativo, o motorista poderá definir *pNativeFenceFd como -1 em vez de um descritor de arquivo de limite nativo, indicando que não há nada pelo que esperar. 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 talvez precisem ser preparados Estruturas de dados do lado da CPU associadas a um buffer Gralloc para uso por consumidores de imagens. A preparação do conteúdo do buffer para uso por consumidores externos 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 VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, o motorista precisará permitir que vkQueueSignalReleaseImageANDROID() seja chamado repetidamente sem intervir em chamadas para vkAcquireImageANDROID().

Suporte a imagens apresentáveis compartilhadas

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 carregador anuncia condicionalmente a Extensão VK_KHR_shared_presentable_image com base na uma resposta a uma chamada para vkGetPhysicalDeviceProperties2.

Se o driver não oferecer suporte ao Vulkan 1.1 ou ao 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 incluir a seguinte estrutura no VkPhysicalDeviceProperties2::pNext cadeia:

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

Se o motorista puder compartilhar a propriedade de uma imagem com a tela sistema, ele define 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 com a 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á configuradas corretamente para os recursos do Vulkan com que ele oferece suporte.

Sinalização de recurso do Vulkan

Um dispositivo com suporte ao Android 11 ou mais recente e à API Vulkan para expor uma flag de recurso, android.software.vulkan.deqp.level: O valor dessa flag de recurso é uma data, codificada como um valor inteiro. Ele especifica a data associada ao os testes de dEQP do Vulkan 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:

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

O valor mínimo permitido para a flag de recurso é 0x07E30301, correspondente à data 2019-03-01, que é a data associada ao Testes dEQP do Vulkan para o Android 10. Se a flag de recurso for pelo menos esse valor, O dispositivo afirma ser aprovado em todos os testes de dEQP do Vulkan do Android 10.

O valor 0x07E40301 corresponde à data 01/03/2020, que é a data associada aos testes de dEQP do Vulkan para o Android 11. Se o recurso tem pelo menos esse valor, o dispositivo declara que transmite todos os Testes dEQP do Vulkan.

O valor 0x07E60301 corresponde à data 01/03/2022, que é a data associada aos testes de dEQP do Vulkan para Android 13 Se a flag de recurso for pelo menos esse valor, O dispositivo afirma passar por todo o Vulkan do Android 13 Testes de dEQP.

Um dispositivo que expõe uma flag de recurso específica (ou seja, link em inglês) 0x07E30301, 0x07E40301 e 0x07E60301). afirma passar em todos os testes dEQP do Vulkan do Android dessa flag de recurso (Android 10, Android 11 e Android 13, respectivamente). Este dispositivo pode ser aprovado em testes de dEQP do Vulkan de uma versão mais recente do Android.

O dEQP do Vulkan faz parte do Android CTS. No Android 11, o executor de testes dEQP o componente do CTS reconhece a classe android.software.vulkan.deqp.level flag de recurso e ignora todos os testes de dEQP do Vulkan que, de acordo com esse flag de recurso - o dispositivo não alega ser compatível. Esses testes são relatadas como erros triviais.