On Sun, 31 Mar 2002, Mark Vojkovich wrote:
> On Sun, 31 Mar 2002, Vladimir Dergachev wrote:
> >
> > On Sun, 31 Mar 2002, Egbert Eich wrote:
> >
> > > Mark Vojkovich writes:
> > > >
> > > > Looking at the code for the siliconmotion driver in the tree, I'm
> > > > not surprised. It looks like the driver is polling until the retrace
> > > > everytime it has to put a frame. I would expect that to eat up more
> > > > CPU than just doing all the video in software. You should probably
> > > > try it without Xv, if that's being used now. Or somebody should fix
> > > > the drivers.
> > > >
> > >
> > > OK, I will look into this next week.
> > >
> > > I guess this retrace waiting was done to prevent shearing.
> > > Only very few chipsets support some kind of double buffering
> > > with automatic buffer switching on retrace. On all others
> > > we need to poll the chip to detect a retrace.
> >
> > Well, I know that ATI chipsets did this at least since Rage Pro. Also,
> > AFAIK, mga does it too and I would be surprised if nvidia does not do it.
> >
> > The way it is implemented in ATI chips is that registers that describe a
> > buffer in ram are buffered with new values taking effect after retrace.
> > I do not think this takes any significant amount of chip real estate.
> > So there should not be any reason not to implement this.
> >
>
> I agree, but I wouldn't be surprised if some low-end chips didn't
> support this anyhow.
>
> Egbert, if you can program the registers outside of the retrace
> without hardware gliches, I think you should just do that. Polling
> for the retrace in the server should not be done for stuff like this.
> These apps are typically cpu intensive so they are competing with
> the server for CPU. That means the server might not even be scheduled
> during the retrace a good deal of the time. I suspect the server
> spends its entire slice spinning most of the time.
>
That's a good point.
Another possibility is to use some other hardware mechanishm to wait
for retrace. For example, if your chip has a fifo for incoming commands
there might be a command that waits for a certain event - like retrace
happenning and stalls the fifo with that. This might or might not produce
better results.
Also if you want to implement an irq handler - take a look at "km" at
http://gatos.sf.net/ it does this (plus dma engine) for ATI cards, I would
imagine your card will be quite similar in this regard. The radeon part is
cleanest, IMO.
Vladimir Dergachev
>
> Mark.
>
>
> _______________________________________________
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
