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
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.
- 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)
.
true
para o Vulkan 1.3 e o Vulkan 1.1 adicionando uma regra, mostrada a seguir, a um arquivodevice.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
- Para o Vulkan 1.3, o recurso é
- 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 10VK_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.