COMP9018 - Advanced Graphics Advanced Graphics: Performance.

COMP9018 - Advanced Graphics

Advanced Graphics: Performance


Performance Optimisation in OpenGL

• Some quotes on optimisation:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

- Donald Knuth

"Rules of Optimization:Rule 1: Don't do it.Rule 2 (for experts only): Don't do it yet."

- M.A. Jackson


But in graphics ...• Frequently, performance is critical to

utility/value.• Working on the edge of the possible.• So may have to optimise.• Systems are engineered for

optimisation.


Making things run faster• Approaches to optimisation

– Use faster hardware– Right data in the right place at the right time– Getting rid of redundant calculations– Tricking the eye ("close enough is good enough")– Trading space for time– Not drawing (elimination of what wouldn't be seen

anyway)– Writing it in assembly/C (but very rarely, usually

last)


Hardware acceleration• Can be a good option. • Problem: Price-performance curve is

exponential Price vs Performance

0

100

200

300

400

500

600

700

800

900

1000

0 1 2 3 4 5 6 7

Pixel Fill Rate

AU

D

GeForce 6800 Ultra

GeForce 5500


More on hardware acceleration

• Implication: It's easy to get very good performance using hardware accel, but it gets extremely expensive when trying to obtain excellent performance.

• Don't forget Moore's law.• Interaction between long development

times & Moore's law means sometimes problem "fixes itself".


Right data in the right place

• One of the best techniques• The basis of caching • Exploits “locality” -- likely to reuse the

same information again and again• Two types:

– Temporal– Spatial


Another way to think of OpenGL

• OpenGL can be thought of as a client-server architecture

• Some examples of client-server:– The Web– X windows

• When did we ever say that the client and server were on the same machine?

• OpenGL can run on a network


Client-server concept• The program that makes API calls is the client• The OpenGL implementation is the server• The client sends requests to the server• Client and server may be different machines -

e.g. client is big mainframe spewing OpenGL commands; server is a PC with hardware acceleration

• Still convenient to think of as client = my program, server = OS/driver/graphics card


Client-server concept• Client-server concept is still useful

on a single machine.• Intuition: Client is your program,

server is your graphics card • Why is it useful concept? Important

from a performance point of view. Different performance if data is stored at client or server.


Right place at the right time

• This is where the client server stuff comes in.

• Now have graphics cards with 512MB on board.

• What use is it?• Once data is on the graphics card,

everything is faster.• Problem: Once it's on the graphics card, it

can't (easily) be modified.


Display lists • A very simple way to speed up

OpenGL.• Idea: Take almost any sequence of

OpenGL commands, and package them up; then you can use them like macros.

• Other libraries have similar concepts. e.g DX has "execute buffers".


When and why • Why?

– Convenience: give something akin to a function calling structure but more efficient.

– Efficiency: hardware can optimise, reduces function call overhead, data can live on the graphics card

• When?– What you want to render is unlikely to change – When you are reusing structure– When you need speed


Initialisation• 3 steps: Initialise, define, use. • Get a display list ID (actually an int)

using glGenLists(size) • Can request more than one list at a

time. • Returns an int you can use. Return 0

if none available


Definition• Like glBegin() and glEnd()• glNewList(index, GL_COMPILE)• ... code for rendering things ...• glEndList();• Instead of GL_COMPILE, can be

GL_COMPILE_AND_EXECUTE


Use• To render stuff, use glCallList(index)• IMPORTANT NOTES:

– Almost anything can go in a display list: matrix ops, material defs, textures, geometry, lights, whatever ...

– Display lists COPY data: you can't modify the data once it's in a display list, even if it's a reference (i.e. e.g. if you use gl*fv(object), it won't notice when object changes).

– Display lists affect and are effected by the current matrix stack values!!


What CAN'T you call for a DL

• Some things not allowed:– Anything that asks about the current

state.– Anything that changes the rendering

mode. – Anything that makes or deletes a list

(but calling another display list is fine - can use this to build a hierarchy)


Code example• Look at nodisplaylist.c vs displaylist.c• Conclusion

– Likely to be much faster, since data lives on graphics card.

– Not much effort.


Redundant calculations• Also very important optimisation

technique.• Closely related to locality idea.


0

1

3

2

0

1

3

2

0

3

2

0

3

2

0

1

3

2

0

1

3

2

0

3

2

0

3

2 5

4

76

glBegin(GL_QUAD);glVertex3f(x0,y0,z0);glVertex3f(x1,y1,z1);glVertex3f(x2,y2,z2); glVertex3f(x3,y3,z3);

glEnd();glBegin(GL_QUAD);

glVertex3f(x1,y1,z1); glVertex3f(x5,y5,z5);glVertex3f(x6,y6,z6); glVertex3f(x2,y2,z2);

glEnd();

Redundant calculations

• An example: Vertex arrays. • Consider rendering a cube in

OpenGL.


Answers: 24, 8, 67 per cent

Question • How many points are transformed and lit

in previous rendering of cube?• How many points would minimally have to

be transformed and lit in previous rendering?

• How much calculations are wasted?


Huge waste!• Same calculations are repeated. • How to solve?• Use indexed face set data structure. • Consists of two lists:

– A list of coordinates.– A list of polygons = a list of lists of

vertex indices.


