On Sat, 26 Jul 2003 15:54:12 -0700 Ian Romanick <[EMAIL PROTECTED]> wrote:
> Michel D�nzer wrote: > > > On Sat, 2003-07-26 at 15:09, Felix K�hling wrote: > > > >>On 26 Jul 2003 12:42:18 +0200 > >>Michel D�nzer <[EMAIL PROTECTED]> wrote: > >> > >> > >>>On Sat, 2003-07-26 at 12:11, Felix K�hling wrote: > >>> > >>>>I see. I simply converted the old environment variable R200_NO_IRQS to > >>>>configuration option use_irqs. > >>> > >>>Indeed, I see now that the trunk is broken already. :) > >>> > >>> > >>>>So what about this patch (similar for radeon): > >>>> > >>>>--- r200_context.c.old 2003-07-26 12:04:35.000000000 +0200 > >>>>+++ r200_context.c 2003-07-26 12:05:04.000000000 +0200 > >>>>@@ -424,7 +424,7 @@ > >>>> > >>>> rmesa->do_usleeps = driQueryOptionb (&rmesa->optionCache, "use_usleeps"); > >>>> > >>>>- rmesa->vblank_flags = (rmesa->do_irqs) > >>>>+ rmesa->vblank_flags = (rmesa->dri.drmMinor >= 6 && rmesa->r200Screen->irq); > >>>> ? driGetDefaultVBlankFlags(&rmesa->optionCache) : VBLANK_FLAG_NO_IRQ; > >>>> > >>>> rmesa->prefer_agp_client_texturing = > >>> > >>>What is this supposed to achieve? :) > >> > >>It will disable driWaitForVBlank if interrupts don't work for some > >>reason. You're right, this check is probably redundant. The VBLANK ioctl > >>will return an error if IRQs don't work. :-| > > > > > > Right. The code now also seems to handle this case more gracefully. > > > > > > > >>>>Or would you prefer having another option "use_vblank_irqs" or more > >>>>general "use_hw_irqs" and maybe rename "use_irqs" to "use_sw_irqs". > >>> > >>>I'd like to drop VBLANK_FLAG_NO_IRQ altogether as it doesn't make sense > >>>to me - vblank throttling and software interrupt emission are orthogonal > >>>concepts. > >> > >>They are, therefore I suggested using two different options. So the user > >>can decide that a specific application shouldn't use vblank throttling. > >>Then maybe the flag is misnamed. Something like VBLANK_FLAG_DISABLE > >>would be more appropriate. > > > > Just don't set VBLANK_FLAG_THROTTLE or VBLANK_FLAG_SYNC, or do you mean > > to override VBLANK_FLAG_INTERVAL even? Is that needed, Ian? > > What we want is basically a quad-state variable. The configuration file > should be able to specify one of 4 answers to the "To vsync or not to > vsync" question: > > 1. Never! FPS rulez!!! > 2. App. preference, default to off. > 3. App. preference, default to on. > 4. App. preference, always at least 1. > > We may or may not want the 4th option. Dunno. This kind of thing is possible with the current system but hard to document. The description string would get quite long and unreadable. Maybe we need another data type "enum". The hard part is that the descriptions of each value should be internationalized. I'll cover the details in a separate mail soon. > > We also need a way to specify that interrupts are not available. In > this case, we don't want to export any of the vsync related GLX extensions. Does the user or the mesa driver really need to specify this. Shouldn't the drm know if interrupts are working? If they aren't the ioctl should just return an error. > How we internally do that, I don't really care. In order to make this a > bit more sane in the non-env var world, we may want to change the way > the driver tells the vblank routines what to do. Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K�hling (_____\�/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
