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.

Sign up for GitHub

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

Jump to bottom

vkCmdSetCheckpointNV should allow a value of 0 for the checkpoint marker #702

Closed
tlf30 opened this issue Dec 9, 2021 · 2 comments
Closed

vkCmdSetCheckpointNV should allow a value of 0 for the checkpoint marker #702

tlf30 opened this issue Dec 9, 2021 · 2 comments
Labels
Type: Bug

Comments

@tlf30
Copy link
Contributor

tlf30 commented Dec 9, 2021 •
edited
Loading

Version

3.3.0 (nightly)

Platform

Windows x64

JDK

Adoptium 17

Module

Vulkan

Bug description

NVDeviceDiagnosticCheckpoints.vkCmdSetCheckpointNV(VkCommandBuffer commandBuffer, @NativeType("void const *") long pCheckpointMarker) should allow for the value 0L as the pCheckpointMarker as this is a user provided pointer that is passed back to the user. It can be useful to pass a 0L as the pCheckpointMarker, especially when the pCheckpointMarker is representing an index in a list of markers.

See: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCmdSetCheckpointNV.html

Thanks,
Trevor

Stacktrace or crash log output

java.lang.NullPointerException
	at org.lwjgl.system.Checks.check(Checks.java:188)
	at org.lwjgl.vulkan.NVDeviceDiagnosticCheckpoints.vkCmdSetCheckpointNV(NVDeviceDiagnosticCheckpoints.java:129)
	at io.tlf.outside.client.plugins.vk.renderer.vk12.Vk12Util.debugCommandBuffer(Vk12Util.java:64)
Spasi added a commit to Spasi/lwjgl3 that referenced this issue Dec 16, 2021
@Spasi
fix(Vulkan): always respect noautovalidity property. Close LWJGL#702
d9d95ad 
Not happy with this fix, since it's obviously wrong in a few places
(e.g. the first three VkAllocationCallbacks function pointers).

LWJGL uses the "optional" property to mark parameters/members as
nullable, but it is missing in cases like the one reported with LWJGL#702.
However, "noautovalidity" is consistent and LWJGL now interprets it
literally and does not perform any kind of validation, including
nullability. This may be reverted if the Vulkan-Docs situation changes
in the future.
Spasi added a commit to Spasi/lwjgl3 that referenced this issue Dec 20, 2021
@Spasi
fix(Vulkan): always respect noautovalidity property. Close LWJGL#702
3eb2b82 
Not happy with this fix, since it's obviously wrong in a few places
(e.g. the first three VkAllocationCallbacks function pointers).

LWJGL uses the "optional" property to mark parameters/members as
nullable, but it is missing in cases like the one reported with LWJGL#702.
However, "noautovalidity" is consistent and LWJGL now interprets it
literally and does not perform any kind of validation, including
nullability. This may be reverted if the Vulkan-Docs situation changes
in the future.
Spasi added a commit to Spasi/lwjgl3 that referenced this issue Dec 20, 2021
@Spasi
fix(Vulkan): always respect noautovalidity property. Close LWJGL#702
be42cc8 
Not happy with this fix, since it's obviously wrong in a few places
(e.g. the first three VkAllocationCallbacks function pointers).

LWJGL uses the "optional" property to mark parameters/members as
nullable, but it is missing in cases like the one reported with LWJGL#702.
However, "noautovalidity" is consistent and LWJGL now interprets it
literally and does not perform any kind of validation, including
nullability. This may be reverted if the Vulkan-Docs situation changes
in the future.
Spasi added a commit to Spasi/lwjgl3 that referenced this issue Dec 20, 2021
@Spasi
fix(Vulkan): always respect noautovalidity property. Close LWJGL#702
2120eaa 
Not happy with this fix, since it's obviously wrong in a few places
(e.g. the first three VkAllocationCallbacks function pointers).

LWJGL uses the "optional" property to mark parameters/members as
nullable, but it is missing in cases like the one reported with LWJGL#702.
However, "noautovalidity" is consistent and LWJGL now interprets it
literally and does not perform any kind of validation, including
nullability. This may be reverted if the Vulkan-Docs situation changes
in the future.
@Spasi Spasi closed this as completed in 7de4041 Dec 24, 2021
@Spasi
Copy link
Member

Spasi commented Dec 24, 2021

Thanks @tlf30, will be fixed in the next snapshot!

@tlf30
Copy link
Contributor Author

tlf30 commented Dec 24, 2021

Thank you @Spasi, that fix has a wide impact, but I did not see anything that would cause an immediate issues. It is unfortunate that there are errors in the vulkan spec on things like this.

Great job and thanks for all your hard work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Spasi @tlf30