There's a lot to be said for backwards compatibility -- especially when maintaining that support is for all practical purposes free -- something that cannot be said for the additional formats that...

Be careful using opengl.org for documentation because it is not without its flaws. For example, the 3.3 pages refer to a set of tables of valid internal formats but fails to include the tables. For...

This keeps me from re-loading the shader and looking a the actual performance numbers and it's nice to see the assembly code to understand what's happening under the covers. As you said, it's far...

Except for trial and error, incremental edits, and binary search debugging, are there any "real" profilers for GLSL shaders? I'm able to max out the triangle pipeline and can match the fixed function...

Somehow I missed how the #version statement worked -- core vs. compatibility.

This is somewhat encouraging ... MultiTexCoords are sufficient for the time being.

Thanks for the pointer!

T

I understand about the compatibility support. My point is that if I specify any version beyond 120, I can't feed data to the shader from a display list:


error C7533: global variable gl_Normal is...

The value actually does change for the mesh, only at a different frequency than that of the vertices. For example a single mesh containing a cube has 8 positions and 6 normals -- a display list only...

That's about what I had concluded. I would not classify this as "acceptable" -- "unavoidable" might be more appropriate -- "disappointed" is more like it. I have been able to feed this type of...

How can I replicate "flat" attributes in a VBO without duplicating the attributes on each vertex of a very complicated, multi-surfaced mesh? For example, when I create a display list, I only need one...

when using glDepthFunc(GL_GREATER), be sure to call glDepthMask(GL_FALSE)

FWIW, Vista/W7 still only provide software OpenGL 1.1 without a working ICD (Installable Client Driver) -- you will not get OpenGL 1.4 without some HW support.

Pipeline article

I have to disagree with this because we recently reviewed a driver from one of the mainstream vendors and our testing showed significant regressions only in our D3D series of tests while the OpenGL...

But don't forget that OpenGL ES was quickly followed by OpenGL SC which ADDED back immediate mode and other similar features. One reason for that was the requirement for a well defined,...

I responded that a suggestion to change the VBO spec to a block oriented spec instead of a byte oriented spec was a bad idea. I have never said this allocation bug violated any spec. What I have said...

A program can "reserve" virtual addresses and while in that state the memory does not occupy any physical resource -- the addresses are simply removed from the pool of available, free memory. However...

No optimization at all for smaller blocks would simply use an entire 64K buffer and waste the extra byte for a 64K-1b block resulting in the same footprint as a 64K block size. This is most...

OK - from a technical point of view the overall footprint for a single byte difference could require slightly more memory but a 2x difference for all allocations below 64K is a clear indication of a...

The individual data buffers are allocated out of a pool of much larger buffers (in this case a pool of what appears to be 4MB buffers) so the allocation granularity only applies to these larger...

There is a definite jump when VBOs are less than 64K and I'm also seeing a rise in memory consumption when the VBOs are greater than 512K and less than 3MB. Some of this can be expected over time but...

Thanks for confirming this.

I started looking at larger buffer sizes and decided to skip display lists and focus only on VBOs. After running through several iterations of various buffer sizes, I found that if you create VBOs...

My application has thousands of complex components and yes I am indeed looking at per-VBO overhead vs per-DL overhead because that was mentioned in another thread. Regardless, I would not expect a...

There is no allocation of vertices in my test application. I'm simply copying a single static buffer into each VBO. The increase in memory is directly a result of that copy.

It doesn't matter. If I skip creating the DLs, the VBOs still take up twice as much memory.

So I started looking into using VBOs and discovered that they have twice the memory footprint of equivalent display lists. When I say "memory footprint", I'm talking of an explicit reduction in the...