1. Field of the Invention
Embodiments of the present invention relate generally to graphics processing and more specifically to processing of a geometry shader program developed in a level-high shading language.
2. Description of the Related Art
Over the past decade, the cost of adding on-chip logic to processors has substantially decreased. Consequently, certain types of processors, such as advanced graphics processing units (GPUs), now include functionality not previously available in earlier GPU designs. For example, the newest GPUs are now able to perform geometry processing operations; whereas, such operations traditionally had been left to the central processing unit (CPU). One benefit of this shift in responsibilities is that more graphics processing may now be performed on the GPU instead of the CPU, thereby reducing performance bottlenecks in the graphics pipeline.
To fully realize additional processing capabilities of advanced GPUs, as much GPU functionality as possible needs to be exposed to application developers. Among other things, doing so enables application developers to tailor their shader programs to optimize the way GPUs process graphics scenes and images. Exposing new GPU processing capabilities, like geometry processing, to application developers requires that the application programming interface (“API”) be configured with new calls and libraries that make new features and functionalities directly accessible by developers.
FIG. 1 is a conceptual diagram illustrating a prior art programming model, 100, availing the processing capabilities of a GPU, 106, to application 102. GPU 106 is typically configured to read and operate on a stream of input elements as those elements flow through graphics rendering pipeline 108. Graphics rendering pipeline 108 includes a series of processing units, each configured to carry out different functions of rendering pipeline 108, where the output of one processing unit is the input to the next processing unit in the chain. Some processing units shown in programming model 100 are programmable, such as vertex processing unit 130 and fragment processing unit 136, and are capable of executing one or more instances of compiled shading programs in parallel. Other processing units perform fixed functions, such as a fixed-function primitive assembler 132, a fixed-function geometry processor 133, and a rasterizer 134.
With GPU driver 104 supporting compiler 114, GPU microcode assembler 116, and GPU microcode assembler 118, specialized application 102, such as vertex shader program 110 or fragment shader program 112, can be written in a high-level shading language (e.g., the High Level Shader Language for Direct3D or the OpenGL™ Shading Language) tailored to one of these programmable processing units. Vertex shader program 110 is generally constructed using unified program instructions and with self-contained variables and functions. Likewise, fragment shader program 112 is constructed using unified program instructions and also with self-contained variables and functions. Compiler 114 optionally translates these high-level shading programs into distinct software objects of vertex shader assembly code 116 and fragment shader assembly code 118. Based on the translated assembly code, GPU microcode assemblers 120 and 122 then generate vertex shader microcode 124 and fragment shader microcode 126, respectively, for GPU 106. It should be noted that compiler 114 may reside outside of GPU driver 104 in other prior art programming models.
One drawback of the aforementioned programming model 100 is the lack of programmability for certain components in rendering pipeline 108. For instance, since rendering pipeline 108 lacks a programmable processing unit in between vertex processing unit 130 and fragment processing unit 136, application 102 is unable to manipulate or process the output data of vertex processor unit 130 until that data reaches fragment processing unit 136. Another drawback of programming model 100 is the potential inefficiencies relating to developing and deploying separate domain-specific shader programs, because application developers need to rationalize the various shader programs they develop.
As the foregoing illustrates, what is needed in the art is a programming model that exposes new programmability and processing capabilities of GPUs, such as the ability to program and perform geometry processing operations, and enables efficient development of the various shader programs that execute within the different domains of the rendering pipeline.