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.

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.

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.




------------------------------------------------------- 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

Reply via email to