OpenGL Shading Language Jian Huang CS594 Spring 2005 Why the need Until late 90 s when it comes to OpenGL programming hardware accelerated graphics an analogy as below was mostly true A machinery operator turns a few knobs and sets a few switches and then push a button called render Out of the other end of a magical black box images come out All the controls offered by the OpenGL API comes as just knobs and switches Although knowing more about the intrinsic OGL states one could become a professional knob operator and achieve better performance but few new functionality could the operator discover Why the need cont But the graphics industry is mostly driven to create new and newer effects so to get more leverage on graphics hardware programmers started to perform multi pass rendering and spend more and more time to tweak a few standard knobs for tasks beyond the original scope of design e g to compute shading using texture transformation matrices to combine multi texture unit lookups using equations beyond just blending or modulating Software Renders During the early days of graphics special effects creation when there was no OpenGL Pixar developed their own in house software renderer RenderMan What s unique about RenderMan is its interface that allows highly programmable control over the appearance of each fragment This part of RenderMan was later opened up to public and is nowadays widely known as RenderMan shading language Cg When graphics hardware vendors started to develop an interface to expose inner controls programmability of their hardware Like the birth of every domain specific programming scripting language a shading language seemed to be a logical choice nVidia was the first vendor to do so and their shading language is called Cg Cg was an immense success and became a widely adopted cutting edge tool throughout the whole industry OpenGL Shading Language GLSL A few years after the success of Cg in loom of a highly diverse and many times confusing set of languages or extensions to write shaders with the industry started its effort of standardization The end result is OpenGL Shading Language which is a part of the OpenGL 2 0 standard GLSL is commonly referred to as GLslang GLSL and Cg are quite similar with GLSL being a lot closer to OpenGL The Graphics Pipeline If GLSL and Cg are both just an interface what do they expose The graphics pipeline Here is a very simplified view Fixed Functionality Vertex Transformation A vertex is a set of attributes such as its location in space color normal texture coordinates etc Inputs individual vertices attributes Operations Vertex position transformation Lighting computations per vertex Generation and transformation of texture coordinates Fixed Functionality Primitive Assembly and Rasterization Inputs transformed vertices and connectivity information Op 1 clipping against view frustum and back face culling Op 2 the actual rasterization determines the fragments and pixel positions of the primitive Output position of the fragments in the frame buffer interpolated attributes for each fragment Fixed Functionality Fragment Texturing and Coloring Input interpolated fragment information A color has already been computed in the previous stage through interpolation and can be combined with a texel Texture coordinates have also been interpolated in the previous stage Fog is also applied at this stage Output a color value and a depth for each fragment Fixed Functionality Raster Operations Inputs pixels location fragments depth and color values Operations Scissor test Alpha test Stencil test Depth test Fixed Functionality A summary common jargons T L Texturing etc Replacing Fixed Functionalities Vertex Transformation stage vertex shaders Fragment Texturing and Coloring stage fragment shaders Obviously if we are replacing fixed functionalities with programmable shaders stage is not a proper term any more From here on let s call them vertex processors and fragment processors Vertex Processors The vertex processor is where the vertex shaders are run Input the vertex data namely its position color normals etc depending on what the OpenGL application sends A piece of code that sends the inputs to vertex shader glBegin glColor3f 0 2 0 4 0 6 glVertex3f 1 0 1 0 2 0 glColor3f 0 2 0 4 0 8 glVertex3f 1 0 1 0 2 0 glEnd Vertex Processors In vertex shaders sample tasks to perform include vertex position transformation using the modelview and projection matrices normal transformation and if required its normalization texture coordinate generation and transformation lighting per vertex or computing values for lighting per pixel color computation Note it is not required that your vertex shader does any particular task no matter what vertex shader is provided you have already replaced the entire fixed functionality for vertex transformation stage Vertex Processors The vertex processor processes vertices individually and has no information regarding connectivity no operations that require topological knowledge can t be performed in here for example no back face culling The vertex shader must write at least a variable gl Position often transforming with modelview and projection matrices A vertex processor has access to OpenGL states so it can do lighting and use materials A vertex processor can access textures not on all hardware A vertex processor cannot access the frame buffer Fragment Processors Inputs the interpolated values computed in the previous stage of the pipeline e g vertex positions colors normals etc Note in the vertex shader these values are computed per vertex Here we re interpolating for the fragments When you write a fragment shader it replaces all the fixed functionality The programmer must code all effects that the application requires A fragment shader has two output options to discard the fragment hence outputting nothing to compute either gl FragColor the final color of the fragment or gl FragData when rendering to multiple targets Fragment Processors The fragment processor operates on single fragments i e it has no clue about the neighboring fragments The shader has access to OpenGL states Note a fragment shader has access to but cannot change the pixel coordinate Recall that modelview projection and viewport matrices are all used before the fragment processor Depth can also be written but not required Note the fragment shader has no access to the framebuffer Operations such as blending occur only after the fragment shader has run Using
View Full Document
Unlocking...