[SDL] Re: extension for 2D with DRI
pphaneuf at sx.nec.com
Fri Apr 14 11:06:46 PDT 2000
Mattias Engdegård wrote:
> > The net result is higher framerates: who doesn't want that? :-)
> Nobody needs higher framerates than required for the recorded
> video sequence, nor higher than vertical frequency of your monitor.
> But if there is a lot of computation going on, you are right.
No, for recorded video, this is not required, except when the CPU power
to do the decompression is lacking. Making the CPU wait isn't a winning
strategy when you have barely what you need to keep the full framerate
of the video sequence.
And for a game, you want the highest framerate possible. I have a
refresh rate around 100 Hz and games usually have a hard time getting
this framerate, so when this is going to be a problem, I think it
actually won't be anymore (I'll have to think of more effects to slow it
> > No problem with that. Just tag the blit command with the "wait for
> > retrace" flag, issue it and start uncompressing the next frame.
> Sure, this is the principle behind triple buffering: assuming you own the
> CPU, decouple the screen refresh from the frame generation. But you may
> not have that luxury.
You may not always have that luxury (maybe your blits are software and
synchronous), but doing it that way doesn't give worse performance than
an algorithm that doesn't take advantage of asynchronous blits, so why
not assume asynchronous blits and try to do your best?
> Even if you can maintain a CPU monopoly, I can imagine situations
> where it is better to produce 40 than 51 frames/s when your monitor
> refreshes at 80Hz. First-person shooters are remarkably immune to this,
> but other games could produce temporal aliasing problems.
I don't really believe in this. If you can make 51 fps on a monitor
going at 80 Hz, that will be better than 40 fps. Of course, the game
logic has to compensate the time properly!
> issuing queued drawing requests at retrace). But that is not sufficient
> if you want to play something at a fixed fraction of the monitor frequency.
Is that useful at all?
> I'm painfully aware of tearing effects from the lack of synchronization
> in X11, and I really wish there was a good standard way around it.
> Too bad many platforms have no usable implementation of the double-buffer
> extension (DBE).
I was told that XFree86 queues drawing requests at retrace to the
accelerator, but for operations that are done in software, the
synchronization too bad to help (the problem I described) and/or
software PIO transfers are so slow that they take more time than the
vertical refresh allows for.
Some of the drivers of XFree86 4.0 are almost completely using the
accelerator and exhibit MUCH better behavior regarding tearing.
More information about the SDL