I’ve taught CIS 565: GPU Programming and Architecture at the University of Pennsylvania three times now, and every time I like to write a reflections post on what went well and what didn’t.
This semester I made some pretty unconventional changes…
No Written Homework. No Tests. No Final.
|CUDA path tracer – Aparajith Sairam|
My course is about writing code that runs on the GPU so I’ve tuned it as such. I replaced written homework with longer and harder coding projects. The first three projects were a ray tracer, a path tracer, and a rasterizer, all written in CUDA.
The previous semester a few students did a path tracer for their final project, but this semester we raised the bar and made it a regular project. In general, we are always looking for outstanding final projects that we can turn into a regular project the next semester. We also added a rasterizer – a stripped down OpenGL ES 2.0-like pipeline. Quite frankly, I wasn’t sure how feasible it would be, but the results were awesome.
Open Source Projects
|Tessellation shaders – Tiju Thomas|
The second time I taught, I required students use private GitHub repos to help them learn source control. The feedback was great; students started using GitHub for everything: other classes, personal projects, etc.
This semester we took it a step further; we encouraged them to make all their projects open source (previously we only did this for the final project). The motivation is to help them build a code portfolio for job hunting as inspired by an internship posting by Christophe Riccio
“The profile for the candidates: C++, OpenGL, OpenCL. Applications with a source code and for the principle of it, a resume.”
To discourage cheating, the academic integrity policy was strict and projects had large open-ended parts. No two projects were exactly alike. Students also gave random random presentations in class on their work. I’m sure this discouraged cheating, but the real motivation was to give them experience talking on their feet and explaining their work.
I wrote a full post about our open source experience: GitHub and Open Source in the Classroom.
|CUDA path tracer with a kd-tree – Zakiuddin Shehzan Mohammed|
Also along the lines of building a portfolio, we had students keep semester-long blogs showcasing each of their projects. Previously, we only required a blog for the final project.
No Final? Really?
OK, I actually told the students that there was a final, but it wasn’t graded and they couldn’t study for it. On the first day of class, I had students draw a graphics pipeline, first individually then as a group. The result was:
At the end of the semester, we did the same exercise as the “final” (with no prior warning as to what the final was), and the result was much better:
This was almost like a final for me! I wrote a full post on this exercise: Graphics Pipeline: Before and After My GPU Course.
|CUDA Rasterizer – Himanshu Masand|
Last semester, I decided grades just got in the way. They measure rigor, and rigor isn’t everything. I want to create a culture of passion for graphics, and to facilitate the quest for knowledge, not the quest for grades. So I let students grade themselves. Well, we reserved 40% of the grade as a sanity check and we, of course, still provided detailed feedback on their work.
The results were great – grades were never a concern as far as I could tell, and students tended to grade themselves harder than I would have, especially the top students.
Instructor/student culture matters and removing grades helps. It makes instructors more approachable; making them less like a boss and more like a mentor.
This also helped create a culture of doing projects for the right reasons, not for grades. For example, several students continued working on their projects after the due-date just because they wanted to make them better.
Course != Lectures
|CUDA path tracer – William Boone|
Traditionally, we look at a course as covering a topic using lectures and reading, and with homework, projects, and exams to drive home the material.
One minor thing I did was re-brand “homework” as “projects.” No one wants to do homework, but everyone loves projects. In my course, everything is projects anyway. This is a minor wording change, but it helps with course culture.
I also fundamentally revisited how I look at a course. It is not a series of lectures; it is a series of projects with supporting lectures. I’m not an instructor; I’m more like a coach helping the team prepare for events (projects). One problem I ran into is that I want to do more projects, but it’s hard for lectures to keep pace.
A theme this semester was that we can’t teach passion, but we can create an environment that fosters it. One of the ways this manifested itself is with a hackathon. I canceled class one day and replaced it with a six-hour hackathon using the GLSL Sandbox and GPU ray marching. The results were great, the energy was awesome, and the students were focused.
This wasn’t graded – that would take the fun out of it. Instead I let the students judge each other for prizes. Strictly speaking, the students didn’t even have to be there, but everyone was there and they pushed hard. I can’t reproduce that with an exam.
I wrote a full post about our hackathon: Hackathons in the Classroom.
|NPR – Kong Ma|
We were fortunate to have several great guest lectures this semester. Dave Shreiner from ARM talked about mobile graphics, OpenGL, and the future of graphics programming; Graham Sellers from AMD talked about OpenGL from the implementer’s perspective; and Tim Kaldewey joined us twice to talk about GPU search and data warehousing.
I like guest lectures because they bring in an outside expert perspective, and overall add to the excitement of the course. I will always cancel one of my lectures for an outstanding guest lecture, but don’t be fooled, setting up a guest lecture is more time consuming that preparing a lecture, but it is worth it.
|Globe Rendering – Ashima Gupta|
In previous semesters, I planned out dates for the projects and lectures well in advance and tried hard to stick to them so students could plan their time in advance.
When introducing potentially last-minute guest lectures and trying projects that we’ve never done before, keeping a rigid schedule was too hard. Instead, we only planned one project out and adjusted the amount of time as needed.
Not For Everyone
These off-the-wall teaching methods won’t work for everyone or for every course. I am lucky in that my course usually attracts second year graduate students. I would change things up for, say, an introduction to computer science course.
What Didn’t Go Well
Although I think this was my most successful semester – in that the students enjoyed it and several took GPU-related jobs or jobs thanks, in part, to this course – a few things did not go well.
- Lack of performance focus – This is embarrassing, but we put so much effort into just seeing if we could get students to be successful with the new projects, that I ignored a lot of performance details in the projects. This really hit home when one student told me they went the entire semester without using shared memory in CUDA. I think I got performance right the first semester I taught so I need to improve this.
- Lack of tools – I’m a big fan of developer tools, but I barely touched them. We need detailed walkthroughs of tools like the WebGL Inspector and Parallel NSight.
- Not enough OpenGL – I made the false assumption that the students already knew OpenGL pretty well, and when material needed to be cut, I cut OpenGL. Big mistake.
- Lectures were OK – The best lectures I give are the ones I just created from scratch. I had some tough time commitments, namely NORAD Tracks Santa, which lead me to giving a few lectures reusing slides and barely looking at them beforehand. Those lectures were OK, but I’m striving for much better than OK.
Ideas for Next Semester
|CUDA path tracer – Seunghoon Park|
For this upcoming fall, we’re going to try some new ideas:
- More hackathons – the students liked the hackathon so much that they suggested doing more of them. In particular, doing one strictly on optimization. Students come in with their basic GPU ray tracer or path tracer and then compete to make it as fast as possible during the hackathon.
- Compete against another university – I wanted to compete against a similar course at another university for a while. This could be a joint hackathon or a joint project. There could be prizes for best performance, best visual quality, etc. This would really build some excitement and exposure for the students.
- Alternative final projects – most students do a flashy final project, usually a new rendering technique. I want to encourage an alternative route that lacks the flash, but impacts the graphics community: write or contribute to an open-source tool that the graphics community needs, e.g., think texture compression libraries, shader translation, etc.
|Edge Detection – Gundeep Singh Bharma|
- Focus more on WebGL, OpenGL ES, and mobile architecture.
Finally, much of this semester’s success was due to my teaching assistant, Karl Li, who implemented the starter code for the projects and supported the students. I simply said things like “let’s do a rasterizer” and Karl made them happen.