What application developers are getting at with this is that OpenGL is a rich API, and not all cards do everything at top speed. There is usually one fastest way to talk to OpenGL to get maximum throughput.
The problem is: this is ludicrous. Case in point, the GeForce 8800 - in my Mac Pro, running OS X 10.5.4 and Ubuntu 8. So what is the fast path?
If I draw my terrain using stream VBOs for geometry and indices that are not in a VBO, I get 105 fps on Linux. If I then put the indices into a stream VBO, I get 135 fps. The fast path!
Well, not quite. The index-without-VBO case runs at 73 fps on OS X, but once those indices go into a VBO, I crash down to 25 fps. Wrong fast path.
Simply put, you can't spec the fast path, so the spec doesn't matter. You find the fast path by writing a lot of code and trying it on a lot of hardware. I can't see there ever being another way, given how many different cards and drivers are out there.
That's true! but not only between platforms it also depends on your driver version. We've been making tests to find the best way to upload textures to the GPU as fast as possible and using the same machine, changing the driver, we got extremely different results. Some techniques worked better with the older driver version, some others not and vice versa.
ReplyDeleteWell, this is exactly the reason why OpenGL 3.x should remove alternatives.
ReplyDeleteAs now driver developers have to optimize for hundreds of use-cases, tuning their drivers to what people are going to use. Developers, have to optimize for different drivers/platforms. If only one alternative exists, everybody will just focus on that.
This will bring up performance in the long term, and lower costs (already in the short term).