diff --git a/README.md b/README.md index bec6ca4..c72d5aa 100644 --- a/README.md +++ b/README.md @@ -3,13 +3,27 @@ Vulkan Flocking: compute and shading in one pipeline! **University of Pennsylvania, CIS 565: GPU Programming and Architecture, Project 6** -* (TODO) YOUR NAME HERE - Windows 22, i7-2222 @ 2.22GHz 22GB, GTX 222 222MB (Moore 2222 Lab) +* David Liao + Windows 7, i7-4770 @ 3.40GHz 16GB, NVIDIA Quadro K600 4GB (SIGLAB) - ### (TODO: Your README) +![](demo.gif) + +- Why do you think Vulkan expects explicit descriptors for things like generating pipelines and commands? HINT: this may relate to something in the comments about some components using pre-allocated GPU memory. + +Vulkan uses a memory pool that's preallocated and thus requires the developer to provide explicit descriptors to manage memory distribution. + +- Describe a situation besides flip-flop buffers in which you may need multiple descriptor sets to fit one descriptor layout. + +Basically whenever you have multiple sets of inputs that fit a single format. Maybe you might need to pass in multiple textures into a shader. + +- What are some problems to keep in mind when using multiple Vulkan queues? + +The issue with using multiple queues is if the processes are not independent of eachother, you'll run into race conditions. Other hardware considerations might include instruction set or apis that certain hardwares might support as well as the number of queues. + +- What is one advantage of using compute commands that can share data with a rendering pipeline? + +Since the memory is shared, there's very low cost in passing around data. - Include screenshots, analysis, etc. (Remember, this is public, so don't put - anything here that you don't want to share with the world.) ### Credits diff --git a/data/shaders/computeparticles/particle.comp b/data/shaders/computeparticles/particle.comp index b7dc2f7..67999c1 100644 --- a/data/shaders/computeparticles/particle.comp +++ b/data/shaders/computeparticles/particle.comp @@ -41,12 +41,44 @@ layout (binding = 2) uniform UBO int particleCount; } ubo; +vec2 computeVelocity(uint index) { + vec2 center = vec2(0.0f, 0.0f); + vec2 separate = vec2(0.0f, 0.0f); + vec2 cohesion = vec2(0.0f, 0.0f); + vec2 tVel = vec2(0.0f, 0.0f); + int neighborCount = 0; + int test = 0; + for (int i = 0; i < ubo.particleCount; i++) { + if (i == index) { + continue; + } + + float distance = distance(particlesA[index].pos, particlesA[i].pos); + if (distance < ubo.rule1Distance) { + center += particlesA[i].pos; + neighborCount++; + } + if (distance < ubo.rule2Distance) { + separate += particlesA[index].pos - particlesA[i].pos; + } + if (distance < ubo.rule3Distance) { + cohesion += particlesA[i].vel; + test++; + } + } + if (neighborCount > 0) { + center /= neighborCount; + tVel += (center - particlesA[index].pos) * ubo.rule1Scale; + } + tVel += separate * ubo.rule2Scale; + if (test > 0) { + tVel += cohesion * ubo.rule3Scale; + } + return tVel; +} + void main() { - // LOOK: This is very similar to a CUDA kernel. - // Right now, the compute shader only advects the particles with their - // velocity and handles wrap-around. - // TODO: implement flocking behavior. // Current SSBO index uint index = gl_GlobalInvocationID.x; @@ -54,21 +86,21 @@ void main() if (index >= ubo.particleCount) return; - // Read position and velocity - vec2 vPos = particlesA[index].pos.xy; vec2 vVel = particlesA[index].vel.xy; + vec2 vPos = particlesA[index].pos.xy; - // clamp velocity for a more pleasing simulation. - vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1); + vVel = computeVelocity(index); + // clamp velocity for a more pleasing simulation. + vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1); - // kinematic update - vPos += vVel * ubo.deltaT; + // kinematic update + vPos += vVel * ubo.deltaT; // Wrap around boundary - if (vPos.x < -1.0) vPos.x = 1.0; - if (vPos.x > 1.0) vPos.x = -1.0; - if (vPos.y < -1.0) vPos.y = 1.0; - if (vPos.y > 1.0) vPos.y = -1.0; + if (vPos.x < -1.0) vPos.x = 1.0; + if (vPos.x > 1.0) vPos.x = -1.0; + if (vPos.y < -1.0) vPos.y = 1.0; + if (vPos.y > 1.0) vPos.y = -1.0; particlesB[index].pos.xy = vPos; diff --git a/data/shaders/computeparticles/particle.comp.spv b/data/shaders/computeparticles/particle.comp.spv index 059ab59..a0b857e 100644 Binary files a/data/shaders/computeparticles/particle.comp.spv and b/data/shaders/computeparticles/particle.comp.spv differ diff --git a/demo.gif b/demo.gif new file mode 100644 index 0000000..d29f093 Binary files /dev/null and b/demo.gif differ diff --git a/vulkanBoids/vulkanBoids.cpp b/vulkanBoids/vulkanBoids.cpp index 9b2f122..7827c5c 100644 --- a/vulkanBoids/vulkanBoids.cpp +++ b/vulkanBoids/vulkanBoids.cpp @@ -36,9 +36,9 @@ #define RULE1DISTANCE 0.1f // cohesion #define RULE2DISTANCE 0.05f // separation #define RULE3DISTANCE 0.05f // alignment -#define RULE1SCALE 0.02f -#define RULE2SCALE 0.05f -#define RULE3SCALE 0.01f +#define RULE1SCALE 0.01f +#define RULE2SCALE 0.02f +#define RULE3SCALE 0.4f class VulkanExample : public VulkanExampleBase { @@ -157,6 +157,7 @@ class VulkanExample : public VulkanExampleBase for (auto& particle : particleBuffer) { particle.pos = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator)); + particle.vel = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator)) * 0.1f; // TODO: add randomized velocities with a slight scale here, something like 0.1f. } @@ -244,7 +245,7 @@ class VulkanExample : public VulkanExampleBase VERTEX_BUFFER_BIND_ID, 1, VK_FORMAT_R32G32_SFLOAT, - offsetof(Particle, pos)); // TODO: change this so that we can color the particles based on velocity. + offsetof(Particle, vel)); // TODO: change this so that we can color the particles based on velocity. // vertices.inputState encapsulates everything we need for these particular buffers to // interface with the graphics pipeline. @@ -540,13 +541,27 @@ class VulkanExample : public VulkanExampleBase compute.descriptorSets[0], VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER, 2, - &compute.uniformBuffer.descriptor) + &compute.uniformBuffer.descriptor), + + vkTools::initializers::writeDescriptorSet( + compute.descriptorSets[1], // LOOK: which descriptor set to write to? + VK_DESCRIPTOR_TYPE_STORAGE_BUFFER, + 0, // LOOK: which binding in the descriptor set Layout? + &compute.storageBufferB.descriptor), // LOOK: which SSBO? - // TODO: write the second descriptorSet, using the top for reference. - // We want the descriptorSets to be used for flip-flopping: - // on one frame, we use one descriptorSet with the compute pass, - // on the next frame, we use the other. - // What has to be different about how the second descriptorSet is written here? + // Binding 1 : Particle position storage buffer + vkTools::initializers::writeDescriptorSet( + compute.descriptorSets[1], + VK_DESCRIPTOR_TYPE_STORAGE_BUFFER, + 1, + &compute.storageBufferA.descriptor), + + // Binding 2 : Uniform buffer + vkTools::initializers::writeDescriptorSet( + compute.descriptorSets[1], + VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER, + 2, + &compute.uniformBuffer.descriptor) }; vkUpdateDescriptorSets(device, static_cast(computeWriteDescriptorSets.size()), computeWriteDescriptorSets.data(), 0, NULL); @@ -583,13 +598,8 @@ class VulkanExample : public VulkanExampleBase // are done executing. VK_CHECK_RESULT(vkQueueSubmit(compute.queue, 1, &computeSubmitInfo, compute.fence)); - // TODO: handle flip-flop logic. We want the next iteration to - // run the compute pipeline with flipped SSBOs, so we have to - // swap the descriptorSets, which each allow access to the SSBOs - // in one configuration. - // We also want to flip what SSBO we draw with in the next - // pass through the graphics pipeline. - // Feel free to use std::swap here. You should need it twice. + std::swap(compute.descriptorSets[0], compute.descriptorSets[1]); + std::swap(compute.storageBufferA, compute.storageBufferB); } // Record command buffers for drawing using the graphics pipeline