Project 6: Bowen Bao

README.md

@@ -3,13 +3,31 @@ 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)
+* Bowen Bao
+  Windows 10, i7-6700K @ 4.00GHz 32GB, GTX 1080 8192MB (Personal Computer)
 
-  ### (TODO: Your README)
+## Boids
 
-  Include screenshots, analysis, etc. (Remember, this is public, so don't put
-  anything here that you don't want to share with the world.)
+![](/img/boids.gif)
+
+## Questions
+* 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.
+
+	In Vulkan, the base binding unit is a descriptor. In generating pipelines and commands, it needs to know how data are stored in GPU memory, and thus it needs explicit descriptors to show the bounded data.
+
+* Describe a situation besides flip-flop buffers in which you may need multiple descriptor sets to fit one descriptor layout.
+
+	Like in rasterization, we can have multiple descriptor sets each for color map, normal map and depth.
+
+* What are some problems to keep in mind when using multiple Vulkan queues?
+	* take into consideration that different queues may be backed by different hardware
+	* take into consideration that the same buffer may be used across multiple queues
+
+	One of the problem to consider is how independent each queue is. If there are a lot of synchronization, race conditions between queues, it might not be as effective as expected.
+
+* What is one advantage of using compute commands that can share data with a rendering pipeline?
+
+	Save I/O time for transfering data to render pipeline.
 
 ### Credits
 

data/shaders/computeparticles/particle.comp

@@ -58,11 +58,53 @@ void main()
 		vec2 vPos = particlesA[index].pos.xy;
     vec2 vVel = particlesA[index].vel.xy;
 
-		// clamp velocity for a more pleasing simulation.
-		vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1);
+	vec2 vel1 = vec2(0.0, 0.0);
+	vec2 vel2 = vec2(0.0, 0.0);
+	vec2 vel3 = vec2(0.0, 0.0);
 
-		// kinematic update
-		vPos += vVel * ubo.deltaT;
+	float vel1Count = 0;
+	float vel3Count = 0;
+
+	for (int i=0; i<ubo.particleCount; ++i)
+	{
+		if (index == i) continue;
+		float dist = length(vPos - particlesA[i].pos.xy);
+
+		if (dist < ubo.rule1Distance)
+		{
+			vel1 += particlesA[i].pos.xy;
+			vel1Count += 1.0;
+		}
+
+		if (dist < ubo.rule2Distance)
+		{
+			vel2 -= (particlesA[i].pos.xy - vPos);
+		}
+
+		if (dist < ubo.rule3Distance)
+		{
+			vel3 += particlesA[i].vel.xy;
+			vel3Count += 1.0;
+		}
+	}
+
+	if (vel1Count > 0)
+	{
+		vel1 /= vel1Count;
+		vVel += (vel1 - vPos) * ubo.rule1Scale;
+	}
+
+	vVel += vel2 * ubo.rule2Scale;
+
+	if (vel3Count > 0)
+	{
+		vel3 /= vel3Count;
+		vVel += vel3 * ubo.rule3Scale;
+	}
+
+	vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1);
+
+	vPos += vVel * ubo.deltaT;
 
     // Wrap around boundary
 		if (vPos.x < -1.0) vPos.x = 1.0;

vulkanBoids/vulkanBoids.cpp

@@ -158,6 +158,7 @@ class VulkanExample : public VulkanExampleBase
 		{
 			particle.pos = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator));
 			// TODO: add randomized velocities with a slight scale here, something like 0.1f.
+			particle.vel = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator)) * 0.1f;
 		}
 
 		VkDeviceSize storageBufferSize = particleBuffer.size() * sizeof(Particle);
@@ -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,32 @@ class VulkanExample : public VulkanExampleBase
 			compute.descriptorSets[0],
 			VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER,
 			2,
-			&compute.uniformBuffer.descriptor)
+			&compute.uniformBuffer.descriptor),
 
 			// 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?
+
+			vkTools::initializers::writeDescriptorSet(
+				compute.descriptorSets[1],
+				VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
+				1,
+				&compute.storageBufferA.descriptor
+			),
+
+			vkTools::initializers::writeDescriptorSet(
+				compute.descriptorSets[1],
+				VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
+				0,
+				&compute.storageBufferB.descriptor),
+
+			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);
@@ -590,6 +610,7 @@ class VulkanExample : public VulkanExampleBase
 		// 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]);
 	}
 
 	// Record command buffers for drawing using the graphics pipeline