CIS565-Fall-2017 · charlesliwang · Oct 17, 2017 · Oct 17, 2017 · Oct 17, 2017 · Oct 17, 2017
diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -2,6 +2,9 @@ cmake_minimum_required(VERSION 3.0)
 
 project(cis565_rasterizer)
 
+find_package(Threads REQUIRED)
+find_package(CUDA 8.0 REQUIRED)
+
 set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH})
 
 # Set up include and lib paths
@@ -76,8 +79,6 @@ if (WIN32)
 endif()
 
 # CUDA linker options
-find_package(Threads REQUIRED)
-find_package(CUDA 8.0 REQUIRED)
 set(CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE ON)
 set(CUDA_SEPARABLE_COMPILATION ON)
 

diff --git a/README.md b/README.md
@@ -1,18 +1,66 @@
 CUDA Rasterizer
 ===============
 
-[CLICK ME FOR INSTRUCTION OF THIS PROJECT](./INSTRUCTION.md)
-
 **University of Pennsylvania, CIS 565: GPU Programming and Architecture, Project 4**
 
-* (TODO) YOUR NAME HERE
-* Tested on: (TODO) Windows 22, i7-2222 @ 2.22GHz 22GB, GTX 222 222MB (Moore 2222 Lab)
+* Charles Wang
+* Tested on: Windows 10, i7-6700K @ 4.00GHz 16GB, GTX 1060 6GB (Personal Computer)
+
+![](img/truck.gif)
+
+## **Project Overview and Goals**
+
+The goal of this project was to write (most of) the graphics pipeline with CUDA kernels. The project tests ability to understand what OpenGL and other graphics APIs typically do under the hood. There is also continual discussion of the shift from hardware implemented pipeline components vs. software implemented components, so this project is, in a way, an investigation on the software capabilities.
+
+I implemented:
+ - Vertex Assembly
+    - storing proper information into VertexOut objects after model and camera transformations
+ - Rasterization:
+    - storing fragments with barycentric interpolation for normals, uvs
+- Rendering
+    - basically fragment shading.
+    - using the stored information to compute lighting (lambert)
+
+### Different Rasterization Modes
+
+I implemented three different rasterization modes: lambert, wireframe and point cloud. They all use the same geometry but provide a slightly different way of presenting the data. 
+
+ ![](img/duck.PNG)  |  ![](img/ducklines.PNG) | ![](img/duckpoints.PNG)  |
+|---|---|---|
+|  lambert shading with textures  |  triangle wireframe | point cloud   |
+
+### Perspective Correct
+
+Naively using barycentric interpolation for uv coordinates will result in skewing at certain viewing angles. Perspective correct interpolation will remedy this at a small computational cost.
+
+ ![](img/notperspectivecorrect.PNG)  |  ![](img/perspectivecorrect.PNG) |
+|---|---|
+|  no perspective correct  |  perspective correct |
+
+### Bilinear Texture Filtering
+
+Casting uv coordinates from floats to ints and fetching texture pixel information directly commonly leads to aliasing issues when the texture is not high resolution.  Bilinear texture filtering is a way of averaging nearby pixels so the resultant texture is more smooth.
+
+ ![](img/nobilinear.PNG)  |  ![](img/bilinear.PNG) |
+|---|---|
+|  no bilinear filtering  |  bilinear filtering |
+
+
+### Performance Analysis
+
+Below are charts that describe the compute breakdown of my graphics pipeline.
+
+For some reason, the vertex and primitive assembly takes up a huge chunk of the total render time (I need to further investigate because there's not much complexity in what's been implemented... maybe it's a weird hardware thing)
+
+![](img/chart.PNG)
+
+In any case, the vertex and primitive assembly stages are the same for all configurations of my rasterizer, so maybe it'd be more meaningful to take a look at the rest:
 
-### (TODO: Your README)
+![](img/chartnovertex.PNG)
 
-*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.
+Rasterization is slightly more costly for shaded geometry because we need to find fragments within a bounding box that are inside the triangle, rather than just plotting the lines or points. Textured geometry will also take more time to rasterize because we need to find the perspective correct interpolated values for the UVs.
 
+Fragment shading for shaded geometry is also significantly slower because we need to calculate lambertian shading and fetch texture data rather than just passing through the fragment color. Intrducing bilinear texture filtering also slows down the process because each fragment color requires multiple texture pixel accesses.
 
 ### Credits
 

diff --git a/img/bilinear.PNG b/img/bilinear.PNG
diff --git a/img/chart.PNG b/img/chart.PNG
diff --git a/img/chartnovertex.PNG b/img/chartnovertex.PNG
diff --git a/img/duck.PNG b/img/duck.PNG
diff --git a/img/ducklines.PNG b/img/ducklines.PNG
diff --git a/img/duckpoints.PNG b/img/duckpoints.PNG
diff --git a/img/nobilinear.PNG b/img/nobilinear.PNG
diff --git a/img/notperspectivecorrect.PNG b/img/notperspectivecorrect.PNG
diff --git a/img/perspectivecorrect.PNG b/img/perspectivecorrect.PNG
diff --git a/img/truck.gif b/img/truck.gif
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
@@ -2,9 +2,12 @@ set(SOURCE_FILES
     "rasterize.cu"
     "rasterize.h"
     "rasterizeTools.h"
+    "timer.h"
     )
 
 cuda_add_library(src
     ${SOURCE_FILES}
-    OPTIONS -arch=sm_20
+    OPTIONS -arch=sm_61
     )
+
+LIST(APPEND CUDA_NVCC_FLAGS "-gencode arch=compute_61,code=sm_61")