Results 1 to 8 of 8

Thread: Descriptor pool able to allocate even though pool should be empty

  1. #1
    Junior Member
    Join Date
    Sep 2017
    Posts
    5

    Descriptor pool able to allocate even though pool should be empty

    Hey folks, I am currently writing a small descriptor pool allocator, though I noticed that even with completely empty descriptor pools, the application still is able to allocate descriptors from this pool.

    Anyone have an idea on what could be causing this behaviour?

    The validation layers are enabled, I am using the CPP Vulkan wrapper with built-in exception handling and none of this triggers on creation.


    Code :
    std::array<vk::DescriptorPoolSize, 3> type_count;
     
    	// Initialize our pool with these values
    	type_count[0].type = vk::DescriptorType::eCombinedImageSampler;
    	type_count[0].descriptorCount = 0;
     
    	type_count[1].type = vk::DescriptorType::eSampler;
    	type_count[1].descriptorCount = 0;
     
    	type_count[2].type = vk::DescriptorType::eUniformBuffer;
    	type_count[2].descriptorCount = 0;
     
     
     
    	vk::DescriptorPoolCreateInfo createInfo = vk::DescriptorPoolCreateInfo()
    		.setPNext(nullptr)
    		.setMaxSets(iMaxSets)
    		.setPoolSizeCount(type_count.size())
    		.setPPoolSizes(type_count.data());
    	pool = aDevice.createDescriptorPool(createInfo);

    Code :
    vk::DescriptorSetAllocateInfo alloc_info[1] = {};
    	alloc_info[0].pNext = NULL;
    	alloc_info[0].setDescriptorPool(pool);
    	alloc_info[0].setDescriptorSetCount(iNumToAllocate);
    	alloc_info[0].setPSetLayouts(&iDescriptorLayouts);
     
    	std::vector<vk::DescriptorSet> tDescriptors;
    	tDescriptors.resize(iNumToAllocate);
     
    	iDevice.allocateDescriptorSets(alloc_info, tDescriptors.data());

  2. #2
    Senior Member
    Join Date
    Mar 2016
    Posts
    227
    Well, it is a validation layer domain. descriptorCount = 0 is invalid usage.
    Either the layers are incomplete, or you have them configured incorrectly.

  3. #3
    Senior Member
    Join Date
    Mar 2016
    Posts
    227
    UPDATE: Yeah, it is incomplete layer. Easy enough; I will whip up a patch. Hopefully it will be in next SDK release.

  4. #4
    Junior Member
    Join Date
    Sep 2017
    Posts
    5
    Quote Originally Posted by krOoze View Post
    UPDATE: Yeah, it is incomplete layer. Easy enough; I will whip up a patch. Hopefully it will be in next SDK release.
    Not only does the layer not catch up on this, the descriptor pool allows allocation even when resources are not specified. I am thinking this might be a driver bug as well, I also posted something on the nvidia vulkan forums. Since it should be illegal behaviour to allocate descriptors from a heap which does not support these descriptors.

    Especially because the API does not throw any error, not even access errors. Which may be the charm of Vulkan, but still it sounds like something that should not happen. Thanks a lot though!
    Last edited by Mercesa; 09-27-2017 at 11:06 AM.

  5. #5
    Senior Member
    Join Date
    Mar 2016
    Posts
    227
    Alright PR is up. The user should get validation error on 0 descriptorCount or maxSets (probably) in the next SDK release.

    Quote Originally Posted by Mercesa View Post
    Not only does the layer not catch up on this, the descriptor pool allows allocation even when resources are not specified. I am thinking this might be a driver bug as well, I also posted something on the nvidia vulkan forums. Since it should be illegal behaviour to allocate descriptors from a heap which does not support these descriptors.

    Especially because the API does not throw any error, not even access errors. Which may be the charm of Vulkan, but still it sounds like something that should not happen. Thanks a lot though!
    TBH the spec itself does seem very specific about it. It is only natural that weird driver implementations follow.
    Maybe some Issue should be written there too.

  6. #6
    Senior Member
    Join Date
    Mar 2016
    Posts
    227
    TBH the spec itself does seem very specific about it. It is only natural that weird driver implementations follow.
    Maybe some Issue should be written there too.
    Correction: the core spec (You have to read that one specifically due to the Issue 533) says in the VUs that you need to account the allocations yourself. Allocating more than available in the pool is invalid usage and the validation layers seem to report those problems to me (do you have them properly enabled?)

    The VK_KHR_maintenance1 extension seems to remove those restrictions and replace them with VK_ERROR_OUT_OF_POOL_MEMORY_KHR VkResult.

  7. #7
    Junior Member
    Join Date
    Sep 2017
    Posts
    5
    My apologies for the very late response, I have been very busy. You are right, disabling this extension does give me an error now due to the layer picking up on it.

    Do you propose I keep track of the memory myself and enable VK_KHR_maintenance1 extension? What would be best practice here?

  8. #8
    Senior Member
    Join Date
    Mar 2016
    Posts
    227
    I get similar (lack) of errors, or crashes for some parameter combinations on AMD too with VK_KHR_maintenance1.

    So considering that, and also that generally extensions are not universally supported, I would stick with vanilla Vulkan in this aspect.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean