Re: [Dri-devel] Mesa C++ driver framework update

[Keith W. <ke...@tu...>]

Jos=E9 Fonseca wrote:
> On Mon, Mar 10, 2003 at 08:32:18PM +0000, Keith Whitwell wrote:
>=20
>>Jos=E9 Fonseca wrote:
>>
>>
>>>Once textures are finished, the most tricky will be the software
>>>rasterizer and the TnL module. For these my idea is to make the=20
>>>driver
>>>able to switch rasterizers and/or TnL modules in real time, with=20
>>>the its
>>>own hardware accelerated versions or the software versions.
>>
>>The driver already does this -- the tnl module is swapped in/out=20
>>by the code in radeon_vtxfmt.c, the rasterizer is swapped by=20
>>RADEON_FALLBACK().
>=20
>=20
> Thank for pointing that out, as I didn't knew this - I though it just c=
hanged a few entry points in a
> callback table as done with swrast. The tnl module thing is still
> unknown territory for me as the embeded radeon drivers overrides the
> glapi dispatch table and emits DMA vertices buffers directly.
>=20
>=20
>>Actually there's probably too much mechanism propping up the tnl=20
>>module swapping at the moment.  I think a better approach would be=20
>>just to swap in a whole new dispatch table when the vtxfmt code is=20
>>viable.
>=20
>=20
> What disptach table would you be referring to, glapi or the TnL one? Th=
e
> problem with disptach tables is that they completely break the OOP
> concept as they work with regular functions instead of object methods.

That's a problem with the OOP concept, then.  Techniques based around=20
switching and updating dispatch tables are *the* way to do fast GL driver=
s.

> What are the specific problems of the module swapping?

The current mechanism tries to make it fast to swap *portions* of a dispa=
tch=20
table.  Better just to maintain two different tables & switch between the=
m.

Of course, that doesn't mean that the tables are static -- incremental up=
dates=20
of a dispatch table are a key mechanism to managing GL statechanges (whic=
h is=20
underutilized in the current drivers).

>=20
>>We could do OUTSIDE_BEGIN_END testing the same way for free.
>=20
>=20
> You lost me here...

In the simplest example you'd have two dispatch tables -- one for inside=20
begin/end, one for outside.  Switch between them in Begin and End.  The i=
nside=20
one has 'Error' stubs for all state functions, and the tnl driver plugged=
 in.=20
  The outside one has the state functions (which no longer need to check =
for=20
OUTSIDE_BEGIN_END), and some special-case handlers for Color,Vertex,etc.

Keith