The Gewiz Language

1. The Gewiz Language Kyle Hegeman Chris Beckenbach Laura Grier CIS6930CT

2. Overview • Background on Nvidia GeForce3 • Gewiz Language Design Considerations • Lexical Analyzer • Parser • Semantics • Optimization of Temporary Registers • Error Handling • Interface for the Assembler • Program Demo

3. Background • Nvidia Geforce3 and the ATI Radeon 7500+ cards contain a Graphics Processing Unit (GPU). • The GPU can be programmed to customize the graphics processing being performed by the card.

4. The GPU • Programmed via an assembly language interface • The instruction set to perform all vertex math • Reads an untransformed, unlit vertex • Creates a transformed vertex • Optionally • Lights a vertex • Creates texture coordinates • Creates fog coordinates • Creates point size

5. OpenGL Interface • An OpenGL extension created by Nvidia is used to download the program to the GPU • To executed a program you enable the program and then draw vertices as normal. • The card will execute the program once per vertex • Data is passed to the card through a set of standard set of input registers and a set of user defined parameter registers • Data is returned through a set of output registers

6. Goal • The goal of the project is to create a high level language to program graphics on the GeForce video card. DP4 R0.x,v[OPOS],c[0]; - ModelView transformation DP4 R0.y,v[OPOS],c[1]; - ModelView transformation DP4 R0.z,v[OPOS],c[2]; - ModelView transformation DP4 R0.w,v[OPOS],c[3]; - ModelView transformation DP4 R1.x,R0,c[4]; - Projection transformation DP4 R1.y,R0,c[5]; - Projection transformation DP4 R1.z,R0,c[6]; - Projection transformation DP4 R1.w,R0,c[7]; - Projection transformation DP3 R2.x, c[0], v[NRML]; DP3 R2.y, c[1], v[NRML]; - Normal transformation DP3 R2.z, c[2], v[NRML]; - Normal transformation DP3 R2.w, c[8], R2; - Lighting calculation MUL R3.xyzw,v[COL0].xyzw,R2.wwww; -Lighting calculation MOV o[COL0],R3; - Output MOV o[HPOS],R1; - Output

7. Gewiz Language Design Considerations • What type of Language should it be? • At first, the group leaned toward a functional language, but the need for variables to represent registers made this impossible, so the Imperative Language Design was followed. • Compilation Implementation Method • The hardware requires assembly code generation

8. Influences on Gewiz Design • Readability • Writability • Reliability • Cost • Portability

9. Readability • Simplicity • Language has a few basic components • No feature multiplicity • Only one way to accomplish operations • Orthogonality • Language has three data types that build on each other • Floats • Vectors • Matrices • The same operators can be used with many of these

10. Readability • Control Statement • Program flow is from top to bottom • Only assignment statements are used • Data Types and Structures • The data types can be defined and assigned in one statement, each beginning with a special character throughout the program for enhanced readability.

11. Readability • Syntax Considerations • No restriction on identifier length. • Special Words • end is used along with the program name for enhanced readability • end main;

12. Writability • Simplicity and Orthogonality • There are few data types, operations, and pre-defined functions to learn • A pre-defined function accepts multiple data types • An operation takes multiple operand types for the same operator • Abstraction • Given in the form of predefined functions and operators • Expressivity • Enhanced through operator overloading ‘a * “b (vector * matrix) %a * %b (floats)

13. Reliability • Type checking is done on all operands. • Type checking is done on parameters of functions. • No exception handling is done. • Range checking is done at compile time • Uninitialized variables are caught when improperly used • Aliasing is used • Although considered a deterrent to readability, “shape seemed more readable and more easily remembered than matrix(3 to 7), which represents a set of input registers.

14. Cost • This is a small language, so training, time to write programs, and maintenance is minimal. • Special hardware is required for the developers and end users. • The compiler and interface is free.

15. Portability • Gewiz is portable to FreeBSD, Linux, and Win32 • There is an OpenGL driver limitation for the video card limiting it to Win32/Linux.

16. Lexical Analyzer • Separation of the lexical analysis and parsing was done using flex and bison, which created the following benefit: • Simplified the lexical analyzer • Issues associated with lexical analysis • Determining where white space is allowed • Since keywords such as float, vector, and matrix aren’t used to specify the data types (this is specified using “,’,% and input and output vector keywords): • Separate tokens were created for floats, vectors, and matrices, as well as output vectors and input vectors • Symbol table entries and some attributes were specified at the lexical analysis phase, since this could not be determined from parsing

