!dSLljtUMNpdwwnkjGq:matrix.org

Portable Graphics in Rust

310 Members
https://community.mozilla.org/groups/rust-portable-graphics/39 Servers

Load older messages

SenderMessageTime
13 May 2021
@kvark:matrix.orgkvarkI thought about simplifying this, and the only idea I got is to skip the pipeline layout stage, and store a hashmap(group, binding) to buffer size in the command encoder state. This would potentially be a tiny bit slower, since hashmap lookups are slower than areay indexing, but unclear how much.18:50:43
@kvark:matrix.orgkvarkAnother approach - make the contents of the sizes buffer dependent on pipeline layout only, and nothing else. Thix would avoid the need to re-map it to the pipeline, but would potentially have larger buffers with mire stages than necessary...18:52:50
@kvark:matrix.orgkvarkNeither is a clear win18:53:04
@uniformbuffer3:matrix.orgUniformbuffer

i was testing and fixing some problems notified by the vulkan validation layer when i have found this:

VUID-vkDestroyInstance-instance-00629(ERROR / SPEC): msgNum: -1958900200 - Validation Error: [ VUID-vkDestroyInstance-instance-00629 ] Object 0: handle = 0x563c0a883fa0, type = VK_OBJECT_TYPE_INSTANCE; Object 1: handle = 0x20000000002, type = VK_OBJECT_TYPE_DISPLAY_KHR; | MessageID = 0x8b3d8e18 | OBJ ERROR : For VkInstance 0x563c0a883fa0[], VkDisplayKHR 0x20000000002[] has not been destroyed. The Vulkan spec states: All child objects created using instance must have been destroyed prior to destroying instance (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkDestroyInstance-instance-00629)
    Objects: 2
        [0] 0x563c0a883fa0, type: 1, name: NULL
        [1] 0x20000000002, type: 1000002000, name: NULL

This error claims that i have not destroyed the VkDisplayKHR object before the instance.... and it is true... because the function to destroy it does not exist 🤔.
Indeed the display is not created using something like "VkCreateDisplayKHR", but it is gathered using vkGetPhysicalDeviceDisplayPropertiesKHR that it is not a create function, so there is no a destroy one. Should i ignore this error?(the image is drawed correctly on the screen)

23:37:23
@uniformbuffer3:matrix.orgUniformbuffer *

i was testing and fixing some problems notified by the vulkan validation layer when i have found this:

VUID-vkDestroyInstance-instance-00629(ERROR / SPEC): msgNum: -1958900200 - Validation Error: [ VUID-vkDestroyInstance-instance-00629 ] Object 0: handle = 0x563c0a883fa0, type = VK_OBJECT_TYPE_INSTANCE; Object 1: handle = 0x20000000002, type = VK_OBJECT_TYPE_DISPLAY_KHR; | MessageID = 0x8b3d8e18 | OBJ ERROR : For VkInstance 0x563c0a883fa0[], VkDisplayKHR 0x20000000002[] has not been destroyed. The Vulkan spec states: All child objects created using instance must have been destroyed prior to destroying instance (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkDestroyInstance-instance-00629)
    Objects: 2
        [0] 0x563c0a883fa0, type: 1, name: NULL
        [1] 0x20000000002, type: 1000002000, name: NULL

This error claims that i have not destroyed the VkDisplayKHR object before the instance.... and it is true... because the function to destroy it does not exist 🤔.
Indeed the display is not created using something like "VkCreateDisplayKHR", but it is gathered using vkGetPhysicalDeviceDisplayPropertiesKHR that it is not a create function, so there is no destroy one. Should i ignore this error (the image is drawed correctly on the screen)?

23:38:17
@uniformbuffer3:matrix.orgUniformbuffer *

i was testing and fixing some problems notified by the vulkan validation layer when i have found this:

