if they just change the readme
Specifically here
ash::vk::XlibSurfaceCreateInfoKHR field dpy shouldn't be pointer to pointer
in
xlib.h Display is typedef to structure type
not pointer
Ralith does seem like a bug though, yeah
Ralith make a PR!
Here is how xcb defines it http://rtbo.github.io/rust-xcb/x11/xlib/enum._XDisplay.html
But it is a real struct in practice https://code.woboq.org/qt5/include/X11/Xlibint.h.html#_XDisplay So what do you think we should do here?
empty enum?
could someone help me with this? https://github.com/SaschaWillems/Vulkan/blob/master/examples/dynamicuniformbuffer/README.md#preparing-the-uniform-buffer-and-memory
i have a uniform vector which i store as a buffer later on
but i think it needs to be aligned right since i get these warnings later on " [ VUID-vkCmdBindDescriptorSets-pDynamicOffsets-01971 ] Object: VK_NULL_HANDLE (Type = 2) | vkCmdBindDescriptorSets(): pDynamicOffsets[0] is 8 but must be a multiple of device limit minUniformBufferOffsetAlignment 0x10. The Vulkan spec states: Each element of pDynamicOffsets which corresponds to a descriptor binding with type VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC must be a multiple of VkPhysicalDeviceLimits::minUniformBufferOffsetAlignment (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdBindDescriptorSets-pDynamicOffsets-01971)"
" [ UNASSIGNED-CoreValidation-DrawState-DescriptorSetNotUpdated ] Object
" [ UNASSIGNED-CoreValidation-DrawState-DescriptorSetNotUpdated ] Object
@MaikKlein i use align for the buffer creation but im not sure how to do it with a custom size https://github.com/gwihlidal/ash-nv-rt/blob/master/src/main.rs#L253
I think I have an example somewhere, I'll try to post it later today (currently at work)
Hi, I am thinking about writing a blas implementation that uses vulkan like opencl. I want to use vulkan since we have this library in rust and vulkan is more supported than opencl. I don't know vulkan well so I don't know if this is a good idea, do you think this could work?
@oezgurmakkurt I don't see anything bad about it. You could also have a look at https://github.com/flame/blis
Hello! I am having a weird issue were, when trying to call
I do put on correct offset on my
It really looks like I am droping the value from memory at some point but I can't find where.
In the same fashion, it warn me later that the buffer in the same writeDescriptor are not valid buffer and then it segfault in the function
updateDescriptorSets the validation layer screams at me that pDescriptorWrites[0].pBufferInfo[0].offset = some garbage (like 0x10cf27af8 which is obviously not my offset) which obviously doesn't respect the storage buffer alignement.I do put on correct offset on my
DescriptorBufferInfo that i pass to my WriteDescriptorSet, and they seem to be valid until the call to device.update_descriptor_sets (at least thats what some println! tell me).It really looks like I am droping the value from memory at some point but I can't find where.
In the same fashion, it warn me later that the buffer in the same writeDescriptor are not valid buffer and then it segfault in the function
I uploaded a version that reproduce the bug to https://github.com/maeln/wyzoid
Ralith for example
I replaced most of the
Vec<T> in your lib with FromIterator<T> + DerefMut<Target = [T]>. That way the only structs that implicitly allocate are Entry and InstanceError.
That makes the lib way more flexible, allowing user defined collections
That way one may use
ArrayVec, for example, to allocate a known number of elements without needing the heap
If you want to take a look: https://github.com/nicbn/ash/tree/no-more-vec
May I pr?
An alternative to avoid allocations is passing mutable slices as parameters. From reading the readme I think that's not prefered, but if it is, I may rewrite it that way.