17. Parser • First, a grammar was created to be used in bison • As a result of bison using a bottom-up parsing technique: • Leftmost recursion was used in the grammar • Semantics use synthesized attributes • Implementation issues • Lack of temporary registers • Allowance of access of up to 4 floats at a time and vectors within matrices requires changing of identifier types within the parsing process • As a result, we were unable to use rules that included an or with an empty set in bison

18. Semantics • A static semantic check is done for the program name: • vertex_program practice(): • end practice; • The other semantic rules are handled as synthesized attributes, which are passed up the parse tree by assigning types to non-terminals • This is unnecessary for type checking of parameters, which is done in the pre-defined function definition.

19. Temporary Registers • Most limited resource • Only 12 available, R0..R11 • 3 4x4 matrices • 4 3x3 matrices • 12 vectors • 1 4x4 matrix, 2 3x3 matrix and 2 vectors • …

20. Reclaiming Registers • Free up a temporary register as soon as possible for other uses • Two methods to do this • Dead Code removal • Operation ordering

21. Dead Code Removal • Only values stored in output registers available to calling program • Remove any operations that do not lead to a value being stored in output registers

22. Example • Original !!VP1.0 MUL R2, v[NRML], c[8].wwww MOV o[HPOS], c[3] END

23. Example • Dead Code removed !!VP1.0 MOV o[HPOS], c[3] END

24. Cascading Removal • Example !!VP1.0 ADD R1, -v[NRML].wzyx MUL R2, v[OPOS], R1.wwww MOV o[HPOS], c[3] END

25. Operation Ordering • Goal: Hold values in temporary registers for as short a time as possible. • Only needs to be “good enough” • Problems: • Dependencies between operations • NP – basically a “shortest route” problem

26. Example • Original !!VP1.0 MUL R2, v[NRML], c[8].wwww MOV o[COL0], c[3] MUL o[HPOS], -R2, v[OPOS] END

27. Example • Reordered !!VP1.0 MUL R2, v[NRML], c[8].wwww MUL o[HPOS], -R2, v[OPOS] MOV o[COL0], c[3] END

28. Dependencies • Dependency violated !!VP1.0 MUL o[HPOS], -R2, v[OPOS] MUL R2, v[NRML], c[8].wwww MOV o[COL0], c[3] END

29. Error Handling • Syntax Errors • Implemented with flex, when an invalid lexeme is scanned in. • Parse Errors • Implemented with bison, when the order of the tokens does not fit the order specified by the grammar rules. • Semantic Errors • Static semantic checks • Type checking as synthesized attributes • Type checking for parameters of pre-defined functions

30. Error Handling • Out of bounds errors • Input registers (floats, vectors, matrices) • Temporary matrices (3x3) vs. (4x4) • Uninitialized variable errors • Created when variables are used on the right hand side of an assignment statement even though they have not been assigned a value yet.

31. Demos • These two programs are Gewiz ports of programs created by Richard Nutty. His web site is http://www.nutty.org. • The first is simply entitled “vertex program” and is designed to be a simple sample. • The next is called “toon shade”.

32. Vertex ProgramOriginal Assembly Source DP4 R0.x,v[OPOS],c[0]; - ModelView transformation DP4 R0.y,v[OPOS],c[1]; - ModelView transformation DP4 R0.z,v[OPOS],c[2]; - ModelView transformation DP4 R0.w,v[OPOS],c[3]; - ModelView transformation DP4 R1.x,R0,c[4]; - Projection transformation DP4 R1.y,R0,c[5]; - Projection transformation DP4 R1.z,R0,c[6]; - Projection transformation DP4 R1.w,R0,c[7]; - Projection transformation DP3 R2.x, c[0], v[NRML]; - Normal transformation DP3 R2.y, c[1], v[NRML]; - Normal transformation DP3 R2.z, c[2], v[NRML]; - Normal transformation DP3 R2.w, c[8], R2; - Lighting calculation MUL R3.xyzw,v[COL0].xyzw,R2.wwww; -Lighting calculation MOV o[COL0],R3; - Output MOV o[HPOS],R1; - Output

