dabroz.scythe.pl

Recently we've got a nice extension: ARB_debug_output.

It allows OpenGL implementations to provide more detailed errors and warnings. To be honest, person that invented glGetError (and consided it a reasonable debugging method) must have been mad or completely drunk. Am I over exaggerating? If you think so, try to fix your car using only one six-color LED diode. And I'll repeat once more: software engineering, and specifically graphics programming is not a goddamn MasterMind game.

Recently we've got a nice extension: ARB_debug_output.

It allows OpenGL implementations to provide more detailed errors and warnings. To be honest, person that invented glGetError (and consided it a reasonable debugging method) must have been mad or completely drunk. Am I over exaggerating? If you think so, try to fix your car using only one six-color LED diode. And I'll repeat once more: software engineering, and specifically graphics programming is not a goddamn MasterMind game.

Recently we've got a nice extension: ARB_debug_output.

It allows OpenGL implementations to provide more detailed errors and warnings. To be honest, person that invented glGetError (and consided it a reasonable debugging method) must have been mad or completely drunk. Am I over exaggerating? If you think so, try to fix your car using only one six-color LED diode. And I'll repeat once more: software engineering, and specifically graphics programming is not a goddamn MasterMind game.

Finally I've fully switched my engine code to OpenGL 3.2 (core profile). I have some experiences that I would like to share.

Performance

Well... damn, it's fast! Although GPU itself can't be accelerated much, the CPU/driver part is much faster. Most of all, count of API calls dropped significantly. Few examples:

• setting up material: instead of 20-30 uniforms and about 5 texture changes I can now upload 1 uniform buffer and 1 texture array (diffuse/normal/specular/...)
• drawing a mesh: was: few enable/disables, few glXxxPointers, 1 glDrawElements. Now: 1 bind of vertex array object, 1 glDrawElements.
• updating buffers: previously bind, update, unbind. Now (thanks to EXT_direct_state_access [spec]) just NamedBufferData(buffer_id, ...). Numbers of calls to setup textures, framebuffers and other stuff could also be reduced with DSA. Drawback: no ATI support at the moment.

This may seem like "just a little optimization". But it's not -- especially if you are CPU-bound. On my main development machine with powerful GPU and rather weak CPU the difference was huge. Even up to 10ms! That's 60 FPS -> 200 FPS. On average, there is 10-40% boost.

Uniform Buffer Objects [spec]

I've been using bindable uniforms for some time. However there was a problem: specification gave no standard layout for data and even no methods to determine the layout. In the end, I've been using float4 for everything and packed data manually. That was quite cumbersome, so I've switched to new OpenGL 3.1 UBO (uniform buffer objects). There are 2 big differences between UBO and bindable uniforms [spec].

First of all, you have 3 different layouts in UBO:

• std140 -- probably most useful. Basically you align float3/float4/structs/arrays/matrices to 16 bytes, float2 to 8 and floats to 4. That is quite OK if you sort your data from biggest to smallest. You would do so in CPU code, right?
• shared -- data using this layout can be shared across programs, but not GPU vendors. Well, I don't think that messing with structs are worth it, it will probably be the same as std140.
• packed -- this is an optimised layout, stripping unused variables, rearranging order and so on. But you can't share such buffer across other programs. And if you can't share it, why bother to create unused variables? :) That's mystery, and rather useless feature for me.

And the other difference is quite minor: with uniform buffers you directly bind buffers to uniforms, with UBO you bind them like textures. So you bind buffers to "slots", and bind those slots to uniforms. OpenGL makers seem to like it a lot.

Setting buffer data & bugs (?)

In my particles code I have found a very annoying bug called "random mess shows up on screen". What was wrong? Finally I've made this piece of code:

GLuint id;
glGenBuffers(1, &id);
glBindBuffer(GL_ARRAY_BUFFER, id);
glBufferData(GL_ARRAY_BUFFER, size_of_data, data, GL_STREAM_COPY);
glGetBufferSubData(GL_ARRAY_BUFFER, 0, size_of_data, data2);
if (data != data2) panic();

Of course initially there was BufferSubData instead of generating buffer. The result was a mess. No GL errors raised, but data was quite random in non-random manner -- everytime I've run the app the data was the same. What was wrong? I have absolutely no idea. I've managed with this bug by using MapBuffer instead of SubBufferData and it worked like a charm. But at least I've learned about...

