Wednesday, April 10, 2013

Reflections on Teaching GPU Programming and Architecture: Take III

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.

No Grades

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.

Yuanhui Chen presents her hack

I wrote a full post about our hackathon: Hackathons in the Classroom.

Guest Lectures

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.

Flexible Schedule

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.

Also, here's my reflections on previous semesters:

Monday, April 8, 2013

Graphics Pipeline: Before and After My GPU Course

A big part of my GPU course is the modern graphics pipeline. Before students take my class, they usually have had one or two graphics classes, but not necessarily much experience with real-time rendering.

To see how well we did this semester, on the first day of class, I asked each student to draw the graphics pipeline on a sheet of paper. Then I asked the class as a whole to collaborative and draw a graphics pipeline on the board. We came up with something like this:

Then I handed out the pipeline map from OpenGL Insights, and said by the end of the semester they would have a pretty good understanding of it.

The semester went on, and we did a bunch of cool projects, including a graphics pipeline implemented in CUDA.

At the end of the semester, I told the class that there would be a final, but they didn't need to study for it and that it wouldn't be graded. For the "final", we repeated the first day of class: students individually drew pipelines, followed by a pipeline by the entire class:

Wow - what a difference! I also handed back individual pipelines so students could compare theirs to the first day of class.

Sunday, April 7, 2013

How developers can get into teaching

A friend recently asked:

I'm considering teaching a course either at the college or high school level in programming similar to what you do. Do you have any tips on how I can learn more about the opportunities? Should I get a masters if I plan to teach college level courses? How did you reach out to schools about teaching?

I really like the idea of developers from industry teaching computer science courses. Practitioners bring a real-world perspective and coolness to the classroom that is hard for full-time faculty to mimic. The academic rigor also rubs off on practitioners by exploring a subject at a new depth. "You don't know something until you can teach it."

Here's a cleaned up version of the answer I gave my friend:

Should I get a masters if I plan to teach college level courses?

Major universities require that professors have a PhD. Generally their PhD is from a more prestigious university and it is rarely from the same university. However, there are part-time and full-time teaching positions, called lecturers (lecturer has a different meaning in the UK), that do not require a PhD. For example, Penn pretty much always has openings for lecturers.

A research-focused university may prefer lecturers have a PhD, but only require a master's degree. Without a PhD, you may find yourself running into glass ceilings, like not being able to introduce a new required undergraduate course, but if your ideas are good, things can happen one way or another. Many universities, especially those with only undergrad programs and/or where most students go into industry, allow lecturers to have just a bachelor's degree, especially if they have good industry experience.

So, no you don't need a masters degree, but it increases the number of places you can teach at - and helps you build an academic network.

How did you reach out to schools about teaching?

I didn't. I was lucky. I knew a lot of folks at Penn after going there, Joe Kider in particular, and they encouraged me to apply to teach the GPU course.

It's not always that simple, but there's plenty you can do...

Give a talk at a local university

There's two ways to do this.
  • Reach out to the instructor of a relevant course and offer to give a guest lecture. Pretty much all computer science departments list their current courses. Likewise, faculty have websites with their email addresses. For example, here's Penn's faculty. Write a concise email to the instructor saying where you work, what you'd like to give a talk on, and how it maps to their course. Having slides already made could help, but I've personally never seen it.

    Generally, an instructor really likes guest lectures, especially for graduate-level and seminar-style courses. In fact, I spend a good bit of time trying to find guest lectures. Given that I teach a GPU course, I'm thrilled to have folks from GPU vendors, game studios, research labs, etc. come in and talk. Even though I am from industry, guests bring another real-world perspective. In fact, I am willing to cancel one of my lectures for the right guest lecturer. They are one of the highlights of the semester.

    Make sure to get your timing right. For example, don't email the instructor with two weeks left in the semester to see if you can come in. It's hard to say when the best time is because preparation varies by instructor. I generally firm up guest lectures at the start of the semester or a month or so before. Just a warning - the first week of classes is generally crazy.

  • Reach out to a faculty in your area of interest and offer give a talk to the entire department. This is nice because you'll meet more people and sometimes instructors don't want to give up class time. Most departments have a colloquium series where visitors from academia or industry present their work. For example, here's Penn's colloquium. A lot of time this is research-focused, but it doesn't have to be, especially at a smaller university.

    When I defended my master's thesis, I invited graphics faculty from the local universities. None of them actually came, but it did result in me being invited to speak at the Villanova colloquium. My work wasn't full research. It had a minor contribution or two, but it was really more like "here's a survey of a field and a cool project with a careful write-up." I imagine most practitioners could prepare a talk like this.

There's a few motivations for giving a talk.
  • You are passionate about a topic that you want to share with others. If this isn't the case, teaching isn't for you.
  • Giving a talk isn't the same as teaching, but it is good practice and relevant experience.
  • It is good for networking even if there aren't any current openings at that particular university.

Give a talk at a conference

Giving a talk at a conference can have a lot of the same benefits of giving a talk at a university. It's good for sharing knowledge, building experience, and networking, especially if a lot of academics attend the conference.

Depending on the conference, getting a talk accepted can be hard. I've been rejected a couple of times. No worries, everyone gets rejected at least sometimes.

Big conferences like SIGGRAPH are competitive, but it's possible to join an established course or partner to create a new course or panel, talk at a Birds of a Feather (BOF), or even hold your own BOF. Something like a BOF talk won't hold as much credibility in the eyes of an academic but it's still fun, and good experience and networking.

Big conferences aren't the only option. Your company's user's conference is an easy option. So are local meetups. Smaller and industry-focused conferences are also a good option.

You can also give a talk at company to build experience. Most places have brownbags and invited speakers. It will help to know someone there who can host you. For example, I gave a talk on our WebGL engine, Cesium, at MIT Lincoln Lab through a friend I previously worked with at IBM.

Give a talk at a local high school

Most high schools have computer science and even AP computer science classes now. The teachers love having someone from industry talk to their students. It helps them bridge the gap between what students see in the classroom and what students can do in the real-world.

I've been back to my high school a few times. One time I wrote a small Java framework to play tic-tac-toe. As a lesson in polymorphism, students could implement a class to write their AI, and then their AIs could play each other. I even had some of my friends implement AIs so the students could play the "pros."

Teachers would also be thrilled for you to come in and talk about how you got into development, what you do everyday, and what advice you have for students. A talk like this is pretty quick to prepare too.

Other ideas

Although I don't have any experience with them other than serving as a reviewer, teaching an online course like those offered by Udacity, is another option. The student interaction is quite different, but it could still be rewarding and you could reach a lot of people.