33. Vertex Program Gewiz Source Vertex_program main(): output_color0 = input_color0 * (Vector(8) dot (input_normal * Matrix(0 TO 2))); output_position = input_position * Matrix(0 TO 3) * Matrix(4 TO 7); end main;

34. Vertex ProgramGewiz Assembler Source DP3 R0.x , v[NRML] , c[0]; DP3 R0.y , v[NRML] , c[1]; DP3 R0.z , v[NRML] , c[2]; DP3 R1.w , c[8] , R0; MUL R2 , v[COL0] , R1.w; MOV o[COL0] , R2; DP4 R3.x , v[OPOS] , c[0]; DP4 R3.y , v[OPOS] , c[1]; DP4 R3.z , v[OPOS] , c[2]; DP4 R3.w , v[OPOS] , c[3]; DP4 R4.x , R3 , c[4]; DP4 R4.y , R3 , c[5]; DP4 R4.z , R3 , c[6]; DP4 R4.w , R3 , c[7]; MOV o[HPOS] , R4;

35. Original Toon Shade Assembler DP4 R0.x,v[OPOS],c[0]; - ModelView transformation DP4 R0.y,v[OPOS],c[1]; - ModelView transformation DP4 R0.z,v[OPOS],c[2]; - ModelView transformation DP4 R0.w,v[OPOS],c[3]; - ModelView transformation DP4 o[HPOS].x,R0,c[4]; - Projection transformation. Store immediatly in output. DP4 o[HPOS].y,R0,c[5]; - Projection transformation DP4 o[HPOS].z,R0,c[6]; - Projection transformation DP4 o[HPOS].w,R0,c[7]; - Projection transformation DP3 R2.x, c[0], v[NRML]; - Normal transformation DP3 R2.y, c[1], v[NRML]; - Normal transformation DP3 R2.z, c[2], v[NRML]; - Normal transformation ADD R3,c[9],-R0; - Get Vector from eye to vertex. DP3 R3.w,R3,R3; - Get magnitude of vector. RSQ R3.w,R3.w; - Calculate reciprocal square root. MUL R3,R3,R3.w; - Multiply by recip square root. To make it normalized. DP3 o[TEX0].x,R2,c[8]; - Dot product of normal, light vector, tone lookup. DP3 o[TEX1].x,R2,R3; - Dot product of normal, eye vector, outline lookup. MOV o[COL0],v[COL0]; - Mov input color straight into output color.

36. Toon Shade – GeWiz vertex_program main(): 'pos = input_position * Matrix(0 TO 3); output_position = 'pos * Matrix(4 to 7); 'norm = input_normal * Matrix(0 TO 2); output_texture0.x = 'norm dot Vector(8); output_texture1.x = 'norm dot normalize(Vector(9) - 'pos); output_color0 = input_color0; end main;

37. Toon ShadeGewiz Assembler Source DP4 R1.x , v[OPOS] , c[0]; DP4 R1.y , v[OPOS] , c[1]; DP4 R1.z , v[OPOS] , c[2]; DP4 R1.w , v[OPOS] , c[3]; MOV R0 , R1; DP4 R2.x , R0 , c[4]; DP4 R2.y , R0 , c[5]; DP4 R2.z , R0 , c[6]; DP4 R2.w , R0 , c[7]; MOV o[HPOS] , R2; DP3 R4.x , v[NRML] , c[0]; DP3 R4.y , v[NRML] , c[1]; DP3 R4.z , v[NRML] , c[2]; MOV R3 , R4.xyz; DP3 R5.w , R3 , c[8]; MOV o[TEX0].x , R5.w; ADD R6 , c[9] , -R0; DP3 R7.w, R6 , R6; RSQ R7.w,R7.w; MUL R7 , R6 , R7.w; DP3 R8.w , R3 , R7; MOV o[TEX1].x , R8.w; MOV o[COL0] , v[COL0];

38. Conclusion • The Gewiz Language provides some advantages over the original assembly code required for the GeForce card • Enhanced readability and writability • Resulting in fewer lines of high level code • More sophisticated data types • Allowing for operator overloading • Resultant Disadvantages • All the features of the original assembly code are not supported due to lack of funding and time constraints • Generated code may not be as optimized as hand written assembly code

39. References • Nvidia Developer Documentation • http://developer.nvidia.com • Demos by Nutty • http://www.nutty.org