Chad Austin » opengl

GLScry 0.2.0 Released

Chad Austin — Fri, 27 May 2005 06:58:00 +0000

The 0.2.0 release of GLScry, our OpenGL benchmarking application, is available. The change log is available on its web page.

GDC – Day 2

Chad Austin — Wed, 09 Mar 2005 03:31:00 +0000

Stayed in the Next Generation Rendering with OpenGL tutorial for the whole day. To summarize: Framebuffer Objects are cool. (They took their sweet time, though!) NVidia has some very sweet performance analysis tools coming out. The folks at Graphic Remedy have a neat tool gDEBugger, but I certainly can’t afford it at $500 / seat. GPGPU is still cool.

I did learn a few new things about how to optimize shaders on modern graphics architectures. Texture fetches are still slow on ATI cards, at least relative to calculations. (On NVidia, it’s the opposite.)

OpenGL 2.0 is going to have some good changes, especially related to the shading language. It’s still in a bit of flux though.

Heh, in hindsight, I don’t remember all that much. But I’ll attribute that to my context-sensitive-access-biased memory.

GLScry 0.1.0 Released

Chad Austin — Sun, 06 Feb 2005 17:49:00 +0000

Dr. Dirk Reiners and I would like to announce the first release of GLScry, an OpenGL performance analysis tool. It provides a framework for testing and graphing the performance of various OpenGL operations. Existing tests include optimal batch size, whether there is a batch rate limit, existence of hierarchical Z or other early Z techniques, cost of lights, pixel transfer rates, state change costs, texture upload rates, interleaved vs. separate VBOs, and size of vertex cache.

Since this is an initial release, we don’t have all the tests we would like, but the framework should make it easy to add additional ones. If you wouldn’t mind, download it and give it a shot. Any feedback and test results would be appreciated.

More details and downloads are available at http://aegisknight.org/glscry.

Thanks all.

More GLSL…

Chad Austin — Fri, 10 Dec 2004 02:26:00 +0000

Does ATI even test their drivers before they release them? :P I’ve found two bugs in their GLSL implementation already. One is minor: the #version preprocessor directive isn’t supported. On the other hand, supporting #version would be simple. A high school intern could add it. The other one is more serious. I must have started exceeding the instruction limits or something because LinkProgramObjectARB was simply crashing when my program got too long. :o

It’s also way too easy to go into software fallback mode. The optimizer kind of sucks — the following code was throwing me into software:

float getOffset(int i) {
  float f = vector[i];
  ...
}

void main() {
  float offset = getOffset(0) + getOffset(1) + getOffset(2) + getOffset(3);
  ...
}

Whereas a simple change took me back into hardware:

float getOffset(float f) {
  ...
}

void main() {
  float offset = getOffset(vector[0]) + getOffset(vector[1]) + getOffset(vector[2]) + getOffset(vector[3]);
  ...
}

Even *I* could write an optimizer better than that. (And I plan to, by the end of next year. More later.) It’s not like the GPU is complicated: there’s a tiny set of instructions, no (well, limited now) branching, and no stack or function call logic. Linear execution with tons of registers… a compiler’s dream!

Meh! I’m standardizing on GLSL nonetheless. Hopefully things start to look up. :)

OpenGL Shading Language

Chad Austin — Thu, 09 Dec 2004 18:09:00 +0000

I’ve been reading the OpenGL Shading Language (hereafter GLSL) specifications for the last few hours. As we’re starting to integrate vertex and fragment shaders into Empyrean, I need to make sure I understand all of the concepts so I can fit them into our rendering architecture in a thought-out way. One of my previous concerns was that GLSL would be supported on a significantly fewer number of GPUs than ARB_vertex_program and ARB_fragment_program (hereafter ARBvp and ARBfp, respectively). After some initial research at the OpenGL Hardware Registry, I have discovered that my concern is somewhat unwarranted. GLSL fragment shaders are supported on pretty much the same cards as ARBfp: Radeon 9500+ and GeForce 5200+. GLSL vertex shaders, on the other hand, are slightly more restrictive than ARBvp. ARBvp requires a Radeon 9000+ or a GF2 MX or better. GLSL vertex shaders need a Radeon 9500 or GF2 GTS. That’s really not too bad though. The convenience and consistency of GLSL is worth the loss of a few older video cards. (The fact that older Radeons don’t support GLSL at all concerns me some, but maybe newer drivers will fix that. And few people have older Radeons anyway.)

Plus, now I only have to support one type of shading language. :) For a student developer, that’s a godsend. Only companies like id Software have the resources to write four different rendering paths to maximize hardware support.

So far everything I’ve talked about is in regards to Windows… GLSL is totally hosed on Mac (as is OpenGL as a whole) and I’ve been hearing of problems on the various Linux drivers too. In fact, my Linux box should in theory support it, but doesn’t. Doesn’t expose the extension strings, at any rate. But drivers will get better. It’s not like there is a fundamental problem here.