1 / 39

The Gewiz Language

Learn about the Gewiz language design considerations, lexical analyzer, parser, semantics, optimization, error handling, and the interface for programming graphics on the Nvidia GeForce3 video card.

lurbina
Download Presentation

The Gewiz Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related