He escrito un ejemplo de triángulo simple que funciona en mi máquina, pero recibí un informe de error donde el usuario no pudo ejecutar el ejemplo y obtuve el siguiente error de validación.

vkAcquireNextImageKHR: la aplicación ya ha adquirido el número máximo de imágenes (0x1) "thread 'main' en pánico en 'llamado Result::unwrap() en un valor Err: ErrorValidationFailedExt'

Creo imágenes minImageCount + 1 o maxImageCount en la cadena de intercambio.

Si tiene curiosidad por cómo presento las imágenes, puede verlo aquí. Y record_submit_commandbuffer si tienes curiosidad sobre cómo enviar las memorias intermedias de comando.

El usuario también informó que puede ejecutar ejemplos de SaschaWillems Vulkan, por lo que es muy probable que el error esté de mi lado.

La única diferencia que pude detectar es que ejemplos de SaschaWillems Vulkan crearían N buffers de comandos pregrabados donde N es el Número de imágenes en la cadena de intercambio.

VK_CHECK_RESULT(swapChain.acquireNextImage(presentCompleteSemaphore, &currentBuffer));

// Use a fence to wait until the command buffer has finished execution before using it again
VK_CHECK_RESULT(vkWaitForFences(device, 1, &waitFences[currentBuffer], VK_TRUE, UINT64_MAX));
VK_CHECK_RESULT(vkResetFences(device, 1, &waitFences[currentBuffer]));

Donde acabo de volver a grabar un nuevo búfer de comandos después de haber llamado acquireNextImage e inmediatamente espero en la cerca del búfer de comandos y luego llamo a queuePresent.

https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/xhtml/vkspec.html#vkAcquireNextImageKHR

Sea n el número total de imágenes en la cadena de intercambio, m sea el valor de VkSurfaceCapabilitiesKHR :: minImageCount, y sea el número de imágenes presentables que la aplicación ha adquirido actualmente (es decir, imágenes adquiridas con vkAcquireNextImageKHR, pero aún no presentadas con vkQueuePresentKHR) . vkAcquireNextImageKHR siempre puede tener éxito si a ≤ n - m en el momento en que se llama a vkAcquireNextImageKHR. vkAcquireNextImageKHR no debería llamarse si a> n - m con un tiempo de espera de UINT64_MAX; en tal caso, vkAcquireNextImageKHR puede bloquearse indefinidamente.

Entonces, en mi caso, sería a > (m + 1) - m => a > 1 Entonces, el error parece indicar que llamé a vkAcquireNextImageKHR demasiado pronto. Pero todavía no estoy muy seguro de por qué sucede esto.

En mi máquina no tengo problemas para ejecutar los ejemplos, ni obtengo ningún error de validación. También parece que estoy haciendo esencialmente lo mismo que ejemplos de SaschaWillems Vulkan

Además, si desea ejecutarlo usted mismo, requiere Rust y las capas de validación LunarG.

git clone https://github.com/MaikKlein/ash
cd examples
cargo run --bin triangle

Volcado de API para render_loop

3
Maik Klein 6 ene. 2017 a las 11:59

2 respuestas

La mejor respuesta

Tuve la oportunidad de reproducirlo en Linux (Ubuntu) Mesa13 Intel driver.

El controlador parece devolver basura en VkPresentInfoKHR::pResults.

Si le asigno null_mut, el programa comienza a funcionar sin problemas.

(Por cierto, su imagen de profundidad se crea como "escasa", lo que me pareció extraño).

2
krOoze 18 ene. 2017 a las 01:37

Es un error (aún no solucionado) en la capa de validación unique_objects. Todavía no se ha solucionado, por lo que todavía no hay una solución. Ticket: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/1670

Para solucionar ese error, puede:

A) Inicialice los valores de la matriz pResults con algo exitoso (como VK_RESULT_SUCCESS) y asegúrese de verificar también el valor devuelto por vkQueuePresentKHR() ya que este valor ya es válido. Esto funcionará cuando lo arreglen o no usará capas de validación, pero por ahora estos valores simplemente permanecerán como inicializados para que no moleste a otras capas de validación.

B) Pase nullptr como pResults. Esto no le permitirá inspeccionar resultados específicos por cadena de intercambio en el futuro cuando lo arreglen. Si solo tiene una cadena de intercambio, puede ser redundante verificar ambas de todos modos ... Aunque preferiría usar la solución (a).

3
RippeR 16 abr. 2017 a las 08:39