Re: [Dri-devel] First configuration GUI available

[Ian R. <id...@us...>]

Michel D=C3=A4nzer wrote:

> On Sat, 2003-07-26 at 15:09, Felix K=C3=BChling wrote:
>=20
>>On 26 Jul 2003 12:42:18 +0200
>>Michel D=C3=A4nzer <mi...@da...> wrote:
>>
>>
>>>On Sat, 2003-07-26 at 12:11, Felix K=C3=BChling wrote:
>>>
>>>>I see. I simply converted the old environment variable R200_NO_IRQS t=
o
>>>>configuration option use_irqs.=20
>>>
>>>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 @@
>>>>=20
>>>>    rmesa->do_usleeps =3D driQueryOptionb (&rmesa->optionCache, "use_=
usleeps");
>>>>=20
>>>>-   rmesa->vblank_flags =3D (rmesa->do_irqs)
>>>>+   rmesa->vblank_flags =3D (rmesa->dri.drmMinor >=3D 6 && rmesa->r20=
0Screen->irq);
>>>>        ? driGetDefaultVBlankFlags(&rmesa->optionCache) : VBLANK_FLAG=
_NO_IRQ;
>>>>=20
>>>>    rmesa->prefer_agp_client_texturing =3D=20
>>>
>>>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 ioct=
l
>>will return an error if IRQs don't work. :-|
>=20
>=20
> Right. The code now also seems to handle this case more gracefully.
>=20
>=20
>=20
>>>>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 sens=
e
>>>to me - vblank throttling and software interrupt emission are orthogon=
al
>>>concepts.
>>
>>They are, therefore I suggested using two different options. So the use=
r
>>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.
>=20
> 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=20
should be able to specify one of 4 answers to the "To vsync or not to=20
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=20
this case, we don't want to export any of the vsync related GLX extension=
s.

How we internally do that, I don't really care.  In order to make this a=20
bit more sane in the non-env var world, we may want to change the way=20
the driver tells the vblank routines what to do.