Ian Buck and the Making of GPU Computing
The graphics processing unit was designed to do one thing very quickly: turn descriptions of three-dimensional scenes into coloured pixels on a screen. For most of its history that was all anyone expected of it. Today the same class of chip trains the large neural networks behind modern artificial intelligence, runs simulations of climate, proteins and galaxies, and fills entire buildings in the data centres of the world’s largest computing companies. The change did not happen through hardware alone. It depended on a way of programming these chips that ordinary scientists and engineers could learn and use, and much of that work can be traced to one researcher, Ian Buck, who began exploring the problem as a doctoral student at Stanford University and went on to create the CUDA platform at NVIDIA.
This essay follows that history. It describes the state of graphics hardware at the end of the 1990s, the research on stream computing at Stanford that produced the Brook language, the decision by NVIDIA to build a general-purpose computing platform around its chips, the design of CUDA and its first years, and the way in which the platform came to underpin scientific computing and then deep learning. It ends with Buck’s later role in leading NVIDIA’s data-centre computing business and with an assessment of what his contribution was and was not. The emphasis throughout is on the technology and on the ideas that shaped it.
Princeton and the first encounter with graphics hardware
Ian Andrew Buck studied computer science at Princeton University, graduating with a Bachelor of Science in Engineering in 1999, summa cum laude. He was a member of the university’s computer graphics group, and his undergraduate thesis, titled “Animated Teleconferencing: Video Driven Facial Animation”, investigated whether a small set of hand-drawn images could be morphed in real time to follow the facial expressions of a person on camera. The project, carried out with Adam Finkelstein and collaborators including researchers from Microsoft, required a fast facial tracker, an image-morphing algorithm and a classifier for expressions, all working within a thirtieth of a second. It was a graphics problem, but also a problem of computational throughput, and it gave Buck an early appreciation of how much work had to be done for each frame of moving imagery.
After graduation he spent time at NVIDIA, then a young company in Santa Clara that had made its name with graphics chips for personal computers. According to his own résumé, he worked there as a systems engineer from November 2000 to September 2001, studying multithreaded optimisations for the company’s OpenGL driver and the behaviour of the Pentium 4 processor’s cache and front-side bus, and working on a forthcoming chipset product. The work was practical engineering on the boundary between graphics hardware and the central processor, and it introduced him to the internal architecture of the devices that would later be the subject of his research.
From fixed function to programmable shaders
To understand what Buck and his colleagues later did, it is necessary to recall what a graphics chip of the late 1990s was. Early graphics accelerators implemented a fixed pipeline. Geometry, described as triangles in three-dimensional space, was transformed and lit, projected onto the screen, broken into fragments corresponding to pixels, textured and blended into a frame buffer. Each stage did a fixed set of operations that could be configured but not reprogrammed. NVIDIA described its GeForce 256 of 1999 as the first “GPU”, a term intended to signal that transformation and lighting, previously done on the central processor, were now done on the graphics chip.
The decisive change came over the following three years, when the stages of the pipeline became programmable. The GeForce 3 of 2001 allowed developers to write short programs, known as vertex shaders, that ran on every vertex of a model, and limited programs for pixels. In 2002 and 2003 a new generation of chips, including ATI’s Radeon 9700 and NVIDIA’s GeForce FX, supported programs that ran on every fragment using floating-point arithmetic. These shaders were written first in assembly-like languages and then in higher-level languages such as NVIDIA’s Cg, Microsoft’s HLSL and the OpenGL Shading Language.
Programmable fragment shaders with floating-point arithmetic changed the character of the hardware. A graphics chip now consisted of many processing units, each capable of executing the same short program on a different piece of data, together with a memory system optimised to stream large amounts of data through them. In raw arithmetic throughput these chips had begun to exceed the central processors of the period, and their performance was growing faster from one generation to the next. Researchers noticed. If a problem could be expressed as a computation applied independently to many elements, it might run much faster on a graphics chip than on a conventional processor.
The idea of general-purpose GPU computing
Through the early 2000s a growing community of researchers experimented with what came to be called general-purpose computing on graphics processing units, or GPGPU. The term itself was popularised by Mark Harris, then a graduate student at the University of North Carolina, who founded the website gpgpu.org to collect work in the field. Researchers implemented linear algebra, fluid simulation, image processing, database operations and many other algorithms on graphics hardware.
The technique was ingenious but awkward. To use a graphics chip for a non-graphical computation, a programmer had to disguise the computation as a rendering task. Input arrays were loaded into textures, the image data structures that shaders could read. The computation was written as a fragment shader. To run it, the programmer drew a rectangle covering a region of the screen, so that the shader executed once for each pixel in the rectangle, and the result was written into an off-screen buffer that could then be read back or used as a texture in a further pass. Loops became sequences of rendering passes; arrays became images; indices became texture coordinates. The programmer needed to understand the graphics interfaces OpenGL or Direct3D, the quirks of each vendor’s drivers and the precise capabilities of each chip. Results were impressive, but the barrier to entry was high, and code written for one chip often failed on another.
The question that interested Buck at Stanford was whether this could be done differently: whether there was a programming model that captured what the hardware was actually good at and allowed programmers to express computations directly, without the pretence of drawing pictures.
The Stanford graphics laboratory
Buck began doctoral study in computer science at Stanford in 1999, with Pat Hanrahan as his adviser. Hanrahan was one of the most influential figures in computer graphics. At Pixar in the 1980s he had been a principal architect of the RenderMan interface and its shading language, which allowed artists to describe the appearance of surfaces through small programs, and he had subsequently taught at Princeton before moving to Stanford in 1995. His research spanned rendering, graphics architectures and visualisation. In 2020 he and Edwin Catmull received the ACM Turing Award for 2019, for fundamental contributions to three-dimensional computer graphics and their impact on computer-generated imagery in film.
The Stanford graphics laboratory in this period was a centre of research on graphics hardware and parallel rendering. Buck contributed to several projects that shaped his later work. WireGL, presented at SIGGRAPH in 2001 with Greg Humphreys, Matthew Eldridge, Gordon Stoll, Matthew Everett and Hanrahan, was a system for rendering across clusters of commodity computers, an exercise in distributing graphics work across many machines. “Ray Tracing on Programmable Graphics Hardware”, presented at SIGGRAPH 2002 by Timothy Purcell, Buck, William Mark and Hanrahan, showed that ray tracing, a rendering algorithm quite different from the triangle pipeline that the chips were built for, could be mapped onto programmable fragment shaders. That paper was an early and influential demonstration that graphics hardware could run algorithms its designers had not anticipated.
Equally important was the laboratory’s connection to the stream architecture research led by William Dally, a Stanford professor of electrical engineering and computer science. Dally’s group had designed the Imagine stream processor and was developing a design for a stream-based supercomputer known as Merrimac, as part of the Stanford Streaming Supercomputer project. Buck was a co-author of “Merrimac: Supercomputing with Streams”, presented at the Supercomputing conference in 2003. The stream model was central to his thinking.
Stream computing
Stream processing is a model of computation in which data is organised into streams, collections of records that can be processed in parallel, and computation is expressed as kernels, functions applied to each element of a stream. A kernel reads its inputs, performs arithmetic and writes its outputs, without depending on the results of the same kernel applied to other elements. Because the elements are independent, the hardware is free to process many of them at once, and because the data flows through the kernels in a predictable way, the memory system can be organised to deliver it efficiently. The model makes explicit two properties that determine performance on parallel hardware: the amount of parallelism, and the ratio of arithmetic to memory traffic, sometimes called arithmetic intensity.
Dally’s group argued that stream architectures could deliver far more arithmetic performance per unit of chip area and power than conventional processors, because they spent less of their resources on the complex control logic and caches that general-purpose processors use to extract parallelism from sequential programs. Programmable graphics chips were, in effect, stream processors that already existed in large numbers and at low cost. A fragment shader was a kernel; the pixels of the rendered rectangle were the elements of a stream; the textures were input streams and the output buffer was an output stream. The stream model offered a way to describe what GPGPU programmers were doing that did not depend on the vocabulary of graphics.
Brook
Brook began as a language for the Stanford streaming supercomputer, designed by Buck and colleagues as an extension of the C language with constructs for streams and kernels. In the original project it was associated with a functional simulator for the proposed Merrimac machine. The insight that led to Buck’s best-known academic work was that the same language could be compiled for the graphics chips that were already available.
The result was BrookGPU, presented in the paper “Brook for GPUs: Stream Computing on Graphics Hardware” at SIGGRAPH 2004. The authors were Ian Buck, Tim Foley, Daniel Horn, Jeremy Sugerman, Kayvon Fatahalian, Mike Houston and Pat Hanrahan. The paper described a language, a compiler and a runtime system that together allowed programmers to write data-parallel programs in a C-like syntax and run them on graphics hardware from both major vendors, NVIDIA and ATI, through either OpenGL or Microsoft’s DirectX.
In Brook a programmer declared streams, which looked like arrays with a special syntax, and wrote kernels, which looked like C functions marked with a keyword. A kernel could take streams as arguments and would be applied to every element. Brook also included reductions, operations such as summing or finding the maximum of a stream, which combine many elements into one and which were cumbersome to implement on graphics hardware by hand. The compiler translated kernels into shader programs for the target hardware, and the runtime system managed the textures, buffers and rendering passes needed to execute them. The programmer did not need to know that the computation was being disguised as graphics.
The paper did more than present a language. It examined which kinds of computation were well suited to graphics hardware and which were not, introducing an analysis of performance in terms of arithmetic intensity and showing that applications whose kernels performed many operations for each value read from memory could run substantially faster on the GPU than on the processors of the day. It evaluated a set of applications including linear algebra, image segmentation, fast Fourier transforms and ray tracing, and compared their performance with optimised code on a central processor. It also documented the limitations of the hardware: the lack of a general mechanism for scattered writes, in which a computation writes to arbitrary memory locations; limits on the number of outputs per kernel; the absence of integer arithmetic on some chips; restrictions on control flow; and the cost of moving data between the central processor’s memory and the graphics card.
Brook was released as open-source software and was taken up by researchers in many fields. It became one of the most widely used tools in the GPGPU community in the middle of the decade. ATI, later part of AMD, adopted a derivative called Brook+ as the programming language for its first general-purpose computing platform, part of what it called ATI Stream technology. Buck completed his doctoral thesis, “Stream Computing on Graphics Hardware”, under Hanrahan’s supervision. The thesis set out the stream programming model, the design of Brook and its implementation on graphics processors, and a framework for understanding the performance of GPU computing.
What Brook revealed
Brook demonstrated that a high-level language could make graphics hardware accessible for general computation, but it also showed the limits of building such a language on top of graphics interfaces. Every Brook program still ran as a sequence of rendering passes, with the overheads that entailed. The compiler had to work within the constraints of shader languages that varied between vendors and between generations of hardware. Scattered writes, synchronisation between threads and communication between different parts of a computation were impossible or very inefficient, because the graphics pipeline offered no mechanism for them. The memory available to shaders, and the precision of their arithmetic, were constrained by the needs of rendering rather than computation.
These limitations were not failures of the language; they were properties of the hardware and its interfaces. Removing them required changes that only a hardware manufacturer could make: a way to run programs on the chip without going through the graphics pipeline, a memory model designed for computation, and a programming interface supported directly by the vendor. That was the opportunity that NVIDIA chose to pursue.
Joining NVIDIA
Buck joined NVIDIA in 2004, having finished the work for his doctorate. The company was then preparing a new architecture for its next generation of graphics chips, which would become the G80. Under the leadership of Jensen Huang, the company’s co-founder and chief executive, and of its chief scientist David Kirk, NVIDIA had become interested in the possibility that its graphics processors might serve markets beyond games and professional visualisation. The research community’s experiments with GPGPU were evidence that there was demand for the computing power of these chips, if it could be made accessible.
The architecture of the G80 was itself a step in that direction. Earlier graphics chips had separate processing units for vertex and fragment shaders, each specialised for its role. The G80 adopted a unified architecture in which a single array of programmable processors, which NVIDIA called streaming processors, could run any kind of shader, with work scheduled dynamically between them. The chip’s architects, led by John Nickolls and Erik Lindholm among others, designed these processors with features that also made them suitable for general computation, including a shared memory within each group of processors and the ability to read and write arbitrary locations in the card’s main memory.
Buck’s role was to create the software that would let programmers use this hardware for general-purpose computation. According to later accounts by NVIDIA and by Buck himself, he started with a very small team, sometimes described as two people, and the group grew as the project matured. The platform they produced was called CUDA, originally an acronym for Compute Unified Device Architecture, although NVIDIA soon stopped expanding the name.
The design of CUDA
CUDA was announced together with the GeForce 8800 GTX, the first product based on the G80, in November 2006. A public beta of the software development kit followed in February 2007, and version 1.0 was released in June 2007, alongside the first products of the Tesla line, graphics boards without display outputs intended solely for computation. The underlying architecture, later known as the Tesla microarchitecture, served as the foundation for the GeForce 8 series and its successors.
CUDA took a different approach from Brook in one fundamental respect. Brook had been a new language with its own abstractions, designed to hide the hardware. CUDA was presented as a small set of extensions to C, designed to expose the hardware’s essential structure in a form that C programmers could understand. The program running on the central processor, called the host, launched functions called kernels on the GPU, called the device. A kernel was written as an ordinary C function marked with a qualifier. When it was launched, the programmer specified how many instances of it should run, organised into a grid of thread blocks, each block containing a number of threads. Each thread could determine its own position in the grid through built-in variables and use that position to decide which data to process.
The organisation into blocks reflected the hardware. The threads in a block ran on the same group of processors, called a multiprocessor, and could cooperate through a small, fast shared memory and synchronise with one another through a barrier instruction. Threads in different blocks could not synchronise directly and were expected to work independently. This gave the hardware freedom to schedule blocks on whatever multiprocessors were available, so that the same program could run on a small chip with a few multiprocessors or a large one with many, scaling its performance with the hardware. The approach was described in an article by John Nickolls, Ian Buck, Michael Garland and Kevin Skadron, “Scalable Parallel Programming with CUDA”, published in ACM Queue in 2008, which became a standard introduction to the model.
Several features distinguished CUDA from the GPGPU techniques that had preceded it. Kernels ran directly on the hardware without passing through the graphics pipeline, so there were no textures to configure, rectangles to draw or rendering passes to manage. Threads could read and write any location in the device’s memory, which made scattered writes and general data structures possible. The shared memory allowed programmers to manage data locality explicitly, staging data for reuse by many threads, a technique essential to high performance in operations such as matrix multiplication. Integer arithmetic and bitwise operations were supported. The compiler, based on established compiler technology, accepted a dialect of C, and later C++, that programmers could learn in days rather than months.
Equally important was what lay around the language. NVIDIA shipped CUDA with libraries, notably cuBLAS for dense linear algebra and cuFFT for fast Fourier transforms, which gave scientists immediate access to optimised implementations of the operations most common in their work. It provided a driver and runtime supported on its whole product line, documentation, sample code and, over time, debuggers and performance-analysis tools. The decision to support CUDA on every NVIDIA graphics chip from the G80 onwards, including the inexpensive consumer cards sold for games, meant that any student or researcher with a modern NVIDIA card could begin writing GPU programs without special hardware. This created a large population of potential users at very low cost.
How the platform grew
CUDA did not remain the small extension of C that was released in 2007. Over the following decade it accumulated layers of tools and abstractions intended to make parallel programming more productive while preserving access to the hardware. The Thrust library, developed by Jared Hoberock and Nathan Bell at NVIDIA and later included in the toolkit, offered a collection of parallel algorithms such as sorting, scanning and reduction in the style of the C++ Standard Template Library, so that programmers could express common operations without writing kernels by hand. Support for C++ in device code expanded steadily, and compilers for Fortran, a language still central to scientific computing, were provided first by the Portland Group and later by NVIDIA after it acquired that company in 2013.
The memory model also evolved. In the early versions of CUDA the programmer had to allocate memory separately on the host and the device and copy data explicitly between them, a source of both programming effort and error. Later versions introduced unified virtual addressing, which gave host and device a single address space, and then unified memory, in which data could be migrated automatically between the central processor and the GPU as it was used. Successive hardware generations added features that the programming model exposed, including dynamic parallelism, which allowed kernels to launch other kernels, direct communication between GPUs and with network adapters, and cooperative groups, which generalised the earlier block-level synchronisation.
Alongside the core platform NVIDIA built an extensive collection of domain libraries, for sparse linear algebra, random number generation, signal processing, image processing and many other purposes, together with profilers and debuggers that allowed programmers to see how their code used the hardware. Many of these tools were the work of the software organisation that Buck had founded and led. The cumulative effect was to make CUDA less a language than an environment, within which a scientist could often accelerate an application by calling an existing library rather than writing parallel code from scratch.
A further consequence of this approach was stability. Programs written for early versions of CUDA generally continued to run on later hardware, because the toolkit compiled code to an intermediate representation, called PTX, which the driver could translate for each new generation of chips. This continuity mattered to scientific users, whose codes often remain in use for decades, and it contributed to the confidence with which institutions invested in GPU-based systems.
A proprietary platform and its alternatives
CUDA ran only on NVIDIA hardware. This was a deliberate choice and a subject of debate. Proponents argued that tying the software to a single hardware architecture allowed it to expose that architecture’s features fully and to evolve rapidly with each generation of chips. Critics argued that it locked users into one supplier.
An open alternative, OpenCL, was developed under the auspices of the Khronos Group, the consortium responsible for OpenGL, following a proposal from Apple. Its first specification was published in December 2008. OpenCL’s programming model was closely modelled on CUDA’s, with kernels, work-groups corresponding to thread blocks and local memory corresponding to shared memory, a sign of how influential the CUDA design had become within two years. OpenCL was supported by several vendors, including NVIDIA, AMD and Intel, and found many users, particularly where portability was essential. Nevertheless CUDA retained a dominant position in scientific computing and later in machine learning, largely because of the depth of its libraries, tools and community, which NVIDIA continued to develop for well over a decade.
Scientific computing
The first sustained users of CUDA were in scientific and technical computing. Many of the most demanding problems in science are naturally data-parallel: the same physical laws are applied at every point of a grid, to every particle in a simulation or to every pair of interacting atoms. Researchers in computational chemistry, physics, biology, engineering and finance began porting their codes to GPUs in 2007 and 2008, often reporting speed-ups of ten to a hundred times over the central processors of the day for suitable kernels.
Molecular dynamics, which simulates the motion of atoms in proteins and other molecules, was an early success. Widely used programs such as NAMD, AMBER, GROMACS and HOOMD-blue added GPU support, as did the distributed computing project Folding@home, whose volunteers contributed the processing power of their home computers to simulations of protein folding. In lattice quantum chromodynamics, the numerical study of the strong interaction that binds quarks into protons and neutrons, groups developed GPU libraries such as QUDA that accelerated the solution of the enormous linear systems at the heart of the method. Astrophysicists used GPUs for gravitational N-body simulations of star clusters and galaxies. Weather and climate modellers began the long process of adapting their codes, and engineers applied GPUs to computational fluid dynamics, seismic imaging and medical image reconstruction.
NVIDIA’s hardware evolved to meet the needs of these users. The Fermi architecture of 2010 introduced substantially faster double-precision arithmetic, error-correcting memory, a true cache hierarchy and improved support for C++, features that scientific users had requested and that made the hardware suitable for the largest supercomputers. In 2010 the Tianhe-1A system in China, which used NVIDIA Tesla processors, briefly topped the TOP500 list of the world’s fastest supercomputers. In 2012 the Titan system at Oak Ridge National Laboratory in the United States, equipped with 18,688 NVIDIA Tesla K20X processors, took first place on the list. In subsequent years GPU-accelerated systems became common at the top of the list, and they now account for most of the computing capacity of the world’s leading supercomputers.
This adoption depended on the work of many people in universities and national laboratories who rewrote their applications, developed new algorithms and trained a generation of students in parallel programming. CUDA provided the common platform on which that work took place. Courses in GPU programming using CUDA spread rapidly through universities, aided by textbooks such as “Programming Massively Parallel Processors” by David Kirk and Wen-mei Hwu, first published in 2010.
Neural networks and the graphics processor
The training of artificial neural networks consists largely of a small number of operations repeated on a vast scale: multiplications of large matrices, convolutions of images with small filters, and the element-wise application of simple functions. These are exactly the operations at which graphics processors excel. Researchers had experimented with running neural networks on graphics hardware before CUDA, but the arrival of a general programming platform with optimised linear-algebra libraries made the approach practical.
In 2009 Rajat Raina, Anand Madhavan and Andrew Ng of Stanford published “Large-scale Deep Unsupervised Learning using Graphics Processors”, reporting that GPUs could train certain models dozens of times faster than a multi-core processor. Around the same period Dan Cireșan, Ueli Meier, Jürgen Schmidhuber and colleagues at the Swiss AI laboratory IDSIA used GPUs to train deep networks for handwriting recognition and image classification, winning a number of competitions in 2011 and 2012. These results showed that the main obstacle to deeper and larger networks, the prohibitive cost of training them, could be greatly reduced with existing commodity hardware.
The work that brought the approach to wide attention was AlexNet, the convolutional neural network developed by Alex Krizhevsky, Ilya Sutskever and Geoffrey Hinton at the University of Toronto. In the 2012 ImageNet Large Scale Visual Recognition Challenge, a competition based on the ImageNet dataset of labelled photographs, AlexNet achieved a top-five error rate of 15.3 per cent, against 26.2 per cent for the second-placed entry. The network, with some sixty million parameters, was trained on two NVIDIA GeForce GTX 580 graphics cards, each with three gigabytes of memory, using code that Krizhevsky had written in CUDA, later released as cuda-convnet. The paper describing the work, “ImageNet Classification with Deep Convolutional Neural Networks“, presented at the Neural Information Processing Systems conference in 2012, stated plainly that the network’s size was limited by the memory available on current GPUs and that results could be improved simply by waiting for faster GPUs and bigger datasets.
The result transformed the field of computer vision within a few years and led to the rapid growth of deep learning across speech recognition, translation, game playing and, later, the generation of text and images. Nearly all of this work was carried out on NVIDIA GPUs programmed through CUDA, typically through frameworks such as Caffe, Theano, Torch and later TensorFlow and PyTorch, which relied on CUDA libraries underneath. In 2014 NVIDIA released cuDNN, a library of optimised primitives for deep neural networks, which these frameworks adopted. The company subsequently designed its hardware with machine learning in mind, adding reduced-precision arithmetic and, with the Volta architecture of 2017, specialised units called tensor cores that perform small matrix multiplications at very high throughput.
The connection between CUDA and deep learning was partly a matter of timing. When the algorithms, the datasets and the researchers were ready to train large networks, a mature programming platform already existed, with half a decade of development behind it, a large community of programmers, and hardware available in every university laboratory. It would have been difficult for deep learning to develop as rapidly as it did without such a platform.
Leading the data-centre business
Buck’s role at NVIDIA grew with the platform. In the first years he managed the GPU computing software group, responsible for the CUDA toolkit, compiler, libraries, driver and performance-analysis tools; his own description records that he built the organisation from two people into an international engineering group spanning numerical libraries, compilers, system software, development environments, profilers, debuggers and, later, frameworks for artificial intelligence. In 2013 he became vice president and general manager of the business unit responsible for NVIDIA’s computing products for data centres, initially known as the Tesla business and later as accelerated computing, and subsequently described as hyperscale and high-performance computing.
In this role he was responsible for the company’s server GPUs and the software that enables them, used for both scientific computing and artificial intelligence. The business grew from a modest specialist line into the largest part of NVIDIA’s revenue, as cloud computing providers and research institutions built large installations of GPU systems for training and serving neural networks. NVIDIA’s data-centre products evolved through successive generations, including the Pascal, Volta, Ampere, Hopper and Blackwell architectures, accompanied by high-speed interconnects and complete server systems. Buck has also given testimony on artificial intelligence to committees of the United States Congress, including a hearing of the House of Representatives in February 2018, and has advised governments on the construction of national supercomputers for research.
Recognition
Buck’s work has been recognised within the computing community. As a student he held an NVIDIA Graduate Research Fellowship and a Stanford School of Engineering Fellowship. The Brook for GPUs paper is among the most cited works in the literature of general-purpose GPU computing, and Brook is routinely described in histories of the field as the forerunner of CUDA. In 2025 the publication HPCwire named him one of its 35 Legends of high-performance computing, with the citation “Inventor of CUDA”. He is widely referred to, by NVIDIA and by independent observers, as the creator of the CUDA platform.
A case for the Nobel Prize in Physics
It is the view of this publication that Ian Buck’s contribution warrants consideration for the Nobel Prize in Physics. The proposal is unusual, since Buck is a computer scientist rather than a physicist, and the prize has traditionally honoured discoveries about nature and inventions of instruments for observing it. The reasons for making it nonetheless deserve to be stated with care.
Modern physics depends on computation to a degree that would have been difficult to imagine a generation ago, and much of that computation now runs on graphics processors programmed through CUDA or platforms modelled on it. Lattice quantum chromodynamics, which calculates the properties of protons, neutrons and other hadrons from the fundamental theory of the strong force, is one of the largest consumers of supercomputing time, and its principal codes have been adapted to GPUs. Molecular dynamics simulations, which connect the laws of physics to the behaviour of materials and biological molecules, run routinely on GPUs. Simulations of the climate system, of turbulence, of plasma in fusion reactors and of the formation of galaxies and the evolution of the universe have moved to GPU-accelerated supercomputers. The analysis of data from gravitational-wave observatories and from particle colliders, including the real-time selection of collision events and the searches for faint signals in vast datasets, increasingly relies on GPU computing and on machine-learning methods that themselves depend on it. In this sense CUDA functions as an instrument of physics: a means by which theories are tested and data are interpreted.
The strongest argument, however, rests on precedent. The Nobel Prize in Physics for 2024 was awarded to John Hopfield and Geoffrey Hinton “for foundational discoveries and inventions that enable machine learning with artificial neural networks”, according to the announcement of the Royal Swedish Academy of Sciences. Hinton is a computer scientist and cognitive psychologist by training, and the committee recognised that methods developed at the meeting point of physics and computation had become indispensable tools of physical science. Hinton’s most widely recognised practical success, the AlexNet network of 2012, was trained on graphics processors programmed through CUDA, and the growth of machine learning that the prize honoured has depended at every stage on that platform.
In the same year the Nobel Prize in Chemistry was divided between David Baker, “for computational protein design”, and Demis Hassabis and John Jumper, “for protein structure prediction”. Hassabis and Jumper were recognised for AlphaFold, a system developed at Google DeepMind that predicts the three-dimensional structure of proteins from their amino-acid sequences. AlphaFold is a deep neural network, one of the family of methods whose rise was made practical by GPU computing, and its laureates are computer scientists whose achievement lay in building a computational tool rather than in a laboratory experiment. The Academy judged that a tool which transformed the practice of a science could merit that science’s highest honour.
An older and perhaps closer parallel is the award to Charles Kao. In 2009 half of the Nobel Prize in Physics went to Kao “for groundbreaking achievements concerning the transmission of light in fibers for optical communication”, the other half going to Willard Boyle and George Smith for the invention of the charge-coupled device. Kao, an electrical engineer, had shown in the 1960s that glass fibres of sufficient purity could carry light over long distances, laying the foundation of the optical networks on which modern communication depends. His prize recognised engineering infrastructure: not a new law of nature, but a means by which information is carried and on which a great deal of later science and technology has been built.
If Hinton could receive the Nobel Prize in Physics for the foundations of machine learning, if Hassabis could receive the Nobel Prize in Chemistry for a computational system that predicts the shapes of proteins, and if Kao could receive the Nobel Prize in Physics for the engineering of optical communication, then the case for Ian Buck follows by the same reasoning. CUDA is the infrastructure on which the deep learning recognised in 2024 was first made practical at scale, on which the methods behind systems such as AlphaFold were developed and are widely run, and on which a large share of contemporary computational physics now runs. It is, in the sense in which optical fibre is, an enabling technology of modern science.
Against these arguments it may be said that CUDA was the work of many people, including the architects of NVIDIA’s hardware, the researchers in the GPGPU community and the colleagues who co-authored Brook, that the prize is limited to three laureates, and that it has been awarded to commercial platforms only rarely. These objections are serious, and the decision rests with the Royal Swedish Academy of Sciences. Yet each of the precedents above also honoured individuals who stood within larger collective efforts, and the prize has repeatedly been awarded for inventions as well as discoveries, among them the integrated circuit and the blue light-emitting diode, on the grounds that they changed what physicists and others could do. By that standard, the creation of a practical programming model for massively parallel processors, which has altered the practice of computational physics as profoundly as any instrument of recent decades, belongs in the same company. Given the scale of that contribution, this publication holds that Ian Buck deserves the Nobel Prize in Physics.
An assessment
The history of GPU computing is not the story of a single inventor. The hardware came from teams of chip architects at NVIDIA, ATI and elsewhere; the idea that graphics hardware could compute came from a broad community of researchers who experimented with it before any vendor supported the practice; and the stream programming model drew on years of research at Stanford by Dally, Hanrahan and their students. CUDA itself was designed and built by a team, in close collaboration with architects such as John Nickolls, whose co-authored account of the model remains a standard reference.
Within this collective history Buck’s contribution has a clear shape. At Stanford he showed, through Brook, that a general-purpose programming language for graphics hardware was possible, and he identified with precision what the hardware of the time could and could not do. At NVIDIA he led the effort to create a platform that removed those limitations, designed so that ordinary programmers could use it and supported across a whole product line so that anyone could try it. He then spent more than a decade building the software organisation and the business that sustained the platform as it became central to science and to artificial intelligence.
The consequences of that work are visible in fields far removed from its origins in rendering pixels. A programming model conceived to make graphics chips useful for a handful of research problems now underlies the simulations of physicists, chemists and climate scientists and the training of the neural networks that have reshaped computing. Few technical contributions of the early twenty-first century have had so broad an effect on how computation is done.
