David Olofson wrote:
What I had in mind is that, maybe there is some trick to fallback
to another driver, or something like this…That would be your glscale backend, I guess.
Well, no. I had the thought that we could just fallback to the
underlying backend somehow.
I think glscale has some different functionality, so it shouldn’t be
mixed with another backend.
However, I’m not sure how uploading the whole OpenGL frame can be
faster than pure s/w rendering.I can think of two cases:
- An SMP machine and an OpenGL driver that can do
async. texture uploading in a separate thread.
Hum, yup that’s true. But then SDL has ASYNCBLIT to speed up s/w
rendering 
- OpenGL drivers that implement DMA transfers, so
that texture uploading is asynchronous and/or
faster than CPU driven uploading.Both cases imply that direct s/w rendering would still update most or
all of the screen every frame, as is the case in many scrolling games
- and probably quite a few games really should use some form of
“smart updating”. (Study my Fixed Rate Pig example and you’ll realize
why people don’t do it unless they really have to…)
glscale v2 does partial updates, btw
But that’s of little use when you have a full screen scrolling. And as I
always tend to think about the whorst case…
Unfortunately, I’m afraid both cases are rather unusual on the
platforms that would need them the most, such as Linux. :-/
Well, in the “standard” form of the OpenGL commands, what the driver
uploads has to be in the state it was when the command was emitted, so
deferred uploading is not possible, which makes most drivers block
before the command returns.
More generally, having deferred uploading means the driver has some way
to lock the data, which quickly turns programs into a mess with locks
everywhere (the mechanism for dma transfers in OpenGL with nvidia
extensions is particularly braindead, with the “fence” system, and
doesn’t always gets you higher performance, and even lowers performance
in fillrate-limited situations).
Stephane