Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 19 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
60 changes: 46 additions & 14 deletions data/shaders/computeparticles/particle.comp
Original file line number Diff line number Diff line change
Expand Up @@ -41,34 +41,66 @@ 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;
// Don't try to write beyond particle count
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;

Expand Down
Binary file modified data/shaders/computeparticles/particle.comp.spv
Binary file not shown.
Binary file added demo.gif
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
44 changes: 27 additions & 17 deletions vulkanBoids/vulkanBoids.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -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
{
Expand Down Expand Up @@ -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.
}

Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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<uint32_t>(computeWriteDescriptorSets.size()), computeWriteDescriptorSets.data(), 0, NULL);
Expand Down Expand Up @@ -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
Expand Down