| Instructor: | Professor Hank Dietz |
|---|---|
| Office: | 203 Davis Marksbury Building |
| Email: | hankd@engr.uky.edu |
| Home URL: | http://aggregate.org/hankd/ |
| Course URL: | http://aggregate.org/GPUCOURSE |
| Course Meetings: | TR 9:30-10:45 in 255 F. Paul Anderson Tower |
| Course Text: | None required - we will use course notes
Both NVIDIA and AMD have extensive collections of supporting materials freely available or indexed at their WWW sites, and we will be making heavy use of some of those materials in addition to notes developed here. |
GPU Computing is about the emerging many-core parallel computing architecture originally developed as Graphics Processing Units for video cards.
This course will begin by tracing the evolution of SIMD (Single Instruction, Multiple Data) architecture that produced modern GPUs, studying the current architectural features, and discussing trends for the future. GPUs are evolving rapidly and not without growing pains (buggy hardware and software, fundamental changes to the programming model, Intel's Larrabee, etc.), but it is clear GPU-like architectures are here to stay and are becoming an integral part of most computers and processor chips (e.g., AMD Fusion "APUs").
The bulk of the course will then involve using various GPU programming environments (especially CUDA and OpenCL), running on ATI (now AMD) and/or NVIDIA GPUs, to implement programs solving problems that would classically have been run on supercomputers. All students will have hands-on experience programming GPUs for assigned problems, at least one of which will involve building software tools/support to make GPUs easier to use. In addition, each graduate student (EE 699) will be expected to solve a modest GPU programming problem that they individually will propose, write-up, code, and present to the class.
A good knowledge of C programming is expected, as all the programming will use environments building on C. Grading will be based on two in-class exams, several programming assignments, and the graduate student's presentation of the project they proposed. It is expected that the exams and assignments will count for approximately equal portions of the grade.
The specific lecture coverage will strongly depend on the class background and interests. The general flow will be:
Grading will be based on two in-class exams, several programming assignments, and the graduate student's presentation of the project they proposed. Simple quizzes may be given in class to confirm your attentiveness and help tailor the presentation to better meet student interests and needs. The relative weightings of the assignments are yet to be determined. Independent of the weights, your final grade cannot be more than one letter grade above the lowest of your separate averages for assignments that involve coding vs. tests.
The two in-class exams should take about 1 hour each, and the schedule will be announced in class and at the course URL. It is likely one exam will be November 15 or 17, because Prof. Dietz has a major research exhibit at IEEE/ACM SC11 that week. Final exams are scheduled by the office of the registrar . We intend to use the scheduled 10:30AM Monday, December 12, 2011, final exam timeslot for brief project presentations from the graduate students enrolled in EE699-002. Although we will try to accomodate requests to take exams at other than the scheduled times, such requests generally will be considered only if made in writing or email at least a week before the scheduled exam time, and the course staff may decide to use a different format (e.g., an oral exam) for exams given at times other than those scheduled.
The programming assignments will require use of a GPU. Physical access to a small number of systems will be provided in room 108 Davis Marksbury Building, with remote access to a larger number of systems. However, students are encouraged to use any appropriate computers to which they have access. Although AMD/ATI GPUs will be discussed, everything can be done using any NVIDIA GPU that is capable of both CUDA and OpenCL.
Testing/grading will be done using a Linux environment, but data demonstrating correct runs on other systems also will be accepted. Each program will be expected to be accompanied by a brief "Implementor's Notes" document giving an overview of the approach used and any known problems. To encourage good design and documentation, any documented bug in a project will loose only half as many points as the same bug without documentation. This is even taken to the limiting case of giving half credit for a submission that simply says "My project doesn't work because I didn't get around to writing it."
So that any grading errors can be consistently corrected for all students, regrade requests (preferably in writing) must be made promptly and must be specific as to the reason a regrade is requested. Any work submitted for regrade may be re-evaluated in its entirety.
Although students are encouraged to discuss course material with one another, everything you submit must be entirely your own original work. UK guidelines dictate that violation of this policy will result in all involved students failing the course; more severe penalties also may be applied. Contact Professor Dietz before submitting work if you have any doubts about how this policy might apply.
GPU Computing