Re: [Dri-devel] Glide hacking

[Brian P. <br...@tu...>]

Jacek Pop=B3awski wrote:
> In file: xc/lib/GL/mesa/src/drv/tdfx/tdfx_tris.c
>=20
> there are calls: fxMesa->Glide.grDrawTriangle( a, b, c );
>=20
> grDrawTriangle is probably defined in:
>=20
> glide3x/h3/glide3/src/gdraw.c
>=20
> and used code is:
>=20
> GR_BEGIN_NOFIFOCHECK("grDrawTriangle",92);
> TRISETUP(a, b, c);
> GR_END();
>=20
> GR_BEGIN_NOFIFOCHECK is:
>=20
> GR_DCL_GC			- set gc value (few asm lines)
> GR_DCL_HW			- set hw value=20
> GR_DEBUG_DCL(name, level)	- empty
> FXUNUSED(hw)			- no idea (can't find definition yet)
>=20
> TRISETUP is: (gc->triSetupProc)(gc, a, b, c)
>=20
> GR_END is: {GR_CHECK_SIZE(); GR_TRACE_EXIT(myName);}  - asserts
>=20
>=20
> Reading Glide source is crazy, but let's say I will complete grDrawTria=
ngle
> function as few simple lines of code (still with Glide calls). Could I =
put
> these lines in tdfx_tris.c? Will it work, if all other functions will u=
se
> fxMesa->Glide stuff?


Aren't GR_DCL_GC, GR_DCL_HW, etc macros?  They're probably private to the
Glide library.  You'd somehow have to make them public to the tdfx DRI dr=
iver.
I'm afraid that once you pull on that thread that things will quickly unr=
avel.

I'd be very hesitant to solve this by exporting new symbols (functions,
global vars, etc) from the libglide.so library.  Nobody wants to go throu=
gh
the hassle of updating their Glide library.

But if you can improve performance without stepping on those landminds, I=
'd
say go for it.

Also, I believe we're already using the Glide triangle strip/list functio=
ns
for rendering batches of triangles.  You should analyze some GL programs =
to
see how oftwen we draw individual triangls by calling glDrawTriangle().  =
If
it's seldom called, the optimization might not be of much value.

-Brian