VUID-vkDestroyInstance-instance-00629(ERROR / SPEC): msgNum: -1958900200 - Validation Error: [ VUID-vkDestroyInstance-instance-00629 ] Object 0: handle = 0x563c0a883fa0, type = VK_OBJECT_TYPE_INSTANCE; Object 1: handle = 0x20000000002, type = VK_OBJECT_TYPE_DISPLAY_KHR; | MessageID = 0x8b3d8e18 | OBJ ERROR : For VkInstance 0x563c0a883fa0[], VkDisplayKHR 0x20000000002[] has not been destroyed. The Vulkan spec states: All child objects created using instance must have been destroyed prior to destroying instance (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkDestroyInstance-instance-00629)
    Objects: 2
        [0] 0x563c0a883fa0, type: 1, name: NULL
        [1] 0x20000000002, type: 1000002000, name: NULL

This error claims that i have not destroyed the VkDisplayKHR object before the instance.... and it is true... because the function to destroy it does not exist 🤔.
Indeed the display is not created using something like "VkCreateDisplayKHR", but it is gathered using vkGetPhysicalDeviceDisplayPropertiesKHR that it is not a create function, so there is no a destroy one. Should i ignore this error (the image is drawed correctly on the screen)?

23:40:50
@uniformbuffer3:matrix.orgUniformbuffer *

i was testing and fixing some problems notified by the vulkan validation layer when i have found this:

VUID-vkDestroyInstance-instance-00629(ERROR / SPEC): msgNum: -1958900200 - Validation Error: [ VUID-vkDestroyInstance-instance-00629 ] Object 0: handle = 0x563c0a883fa0, type = VK_OBJECT_TYPE_INSTANCE; Object 1: handle = 0x20000000002, type = VK_OBJECT_TYPE_DISPLAY_KHR; | MessageID = 0x8b3d8e18 | OBJ ERROR : For VkInstance 0x563c0a883fa0[], VkDisplayKHR 0x20000000002[] has not been destroyed. The Vulkan spec states: All child objects created using instance must have been destroyed prior to destroying instance (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkDestroyInstance-instance-00629)
    Objects: 2
        [0] 0x563c0a883fa0, type: 1, name: NULL
        [1] 0x20000000002, type: 1000002000, name: NULL

This error claims that i have not destroyed the VkDisplayKHR object before the instance.... and it is true... because the function to destroy it does not exist 🤔.
Indeed the display is not created using something like "VkCreateDisplayKHR", but it is gathered using vkGetPhysicalDeviceDisplayPropertiesKHR that it is not a create function, so there is no a destroy one. Should i ignore this error?(the image is drawed correctly on the screen)

23:46:17
14 May 2021
@uniformbuffer3:matrix.orgUniformbuffer

i also got strange errors like:

[2021-05-13T23:54:02Z ERROR gfx_backend_vulkan] 
    VALIDATION [UNASSIGNED-Threading-Info (0x5d6b67e2)] : Validation Error: [ UNASSIGNED-Threading-Info ] Object 0: handle = 0x558cb9713d52, type = VK_OBJECT_TYPE_DISPLAY_KHR; | MessageID = 0x5d6b67e2 | Couldn't find VkDisplayKHR Object 0x558cb9713d52. This should not happen and may indicate a bug in the application.
    object info: (type: DISPLAY_KHR, hndl: 0x558cb9713d52)

saying object xxxx not found. I'm double checking all the handle addresses that i gather from vulkan and seems the handles refered in the validation errors does not exist. Effectively, if i was using wrong handle addresses for displays and modes, i'm pretty sure the driver would panic on functions calling, but instead it is working correctly. It is strange (and i'm very scared to say this because i'm usually the one in error), but maybe there is something wrong with the validation layer

