CIS565-Fall-2018 · yuruwang · Oct 14, 2018 · Oct 14, 2018 · Oct 15, 2018 · Oct 15, 2018
diff --git a/README.md b/README.md
@@ -5,14 +5,72 @@ CUDA Rasterizer
 
 **University of Pennsylvania, CIS 565: GPU Programming and Architecture, Project 4**
 
-* (TODO) YOUR NAME HERE
-	* (TODO) [LinkedIn](), [personal website](), [twitter](), etc.
-* Tested on: (TODO) Windows 22, i7-2222 @ 2.22GHz 22GB, GTX 222 222MB (Moore 2222 Lab)
+* Yuru Wang
+* Tested on: Windows 10, i7-7700HQ @ 2.5GHz 128GB, GTX 1050 Ti 8GB (personal computer)
+* Modified CMakeList.txt: changed sm_20 to sm_61 inside cuda_add_library
 
-### (TODO: Your README)
+## Project Description ##
+This project implements a simplified rasterized graphics pipeline, similar to the OpenGL pipeline which includes vertex shading, primitive assembly, rasterization, fragment shading, and a framebuffer
 
-*DO NOT* leave the README to the last minute! It is a crucial part of the
-project, and we will not be able to grade you without a good README.
+A list of features implemented in this project is as follows:
+* Vertex shading. (vertexTransformAndAssembly in rasterize.cu)
+* Primitive assembly with support for triangles read from buffers of index and vertex data. (primitiveAssembly in rasterize.cu)
+* Rasterization. (**support rasterization for points, lines and triangles**)
+* A depth buffer for storing and depth testing fragments.
+* Fragment-to-depth-buffer writing (Utilized CUDA atomicMin() for race avoidance).
+* Fragment shader with Lambert shading and point light (render in rasterize.cu)
+* **UV texture mapping with bilinear texture filtering and perspective correct texture coordinates**.
+
+## Results ##
+**Screen recording of running program with lambert shading and point light**
+
+| duck.gltf | CesiumMilkTruck.gltf |
+|------|------|
+| ![](renders/demo.gif) |![](renders/demo_2.gif) |
+
+**Render depth and normals**
+
+| depth | normal |
+|------|------|
+| ![](renders/depth.png) | ![](renders/normals.png) |
+
+**Texture mapping and lambert shading**
+
+| plain color | lambert shading |
+|------|------|
+| ![](renders/duck_plain.png) | ![](renders/duck_lambert.png) |
+
+| plain color | lambert shading |
+|------|------|
+| ![](renders/truck_plain.png) | ![](renders/truck_lambert.png) |
+
+**Render texture w/o bilinear texture filtering**
+
+| no bilinear filtering | with bilinear filtering |
+|------|------|
+| ![](renders/no_bilinear.png) | ![](renders/bilinear.png) |
+
+**Back face culling**
+
+| render front face | render back face |
+|------|------|
+| ![](renders/frontface.png) | ![](renders/backface.png) |
+
+**Render points and lines**
+
+| render points | render lines |
+|------|------|
+| ![](renders/points.png) | ![](renders/lines.png) |
+
+## Performance Analysis and Questions ##
+![](renders/time.png)
+Above figure shows the time spent on different rendering pipeline stages for three models. The time is measured on the present of lambert shading, back face culling, and bilinear filtering. As expected, rasterization takes most amount of time in graphics pipeline because the rasterization is parallelized by primitives and each thread needs to iterate through all fragments inside the bounding box, which has a lot more work than other stages. For duck.gltf, the time spent on fragment shading is almost the same as rasterization, this is because in duck model, after rasterization, every fragment have different normals due to the curve surfaces, which results in different calculation time for lambert shading on each threads.
+
+![](renders/backface-culling.png)
+This figure is for the duck.gltf with lambert shading. We can observe an optimization on the performance of rasterization stage which is expected since back face culling eliminates primitives that are not visible by the camera and thus some threads or warps could exterminate quickly.
+
+![](renders/bilinear-filtering.png)
+Above figure is obtained by rendering duck.gltf with back face culling and just texture mapping(no lambert shading). We can notice a little bit performance decay on the fragment shading stage if we add bilinear texture filtering. This is because with bilinear filtering, there are some more operations need to done for every fragment (literally 3 more linear color interpolations) which slow down the process a little bit.
 
 
 ### Credits

diff --git a/renders/QQ截图20181013141433.png b/renders/QQ截图20181013141433.png
diff --git a/renders/backface-culling.png b/renders/backface-culling.png
diff --git a/renders/backface.png b/renders/backface.png
diff --git a/renders/bilinear-filtering.png b/renders/bilinear-filtering.png
diff --git a/renders/bilinear.png b/renders/bilinear.png
diff --git a/renders/demo.gif b/renders/demo.gif
diff --git a/renders/demo_2.gif b/renders/demo_2.gif
diff --git a/renders/depth.png b/renders/depth.png
diff --git a/renders/duck-diffuse-texture.png b/renders/duck-diffuse-texture.png
diff --git a/renders/duck_lambert.png b/renders/duck_lambert.png
diff --git a/renders/duck_plain.png b/renders/duck_plain.png
diff --git a/renders/frontface.png b/renders/frontface.png
diff --git a/renders/lines.png b/renders/lines.png
diff --git a/renders/no_bilinear.png b/renders/no_bilinear.png
diff --git a/renders/normals.png b/renders/normals.png
diff --git a/renders/points.png b/renders/points.png
diff --git a/renders/time.png b/renders/time.png
diff --git a/renders/truck_lambert.png b/renders/truck_lambert.png
diff --git a/renders/truck_plain.png b/renders/truck_plain.png
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
@@ -6,5 +6,5 @@ set(SOURCE_FILES
 
 cuda_add_library(src
     ${SOURCE_FILES}
-    OPTIONS -arch=sm_20
+    OPTIONS -arch=sm_61
     )
diff --git a/src/main.cpp b/src/main.cpp
@@ -121,6 +121,7 @@ void runCuda() {
 
     cudaGLMapBufferObject((void **)&dptr, pbo);
 	rasterize(dptr, MVP, MV, MV_normal);
+	cout << "elapsed time: " << timer().getGpuElapsedTimeForPreviousOperation() << endl;
     cudaGLUnmapBufferObject(pbo);
 
     frame++;