Near as I can tell, if I wanted to reproduce a cube in many places, I’d
upload the cube
upload the places as a texture buffer object
write a shader to transform the cube to various places
…unless the graphics card doesn’t support texture buffers? Then I’d do this:
upload the cube
upload the places as some older thingy with a weird format
write a shader to etc, but using special code to decipher the old format into something like texture buffers
…unless the graphics card didn’t support shaders? Then I’d do um…
put the cube in ordinary memory
create the places as a software buffer
write a program to transform the cube to various places, and upload it each time.
In every case I’m doing basically the same thing, on the surface. Just, if the graphics card doesn’t support it, I have to do the logic of the shader myself, on the software side.
But that seems like a whole lot of wasted effort, because you could implement those software side algorithms in opengl itself. That’s already been done, right? The only difference with cheap graphics cards is that they’d be slower? Opengl could even include a software GLSL interpreter, since the opengl project maintains the language. That way from the programmer’s perspective, they can just do it the most modern “best” way, and opengl will figure out how much it needs to fall back, based on the graphics card.
That’s how things are, right? opengl uses other techniques to emulate the more modern ones, if the graphics card doesn’t support it? I mean, what if you run into a card that doesn’t support VBOs? glBegin/glEnd are completely gone! So there have to be some extensions opengl emulates using other techniques, don’t there? When does it report that an opengl extension is unavailable, when the graphics card hardware doesn’t support it, or when the opengl version doesn’t have a software fallback for it?
There is no “OpenGL project”. Khronos (formerly the ARB) publishes a standard, not software. It’s up to vendors (or open-source projects) to supply drivers for hardware.
Wrong, for the most part.
Software fallbacks may be used to implement legacy features which aren’t implemented directly on modern hardware. Vendors rarely use software fallbacks to implement recent features; they just support the highest OpenGL version that can be implemented in hardware.
If you want features beyond those which your hardware supports and can tolerate the performance hit, look at Mesa, which includes a complete software implementation, using LLVM to compile shaders for execution on the CPU.
Near as I can tell, if I wanted to reproduce a cube in many places, I’d
upload the cube
upload the places as a texture buffer object
write a shader to transform the cube to various places
No, this would generally be a terrible idea. It would be very difficult to make such a thing seamless, since that requires getting the invariance rules right.
I mean, what if you run into a card that doesn’t support VBOs? glBegin/glEnd are completely gone! So there have to be some extensions opengl emulates using other techniques, don’t there?
glBegin/glEnd were removed from the core profile of OpenGL in version 3.1. However, version 3.1 (and the 4 versions before that) requires buffer object support. As such, if the hardware cannot support buffer objects, it cannot support any version of OpenGL where “glBegin/glEnd are completely gone!”