00:01:13
@uniformbuffer3:matrix.orgUniformbufferstill i will continue to look for the error, i trust more the validation layer than myself 😄00:02:31
@uniformbuffer3:matrix.orgUniformbufferlooking on the validation layer git i have found an issue stating that if VK_KHR_display is used, the validation layer produce false positives. It has been merged in v1.2.148. My version is 1.2.141 , so i have to update the validation layers and check if error are still returned00:54:32
@kvark:matrix.orgkvarkGreat!01:05:44
@uniformbuffer3:matrix.orgUniformbufferok, i have downloaded the latest stable lunarg sdk and runned the quad example linked against the updated layers and it does throw the errors no more, so seems it was effectively a bug of the validation layer 😁01:54:00
@kvark:matrix.orgkvark groves: do you have the energy to look at https://github.com/gfx-rs/gfx/pull/3758 ? I imagine it's hard to review 03:24:58
@kvark:matrix.orgkvarkI can just proceed, but I thought if you were planning to look at it, we can and should wait03:25:30
@uniformbuffer3:matrix.orgUniformbuffer I was testing the VK_EXT_display_control extension implementation for display hotplug detection and the function to register the event listener with a fence returns VkResult::ERROR_FEATURE_NOT_PRESENT, that it is not among the possible outputs for that function. I suppose the driver implements the power control part of VK_EXT_display_control (that i have tested and it works), but not the hotplug event detection. Should i handle drivers's non-standard behaviours? 16:07:43
@uniformbuffer3:matrix.orgUniformbuffer this happening on intel vulkan driver. On every vulkan physical device enumeration i got MESA-INTEL: warning: Haswell Vulkan support is incomplete warning, so i suppose i should expect this kind of behaviours 16:08:36
@uniformbuffer3:matrix.orgUniformbuffer * I was testing the VK_EXT_display_control extension implementation for display hotplug detection and the function to register the event listener with a fence returns VkResult::ERROR_FEATURE_NOT_PRESENT, that it is not among the possible outputs for that function. I suppose the driver implements the power control part of VK_EXT_display_control (that i have tested and it works), but not the hotplug event detection. Should i handle drivers's non-standard behaviours? 16:09:50
@kvark:matrix.orgkvarkHmm, it happens sometimes with other vendors as well. Let's handle this16:32:22
@ralith:ralith.comRalithif the spec says it's possible, it must be handled16:49:16
@uniformbuffer3:matrix.orgUniformbuffer that's the problem, that function should only return (as error) VK_ERROR_OUT_OF_HOST_MEMORY (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkRegisterDeviceEventEXT.html). It is a driver specific way to handle that function. Still something trivial to handle, so it is not a problem 16:52:36
@uniformbuffer3:matrix.orgUniformbuffer
In reply to @ralith:ralith.com
if the spec says it's possible, it must be handled
* that's the problem, that function should only return (as error) VK_ERROR_OUT_OF_HOST_MEMORY. It is a driver specific way to handle that function. Still something trivial to handle, so that's not a problem 		16:53:02
@uniformbuffer3:matrix.orgUniformbuffer * that's the problem, that function should only return (as error) VK_ERROR_OUT_OF_HOST_MEMORY (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkRegisterDeviceEventEXT.html). It is a driver specific way to handle that function. Still something trivial to handle, so that's not a problem 16:53:43
@uniformbuffer3:matrix.orgUniformbuffer * that's the problem, that function should only return (as error) VK_ERROR_OUT_OF_HOST_MEMORY (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkRegisterDeviceEventEXT.html). It is a driver specific way to handle that function. Still something trivial to handle, so it is not a problem 16:54:37
@ralith:ralith.comRalithinteresting; bug report?17:14:36
@uniformbuffer3:matrix.orgUniformbufferi don't think it is a bug, but rather a decision. That extension provide other functionalities that they have implemented, so i suppose they have prefered to return that error on functions they does not support instead of not supporting the whole extension at all17:17:35
@uniformbuffer3:matrix.orgUniformbuffer * i don't think it is a bug, but rather a decision. That extension provide other functionalities that they have implemented, so i suppose they have prefered to return that error on functions they does not support instead of not supporting the whole extension at all17:17:57
@uniformbuffer3:matrix.orgUniformbufferStill non-standard, it can cause problem to very vulkan specific implementation. Abstracting the api, like Gfx does, allow to handle this kind of weird behaviours very easily ^^17:19:57
@uniformbuffer3:matrix.orgUniformbuffer * Still non-standard, it can cause problem to very vulkan specific implementation. Abstracting the api, like Gfx does, allow to handle this kind of weird behaviours very easily ^^17:20:20
@ralith:ralith.comRaliththere should be upstream bugs open for nonconformant behavior regardless of whether it's intentional17:23:07
15 May 2021
@therawmeatball:matrix.orgtherawmeatball joined the room.08:08:49

There are no newer messages yet.

Back to Room List