MPCS 52072 - GPU Programming documentation

Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

MPCS 52072 - GPU Programming documentation

Course Description

This course provides an introduction to programming for Graphics Processing Units (GPUs), primarily focusing on both the theoretical aspects and practical implementations for programming on them. With the increasing demand for high-per-formance computing, understanding how to leverage GPUs is becoming essential for various "elds including machine learning, scienti"c computing, and computer graphics. Students will learn the fundamental principles of GPU architecture, which includes GPU hardware structure, memory hierarchy, and execution model. Students will gain pro"ciency in writing GPU programs by using industry-standard frameworks such as CUDA and OpenCL. By the end of this course, students will know how to pro"ciently use GPU resources to accelerate the performance of a wide range of applications that require their computational power.

Prerequisite: Core Programming, Fluency in C is required.

Course Staff

Instructor

Lamont Samuels (https://lsamuels.github.io)

Teaching Assistants

Tina Oberoi (contact on Ed)

Nishchay Karle (contact on Ed)

Graders

None

Course Structure

The course material will be split into seven modules that will span 1-2 weeks through out the quarter. The delivery of each module will follow a #ipped classroom model, where the lectures/module content will be delivered in two ways:

Synchronous content (i.e., zoom meetings) : Each week during our normal class time, we will meet via Zoom, where you will join via a Zoom invite. These invites are accessible via Canvas. The synchronous lectures will include the fol-lowing:

An introduction to the material/topics for the current week’s module.

Allow you to ask questions about the content provided in the videos from the prior week.

Have live coding sessions/activities with everyone regarding the material covered in the current week’s mod-ule.

Asynchronous content (i.e., pre-recorded videos/readings): Each week after our normal class time, you will be re-quired to watch pre-recorded videos and do readings from the current week. The videos will include lecture con-tent that would be normally covered in a traditional lecture setting (i.e., non-remote setting). These videos and readings will typically range between 1 hour to 1.5 hours and be posted after our scheduled time. Feel free to watch them at your convenience. However, you are required to watch the pre-recorded videos before we meet the next week. I will try post readings for the next module in advance in case you would like to read about the topics for the next module before the next class.

Please see the calendar (calendar.html) for more details on what happens on a week to week basis.

Coursework

The course will include weekly homework, one quarter exam, attendance and projects:

Homework - The weekly homework assignments will contain practice problems to help enforce the concepts learned during a lecture.

Attendance - In order to receive you full attendance weight, you must do the following

1. Attend every lecture (either in-person or remotely). If you cannot attend a lecture then you must reach out to the instructor letting them know you won’t be able to attend.

2. You must watch any speci"ed pre-recorded lectures. We will look at the statistics on Panopto to ensure you watch the videos. As long as you continuously do those two main points you will receive full credit for attendance.

Projects - The projects provide the opportunity to apply the skills you learned to develop systems that can bene"t from GPU parallelization. Potential project domains could include: AI and machine learning, computer graphics, cryptocurrency technologies, scienti"c visualization, etc.

All homework and projects will be due on Fridays @ 11:59pm. The new assignments will be out by Friday evenings. I will post when they are available. Please note that I am normally busy on Friday afternoons and weekends so I may not be available for additional help. Please make sure to take this into consideration as you manage the coursework in this class.

Please see the Assignments Rubric (assignments/index.html) page for more details on how the assignments will be grad-ed.

Course Software

C will be the required language to code all programming assignment. You will be testing your GPU programs on a UChica-go server. We will provide details about accessing the server and running programs on it via the "rst assignment. You could potentially work locally on your assignments if you have a CUDA enabled device installed on your local machine. However, all programs will need to be veri"ed and working correctly on the UChicago server speci"ed in the assignment. Thus, we recommend writing all programs on that server instead.

The basics that will you need in order to connect to the server will be the following:

UNIX based machine (e.g., macOS or Linux) or software that allows for you to ssh into the server.

Git (http://git-scm.com/downloads/)

Text editor (suggestion, not required): Visual Studio Code (https://code.visualstudio.com)

Books

This course will not have a required textbook; although, for those students who may "nd it helpful to know the topics we will discuss each week, readings will come from the text:

Programming Massively Parallel Processors: A Hands-on Approach by Wen-mei W. Hwu, David B. Kirk, Izzat El Hajj and will be shown on the course schedule. Along with these readings and the lecture notes, students may "nd the follow-ing references helpful in understanding the course material:

Professional CUDA C Programming by John Cheng, Max Grossman, Ty McKercher

C Programming: A Modern Approach, 2nd Edition by K. N. King

Grading

Your "nal grade will be based on the following:

Homework (10% each)                                           40%

Project 1                                                                15%

Projects 2                                                               20%

Projects 3                                                               20%

Attendance                                                              5%

Grades are not curved in this class or, at least, not in the traditional sense. We use a standard set of grade boundaries:

95-100: A

90-95: A-

85-90: B+

80-85: B

75-80: B-

70-75: C+

<70: Dealt on a case-by-case basis

We curve only to the extent we might lower the boundaries for one or more letter grades, depending on the distribution of the raw scores. We will not raise the boundaries in response to the distribution.

So, for example, if you have a total score of 82 in the course, you are guaranteed to get, at least, a B (but may potentially get a higher grade if the boundary for a B+ is lowered).

Late submissions ¶

You cannot use a late extension on the last project (i.e., Project 3) in the course!

You are allowed to make at most two late submissions on the programming assignments. You are allowed to make at most two late submissions on the programming assignments. This is total across all assignments and not on a per-assign-ment basis. For example, you can use one late submission on homework #1 and homework #2 and then you’ll be out of late extensions. Please ask on Ed if you are confused by the late submission policy. Late submissions will be accepted up to 24 hours after the deadline. You are allowed to double up on your late submissions (i.e., if you have not used your two late submissions, then you can use them back to back).

No credit will be given for late submissions after you have used up your two allowed late submissions.

No credit will be given for any submission made 24 hours after the deadline.

Please note that, while Gradescope does enforce the 24-hour limit on late submissions and will clearly #ag late submis-sions with a red “LATE” label, it does not enforce our speci"c limit of two late submissions. It is your responsibility to keep track of how many late submissions you have made so far, and to ensure you don’t make more than two late submissions.

If extraordinary circumstances (medical and family emergency etc.) prevent a student from meeting a deadline, we may grant additional extensions on a case-by-case basis. Whenever possible, the student must inform their instructor of these extraordinary circumstances before the deadline.

Please note that having a heavy workload in a given week does not qualify as an extraordinary circumstance. The purpose of the two extensions is precisely to give you some #exibility in weeks when you are busier than usual. Additionally mild COVID or common cold illness is also does not qualify as an extraordinary circumstance.

Regrades

We sometimes make mistakes, and are happy to review any incorrect grading decision.

However, please note that we will only consider regrade requests where a grader made an actual mistake (e.g., they took points o! claiming you didn’t do something, when you actually did do it and the grader maybe missed that when reading over your submission). We will not consider regrade requests that ask for point penalties to be reduced, or try to argue that we should not be taking points o! for a given issue in your code.

For example, suppose you receive a penalty that says “-2 points: Function X did not check that parameter Y is greater than zero”. If function X in your code did perform this check, and the grader missed this fact (and erroneously applied that penalty), you can submit a regrade request asking us to review this decision. We ask that you keep these requests brief and to the point: no more than 1-2 paragraphs identifying the exact penalty and the reasons you believe it was applied erroneously, including references to speci"c parts of your code (e.g., “I did check the value of the parameter in line 107”). Focus on laying out the facts, and nothing else.

On the other hand, let’s say you received the “Function X did not check that parameter Y is greater than zero” penalty, and function X in your code did not perform this check. In this case, you cannot submit a regrade request arguing that this is not something for which we should deduct points, or that the point deduction should be lower. Please note that all penalties are explicitly approved by an instructor (graders have no discretion to come up with penalties on their own and, if they took points o! for something, it is because they were directed to do so by the instructors).

Please note that, while you may request a regrade for a speci"c issue, an instructor may do a full regrade of your submis-sion if they feel there are other issues with the grading of your submission. This can result in you ending up with a lower score on the assignment.

Steps to Submit a Regrade Request

1. Read over the above section to make sure your request will not be denied.

2. All regrades must be submitted on Gradescope. Do not write on Ed asking for a regrade request. However, you can on Ed notify the instructor(s) that you submitted a regrade request on Gradescope.

3. Finally, it is also your responsibility to make these requests in a timely manner. Requests for regrades must be sub-mitted no later than one week after a graded piece of work is returned to you. After that time, we will not consider any requests for regrades, regardless of whether the regrade request is reasonable and justi"ed.

Please allow time for the course sta! to review your regrade request. We cannot provide a speci"c timeframe when your request will be handled. We are on a tight schedule grading other assignments but your request will be reviewed before the end of the quarter.