vulkan

I am in the middle of rendering different textures on multiple meshes of a model, but I do not have much clues about the procedures. Someone suggested for each mesh, create its own descriptor sets and call vkCmdBindDescriptorSets() and vkCmdDrawIndexed() for rendering like this: // Pipeline with descriptor set layout that matches the shared descriptor sets vkCmdBindPipeline(...pipelines.mesh...); ... // Mesh A vkCmdBindDescriptorSets(...&meshA.descriptorSet... ); vkCmdDrawIndexed(...); // Mesh B vkCmdBindDescriptorSets(...&meshB.descriptorSet... ); vkCmdDrawIndexed(...); However, the above

I had some experience with DirectX12 in the past and I don't remember something similar to render passes in Vulkan so I can't make an analogy. If I'm understanding correctly command buffers inside the same subpass doesn't need to be synchronized. So why to complicate and make multiple of them? Why can't I just take one command buffer and put all my frame related info there? Imagine that the GPU cannot render to images directly. Imagine that it can only render to special framebuffer memory storage, which is completely separate from regular image memory. You cannot talk to this framebuffer

In all of the create info structs ( vk*CreateInfo ) in the new Vulkan API, there is ALWAYS a .sType member. Why is this there if the value can only be one thing? Also the Vulkan specification is very explicit that you can only use vk*CreateInfo structs as parameters for their corresponding vkCreate* function. It seems a little redundant. I can see that if the driver was passing this struct straight to the GPU, you might need to have it (I did notice it is always the first member). But this seems like a really bad idea for the app to do it because if the driver did it, apps would be much less

随着新的一个月的开始，Valve公布了上个月的软件/硬件调查数据。在2019年5月，Steam Linux 的使用率按百分比略微上升。 上个月，运行Linux的Steam用户比例(根据有争议的Steam调查)上升到了0.84%，比4月份上升了0.02%。这一数字在很大程度上符合最近该地区约0.8%的预期，并且比去年有所上升。 自Valve去年推出Steam Play以来，Linux游戏市场的份额一直呈逐点增长的趋势。由于基于Wine的Proton和DXVK将Direct3D转换为Vulkan, Steam Play允许许多著名的Windows游戏在Linux上运行。但是没有任何Linux独家产品，Steam机器的回归或任何里程碑式的原因导致Windows游戏玩家突然转向Linux。结果，它每个月都是平缓或微小的增长。 5月份在Steam上使用Windows的比例为95.9％，而macOS为3.26％ 每月Steam调查数据可在SteamPowered.com上查看。 来源： oschina 链接： https://my.oschina.net/u/3008585/blog/3064905

The vec3 type is a very nice type. It only takes up 3 floats, and I have data that only needs 3 floats. And I want to use one in a structure in a UBO and/or SSBO: layout(std140) uniform UBO { vec4 data1; vec3 data2; float data3; }; layout(std430) buffer SSBO { vec4 data1; vec3 data2; float data3; }; Then, in my C or C++ code, I can do this to create matching data structures: struct UBO { vector4 data1; vector3 data2; float data3; }; struct SSBO { vector4 data1; vector3 data2; float data3; }; Is this a good idea? Nicol Bolas NO! Never do this! When declaring UBOs/SSBOs, pretend that all 3