Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get_query_pool_results buggy when called with vk::QueryResultFlags::WITH_AVAILABILITY #639

Closed
matszczygiel opened this issue Jul 11, 2022 · 1 comment

Comments

@matszczygiel
Copy link

Hello,
I have a piece of code which according to my knowledge does not violate the Vulkan spec.

let first_query = 0;
let query_count = 2;
let flags = vk::QueryResultFlags::WITH_AVAILABILITY;
let mut data = [0u32; 4];
device.get_query_pool_results(
    query_pool,
    first_query,
    query_count,
    data.as_mut_slice(),
    flags,
)?;

This code gives a validation error:

[VK][Validation]"Validation Error: [ VUID-vkGetQueryPoolResults-dataSize-00817 ] Object 0: handle = 0x13105e0000000155, type = VK_OBJECT_TYPE_QUERY_POOL; | MessageID = 0x73375ed4 | vkGetQueryPoolResults() on querypool VkQueryPool 0x13105e0000000155[] specified dataSize 8 which is incompatible with the specified query type and options. The Vulkan spec states: dataSize must be large enough to contain the result of each query, as described here (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkGetQueryPoolResults-dataSize-00817)"

I managed to locate a bug in the implementation of this function. It passes query_count as a data length parameter forward. This is fine in most cases but here the flagvk::QueryResultFlags::WITH_AVAILABILITY requires the data to be twice as large as query_count.
I will open PR with a fix.

@MarijnS95
Copy link
Collaborator

MarijnS95 commented Feb 16, 2023

This ended up not requiring a fix but merely a simplified API since the type T of data: &[T] is used to determine the stride, where T = u32 for a WITH_AVAILABILITY query would overwrite the bool in query N-1 which was not addressed by the linked PR. Instead we now force the user to use slice length by removing the query_count parameter: #644

This is a breaking change that has not been released yet (will be part of Ash 0.38) but to achieve what you want now, make sure T includes the availability flag through a tuple via T = (0u32, vk::Bool32), and request a total of 2 instead of 4 queries:

let first_query = 0;
let flags = vk::QueryResultFlags::WITH_AVAILABILITY;
let mut data = [(0u32, vk::Bool32); 2];
device.get_query_pool_results(
    query_pool,
    first_query,
    data.len(),
    data.as_mut_slice(),
    flags,
)?;

This pattern remains in Ash 0.38, where only data.len() (= query count) should be removed from the call signature.

MarijnS95 added a commit that referenced this issue Feb 24, 2023
…y_pool_results()`

Commit c66db26 ("device: Replace `query_count` parameter in
`get_query_pool_results` with `data.len()` (#644)") removed this
parameter in favour of using `data.len()` to make it more obvious to use
an appropriate element type that matches the kind of request (see also
 #639) so that the stride is filled in correctly, but it was not
mentioned in the changelog yet.
MarijnS95 added a commit that referenced this issue Feb 24, 2023
…y_pool_results()` (#710)

Commit c66db26 ("device: Replace `query_count` parameter in
`get_query_pool_results` with `data.len()` (#644)") removed this
parameter in favour of using `data.len()` to make it more obvious to use
an appropriate element type that matches the kind of request (see also
 #639) so that the stride is filled in correctly, but it was not
mentioned in the changelog yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants