art with code

2008-12-30

Some OpenGL renderer analysis

This is all hypothetical wanking to see what sort of performance I might expect from an OpenGL renderer for Filezoo. And with that disclaimer out of the way, on with it.

My goal is 60 frames per second. The application side of the drawing takes currently around 10 milliseconds, so the drawing side gets 6 milliseconds, making the effective drawing framerate target around 170 fps.

Fillrate of one gigapixel per second for single texturing sounds like a nice conservative estimate. The drawing area is 400x1000 pixels with maybe 25% overdraw, for a total of 500 kpixels per frame. Multiply by four for 4x FSAA and it's 2 Mpx per frame. At 1000 Mpx / second, 500 fps. Well above the 170 fps target.

For geometry, let's assume 40 million triangles per second. The maximum amount of files drawn by the renderer is currently at around 2000, each requiring four rectangles (three fill rectangles, one text rectangle.) Add in the group separators and lines, for maybe an extra two thousand rectangles, and we get the total amount of geometry per frame to be 10 kQuads, or 20 kTris. 20 kTris at 4000 kTris / second would give 200 fps, so the geometry side should work out ok as well.

Then, texture uploads. Suppose that we upload a full set of 2000 128x128x4 thumbnails to the graphics card. The amount of data transferred is 130 megabytes, and (IIRC) the bandwidth is 400-500 MB/s. So we can't plan on uploading the thumbnails on every frame and must have a texture manager. A graphics card is likely to have at least 128 megs of RAM, so if we use 120 megs for the texture cache and upload 10 megs per frame in the worst case, we should be able to sustain 40 fps. It might be worthwhile to crop the small thumbnails on the CPU, which'd make the maximum per-frame transfer be 128x2000x4 bytes, which comes in at 1 MB and sustains >400 fps.

The large thumbnails need to be mipmapped for nice rendering. Doing it with the GL texture mipmap generation extension might be perceptible as it does happen in the drawing thread. Generating the mipmaps at thumbnail load time, keeping them on the CPU, and uploading them manually is likely to cause less drawing latency.

Bringing it all together, a 20 kTri frame of 0.5 Mpx and 1 MB texture uploads would take 5 ms for drawing (1 / min(200 fps, 500 fps)) and 2.5 ms for the texture upload. Giving us a guesstimate worst-case drawing performance of 7.5 ms per frame, and 17.5 ms per frame with the application drawing logic. Which would plonk the framerate to 30 vsynced frames per second. Which I probably can salvage by making the app side faster by 1.5 ms.

So. Yeah. It does sound doable to do the OpenGL side of the drawing fast enough to get 60 fps. Now to see if I can get Tao.OpenGL working. And then theory hits practice for 3d5+3 lightning damage.
Post a Comment

Blog Archive

About Me

My photo

Built art installations, web sites, graphics libraries, web browsers, mobile apps, desktop apps, media player themes, many nutty prototypes, much bad code, much bad art.

Have freelanced for Verizon, Google, Mozilla, Warner Bros, Sony Pictures, Yahoo!, Microsoft, Valve Software, TDK Electronics.

Ex-Chrome Developer Relations.