On Tue, Jun 12, 2007 at 08:59:23AM +0200, Michel Dänzer wrote:
> On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
> > On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
> > > ick. just read the registers and return the value here. We should place
> > > wrap-detection in the core code by reporting the range of the register
> > > values; with the offset suggested above, that would result in a single
> > > addition to convert from raw to cooked frame counts.
> > 
> > Ok, here's an updated version:
> >   - move wraparound logic to the core
> >   - add pre/post modeset ioctls (per-driver right now, making them core 
> > would
> >     mean lots more DDX changes I think), 
> 
> Shouldn't really matter, DDX drivers can call driver independent ioctls.
> 
> > hope I got this right
> >   - add vblank_get/put calls so interrupts are enabled at the right time
> > 
> > I haven't implemented Ville's suggestion of adding a short timer before
> > disabling interrupts again, but it should be easy now that the get/put
> > routines are in place and we think it's worth it (might make vblank
> > calls a little cheaper, but it would probably be hard to detect).
> 
> Yeah, I'm doubtful. Ville, can you explain some use cases you're
> thinking of?

Was this discussion only for wait for vblank? I was mainly thinking
about triple buffering w/ page flipping. Now that I think about it the
interrupt would only need to be enabled until the flip is actually
completed by the hardware. With interlaced displays that event might in
reality be two vblank interrupts away (assuming the API allows one to
sync to a specific field).

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to