Cube example• float vertices[][] = {{x0,y0,z0},

{x1,y1,z1}, {x2,y2,z2}, ..., {x7,y7,z7}};• int faces[][] = {{0,1,2,3}, {0,5,6,2}, ...,

{4,5,6,7}};

• But what about other data, e.g. surface normals?

• Need to store them too.


Problem: Needs API support

• To do this efficiently, API needs to support such an approach.

• Any good graphics API (e.g. OpenGL, DX8, Inventor, VRML97, etc) supports this.

• Have various names.• In OpenGL, called a vertex array.


Using Vertex Arrays• Can have up to 6 different arrays, for:

– Vertex coordinates– Normals– Colours– Texture coordinates– A few other funky ones: index, edge flag

• Enable which ever arrays you need• glEnableClientState(GL_VERTEX_ARRAY)


Step 2• After initialising, tell it where the data lives• e.g. glVertexPointer(size, type, stride,

vertices);• Size is number of values per vertex (typ. 2, 3

or 4)• Type = GL_FLOAT or whatever • Stride is for more funky stuff (e.g. interleaved

arrays)• Similar calls for glNormalPointer,

glTexCoordPointer etc


Step 3: Access the data• Lots of different ways to call. Simplest:

glArrayElement(index).• Action depends on what's enabled, but let's

say only vertex arrays are enabled. Then this looks up index in the last thing glVertexPointer was called on (say x) and does glVertex3f(x).

• If normal arrays were enabled,(and normal for index was y) this would do: glNormal3f(y); glVertex3f(x);

• NOTE: belongs between glBegin, glEnd.


Bunches of indices• Can also give multiple points at

once: use glDrawElements(mode, count, type, indices).

• Mode is GL_LINE, GL_POLYGON, etc.• Count is number of indices• Type is usually GL_UNSIGNED_INT• NOTE: Does NOT go between a

glBegin/glEnd


glDrawElements• Functionally equivalent to:• glBegin(mode);

for(i=0; i < count; i++) glArrayElement(indices[i]);

• glEnd();

• glDrawRangeElements() is similar, but you specify a constrained range of indices.


What does OpenGL do?• Can cache previously transformed

vertices• Can use glDrawRangeElements to help

tell OpenGL what's going to change• glDrawElements can draw lots of

objects. Example: if all polys have four vertices, then use GL_QUADS instead and can give list of 24 vertices.


Vertex Buffer Objects• “Right stuff at right time”• Problem: Vertex arrays are client

side.• How to speed up?• Put vertex array on server side?• What is the disadvantage?


OpenGL 2.0• Vertex buffer objects – very new. • Idea: Push vertex array to server• Simple to use:

– glGenBuffers() to ask for a buffer– glBindBuffer() to make it the current

context– glBufferData() specifies the data– Then use the usual commands


glBufferData• glBufferData(target, size, data, usage)• Most are obvious, but usage?

– Used to control how buffer gets treated– Static vs stream vs dynamic– Read vs Copy vs Draw

• Can also use glMapData to modify the data


Code Example• vertexarray.c• Note: can mix and match normal

with vertex arrays.


Practical implications• You CAN use display lists and vertex

arrays at the same time, but it's a bit tricky.

• When you change data in a vertex array, and render immediately, that's fine. But with a display list, the data is copied.

• Example: Say you have a creature with constantly moving body. Can't use a a display list.

• But can use, for say, a helmet; or a head.


Space-time tradeoff• Sometimes, can use more space to make

algorithm faster or vice versa. • E.g. can sometimes precompute values if

they will be reused alot. • Trading space for time example:

precomputing sin/cos tables.• Trading time for space example:

compressed textures (but really still about time).


Tricking the eye• Lots of examples in what you've already

studied.• E.g. Gouraud shading is nonsense

theoretically.• Strictly Gouraud shading should be

perspective-corrected.• Not noticeable for Gouraud, but IS

noticeable for texture maps.


Not rendering things• Back face culling: not drawing polygons

facing away from us. • Easy to enable in OpenGL:

glEnable(GL_CULL_FACE)• But lots of other examples: e.g. using

visibility trees (similar to BSP trees) and portal systems to cut back on polygons. Any coincidence games are indoors? (more later)

• Also the multires stuff and LOD (more later)


Rewriting code• Usually the last resort.• Usually the big gains are in algorithmic

improvement, not rewriting code more efficiently or re-implementing in C/Assembly.

• Assembly less significant with RISC processors.

• Very time consuming both initially and long-term.


Profiling• Profiling is analysing software as it runs to

see how much time executing different parts of code.

• General observation: 90 per cent of time spent executing 10 per cent of code.

• Pointless optimising wrong thing. • Example: Say you improve code outside

top 10 per cent by 100 per cent. Will only make program run 5 per cent faster.


Bottlenecks• Profiling frequently reveals the bottleneck (the

thing that slows everything down). Type of bottleneck suggest solution.

• Typical bottlenecks:– Fill-limited: Rasterising/texturing polygons. Occurs

with software renderers.– Geometry-limited: Calculations of geometry. Too

many polygons/vertices. – Client-side limited: Calculations on client side (e.g. of

vertex/texture coordinates). Code optimization? Maybe


Demo• Profiling

COMP9018 - Advanced Graphics Advanced Graphics: Performance.

Documents

Transcript of COMP9018 - Advanced Graphics Advanced Graphics: Performance.