...Transform Feedback [spec]

Equivalent of DirectX's Stream Out. Basically this allows to stream some data from vertex shader into a buffer. So you can for example:

• debug your vertex shader. You can hook between vertex and fragment shader and see what is VS' output
• save vertex results for future usedata, for example to do skinning only once per frame (in case you have shadows/reflections etc)
• do some GPGPU calculations without OpenCL -- this way you can store structures more easily than doing your job in fragment shader

You can also disable rasterization of generated vertices (pure streaming into buffer).

Timer Query [spec]

This is very useful for profiling your OpenGL application. Because GPU & CPU are doing their jobs asynchronically, something like this is bad:

var t0 = get_current_timestamp();
glRenderFancyThings();
var t1 = get_current_timestamp();
Log("Time elapsed: %f", t1 - t0);

Another bad example. This time we wait for GPU to complete, so the result makes no sense (compared to real world usage):

var t0 = get_current_timestamp();
glRenderFancyThings();
glFinish();
var t1 = get_current_timestamp();
Log("Time elapsed: %f", t1 - t0);

However we can use Timer Query to measure every GL command and grab result after few frames, when the commands have finished.

Bonus: Fermi GPU Architecture

NVIDIA_Fermi_Compute_Architecture_Whitepaper.pdf. Interesting, I wonder about its performance in OpenGL/DirectX.

I've made a simple diff of supported OpenGL extensions on NVidia & ATI cards. Lists were done in GPU caps viewer -- 3.2 compability (default) profile. Vendor-specific exts are marked with color background.

The good news: bindable uniforms.

The bad news: no direct state access on ATI. I hope this is going to be implemented soon!

Thx Krajek for ATI extensions. :)

See it here:

If you use OpenGL you must check out this free debugger: glslDevil.

Quoting autors, glslDevil is a tool for debugging the OpenGL shader pipeline, supporting GLSL vertex and fragment programs plus the recent geometry shader extension. By transparently instrumenting the host application it allows for debugging GLSL shaders in arbitrary OpenGL programs without the need to recompile or even having the source code of the host program available. The debug data is directly retrieved from the hardware pipeline and can be used for visual debugging and program analysis.

I'm going to test it in near future, hoping it could handle OGL 3.x code (gDEBugger fails to do so and doesn't support Win7).

I wanted to compare NV_explicit_multisample and new multisample textures that are now part of OpenGL 3.2 core.

Results:

• both methods give exactly same results (pixel accurate)
• FPS is also exactly the same
• multisample textures are little easier to use

To use multisample textures, you need to change just few lines in your FBO code:

Non-MS:

glGenTextures(1, &tex);
glBindTexture(GL_TEXTURE_2D, tex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA32F, 1024, 768, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, tex, 0);

BTW - here's the tip: 7th and 8th parameters in glTexImage2D (GL_RGBA, GL_UNSIGNED_BYTE in this case) doesn't matter if you pass NULL pointer to data. They are used only to convert data to texture format (so you can upload integer data to float texture). However they must be valid enums, otherwise function will fail.

And now MS version:

glGenTextures(1, &tex);
glBindTexture(GL_TEXTURE_2D_MULTISAMPLE, tex);
glTexImage2DMultisample(GL_TEXTURE_2D_MULTISAMPLE, 4, GL_RGBA32F, 1024, 768, false);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D_MULTISAMPLE, tex, 0);

Pretty easy, huh? And to bind this texture to sampler, you only need to change GL_TEXTURE_2D to GL_TEXTURE_2D_MULTISAMPLE:

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D_MULTISAMPLE, tex);

So now the fragment shader part. Take code from my previous post and make following changes:

• #extension GL_NV_explicit_multisample : enable is obviously unnecessary
• change all samplerRenderbuffer to sampler2DMS
• change texelFetchRenderbuffer to texelFetch
• change textureSizeRenderbuffer to textureSize

That's it. I think it's quite easy to use.

BTW. I've made various versions of my GI demo. I've made also a OpenGL 3.1 version that should run on all DX10 cards (NV & ATI). I'd be glad if you test it (and tell me it actually works).

• OpenGL 3.1 + NV_explicit_multisample - this should be most compatible, even with ATI cards and old NV drivers
• OpenGL 3.2 + core multisample textures
• OpenGL 3.2 + NV_explicit_multisample