[SDL] Mistake on DFont announcement
dleimbac at phoenix.lhup.edu
Wed Apr 26 21:02:13 PDT 2000
Pierre Phaneuf wrote:
> I talked with Dirk Hohndel (sp?), the CTO of SuSE, who worked on XFree86
> since 1992. I talked with him on a few things, and his answer as to
> whether DRI could be adapted to allow access to 2D acceleration
> primitives of video boards, his answer was something along the lines of
> "Definitely!". Sounds good. :-)
Oh yes, I also remember some people that wanted to be able to wait for
the vertical retrace. We also talked about this.
It seems that now, some new, high end video boards don't event support
the reporting of the vertical retrace as an interrupt, if you want to
know, you have to poll (which is awful and is really not the thing to
do). At first, I was really puzzled and wondered how we could ever do it
correctly, but he explained further.
Polling for the retrace is really out of the question on a multitasking
Waiting for an interrupt to be delivered is okay if you can hook the
interrupt (through a special kernel module, I think it is doable) and is
what is usually popular in games (and what people here were asking for).
It turns out that in reality, it is quite inefficient on recent boards.
First of all, in a non-realtime multitasking OS, it could take a while
between the actual interrupt happening and the X server process waking
up and acting on it, which is inacceptable since they happen so close to
each other. Second, modern boards have an accelerator pipeline that can
buffer multiple commands, and thus, waiting for the vertical retrace
before sending a command will only be effective if the accelerator
pipeline is empty or else it will wait even more and could effectively
miss the deadline. Even if the pipeline is empty, this is missing out on
parallelism, as the CPU waits idly for the vertical retrace to happen.
The right thing is this: those modern boards usually support a "wait for
vertical retrace" flag on their command, which will let the *board* do
all the waiting. If you do a big blit that you think could shear (small
blits usually are fast enough not to produce any artifacts), you set
that flag and when the accelerator is about to execute that command, it
will execute it only right as the vertical retrace happens, exactly what
we want. And the CPU is free during all this time to just spit commands
to the accelerator pipeline as fast as it can, exploiting the parallel
nature of the CPU/video board setup.
More information about the SDL