mesa3d-dev Mailing List for Mesa3D (Page 832)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Brian Paul wrote:
> 
> All the conformance tests pass now.

I don't think I'll ever get sick of hearing that...

-- Gareth

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> > I think the sources for Mesa 3.5 are quickly settling down and I don't
> > think there will be any big changes anymore (Keith?).  If that's the
> > case, do you still want to make a seperate sources file?
> 
> I removed a file 't_vb_materials.c' yesterday.

t_vb_materials.c or t_vb_material.c?

_tnl_update_material_stage is referenced in FX/fxdd.c and is in
t_vb_material.c.  I added it to the makefile and added an extern
declaration for _tnl_update_material_stage to t_pipeline.h to make
everything compile.

All the conformance tests pass now.

-Brian

On Fri, 16 Feb 2001, Keith Whitwell wrote:

> Klaus Niederkrueger wrote:
> >
> > Hi,
> >
> > I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> > and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> >
> > I don't know if this is important or not and if was a bug, I have no idea
> > if it is now or it was before.
> >
> > I haven't try though Mesa-3.4.1.
>
> On what driver?
>
> I've got the two X11 drivers running side by side & they look identical.
>
> Keith
>

Just normal software-rendering.
24bit TrueColor
Frame buffer: 24bit R8:G8:B8:A0

I don't know what else could help.

Klaus

Klaus Niederkrueger wrote:
> 
> Hi,
> 
> I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> 
> I don't know if this is important or not and if was a bug, I have no idea
> if it is now or it was before.
> 
> I haven't try though Mesa-3.4.1.

On what driver?

I've got the two X11 drivers running side by side & they look identical.

Keith

Hi,

I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.

I don't know if this is important or not and if was a bug, I have no idea
if it is now or it was before.

I haven't try though Mesa-3.4.1.

Klaus

Brian Paul wrote:
> 
> "Sven M. Hallberg" wrote:
> >
> > On Mon, Feb 12, 2001 at 12:15:44PM -0700, Brian Paul wrote:
> > > > PS: Maybe we could even modify the "manual" Makefiles to use these list files.
> > > >     That way the need for seperate maintainance of the traditional and the
> > > >     automake lists would disappear. Comments anyone?
> > >
> > >
> > > The src/Makefile.X11 file is always up to date.  It's what Keith
> > > and I use.  If your scripts will help you that's fine.
> >
> > However, pulling the source file lists out would directly eliminate?
> > the need for that double maintanence work. That's what I meant.
> >
> > Do you think we could do that? I would of course do the modification work,
> > on a seperate branch. You and Keith would just have to agree to use couple of
> > seperate file for specifying the source lists. Or do you see a problem there?
> 
> I think the sources for Mesa 3.5 are quickly settling down and I don't
> think there will be any big changes anymore (Keith?).  If that's the
> case, do you still want to make a seperate sources file?

I removed a file 't_vb_materials.c' yesterday.

I plan on adding a bunch of templates to make driver writing easier (you've
already seen a few in the tnl/ directory; they really belong in a directory of
their own, I think).

Otherwise, I think that's it for me.

Keith

On Sat, Feb 17, 2001 at 02:42:10AM +1100, Gareth Hughes wrote:
> Daryll Strauss wrote:
> > 
> > No it won't. There is no Glide for it.
> 
> You mean Glide 3 doesn't work with the V5?  Or is it that Glide 3
> doesn't work with the FX driver?

Here's the long story:

The original VB/V3 version of Glide was something of a hack. The X
server only used PIO and and Glide only used MMIO. The X server would
always setup the card in an easily predictable memory layout and Glide
took advantage of that. You'd start the X server, it would do it's
thing. You'd start a glide app, which would start MMIO and that caused
the card to ignore PIO. Glide would just take over the card and keep
working.

XFree 4.0 comes out, and the X driver uses MMIO for better
performance. It also lays out the board dynamically. Now you really need
cooperation between Glide and XFree. Glide would have to be written to
use the DRI to do that cooperation. That was done as an experiment, but
it required making some behavior modifications to Glide/X which meant
older Glide programs wouldn't run. So 3dfx decided it wasn't worth
persuing. 

So, the only stand alone Glide that works is V1/V2 and VB/V3. The V5
version was never ported for anything other than running under Mesa in
DRI mode.

						- |Daryll

Daryll Strauss wrote:
> 
> No it won't. There is no Glide for it.

You mean Glide 3 doesn't work with the V5?  Or is it that Glide 3
doesn't work with the FX driver?

-- Gareth

On Sat, Feb 17, 2001 at 02:05:38AM +1100, Gareth Hughes wrote:

> Thanks, Keith.  This is all really great information.
> 
> So, if you guys have other things to do, I'd be more than happy to
> tackle this problem in the short term (ie. to get a 3.5 release out). 
> The standalone FX driver should work with a V5, right?

No it won't. There is no Glide for it. 

					- |Daryll

Gareth Hughes wrote:
> 
> Keith Whitwell wrote:
> >
> > As you can see, there's a fair bit of experimentation left to get this
> > right...
> >
> > There may be yet another approach which bypasses some of these issues.
> > I haven't given much thought to it, but it may be possible to allow
> > the driver to swap dispatch entries from gl_update_state(), even when
> > called from inside a tnl module, providing that the lost data is
> > somehow rescued later on, perhaps by calling a special 'fallback'
> > routine.  I guess DrawArrays etc would still need to forward...
> 
> Thanks, Keith.  This is all really great information.
> 
> So, if you guys have other things to do, I'd be more than happy to
> tackle this problem in the short term (ie. to get a 3.5 release out).
> The standalone FX driver should work with a V5, right?

I've never tried.  It would require a special Glide library.
I guess you'd have to go to the Glide project on sourceforge and
build it w/out DRI.

-Brian

"Sven M. Hallberg" wrote:
> 
> On Mon, Feb 12, 2001 at 12:17:20PM -0700, Brian Paul wrote:
> > "Sven M. Hallberg" wrote:
> > >
> > > Greetings,
> > >
> > > I have rearranged the configure.in to work with autoconf v2.13 again.
> > > Unfortunately it is now no longer possible to use configure to compile a Mesa
> > > with missing GLUT and/or demo source directories. However, one might consider
> > > making those seperate packages, thus giving them their own configure script...
> > > But that's another story.
> >
> > As sophisticated as autoconf is, I'm surprised that you can't
> > detect whether or not src-glut/, demos/, etc. exist at compile time.
> 
> Well, the problem lies in dynamically generating the list of Makefiles to be
> created, depending on which directories are present. With the current autoconf
> you must pass the entire list to a single call of AC_OUTPUT. The only
> way for a dynamic list is to use a variable and pass that one. I guess that
> would work with autoconf, _but_ it doesn't with automake because automake
> parses configure.in for the call to AC_OUTPUT and if it finds AC_OUTPUT($list)
> assumes it should create a file $list.in. *g*
> 
> In the new autoconf you have the required flexibility because it uses
> a dynamic list internally, i.e. you specify any files to be created by means
> of repetitive calls to a certain macro (AC_CONFIG_FILES I think) and call
> AC_OUTPUT without any arguments. The new automake is of course aware of
> AC_CONFIG_FILES.

You had suggested putting all the demo directories under a new demo/
subdirectory.  How would that work?

-Brian

"Sven M. Hallberg" wrote:
> 
> On Mon, Feb 12, 2001 at 12:15:44PM -0700, Brian Paul wrote:
> > > PS: Maybe we could even modify the "manual" Makefiles to use these list files.
> > >     That way the need for seperate maintainance of the traditional and the
> > >     automake lists would disappear. Comments anyone?
> >
> >
> > The src/Makefile.X11 file is always up to date.  It's what Keith
> > and I use.  If your scripts will help you that's fine.
> 
> However, pulling the source file lists out would directly eliminate?
> the need for that double maintanence work. That's what I meant.
> 
> Do you think we could do that? I would of course do the modification work,
> on a seperate branch. You and Keith would just have to agree to use couple of
> seperate file for specifying the source lists. Or do you see a problem there?

I think the sources for Mesa 3.5 are quickly settling down and I don't
think there will be any big changes anymore (Keith?).  If that's the
case, do you still want to make a seperate sources file?

I guess I really don't care either way.

-Brian

Keith Whitwell wrote:
> 
> As you can see, there's a fair bit of experimentation left to get this
> right...
> 
> There may be yet another approach which bypasses some of these issues.
> I haven't given much thought to it, but it may be possible to allow
> the driver to swap dispatch entries from gl_update_state(), even when
> called from inside a tnl module, providing that the lost data is
> somehow rescued later on, perhaps by calling a special 'fallback'
> routine.  I guess DrawArrays etc would still need to forward...

Thanks, Keith.  This is all really great information.

So, if you guys have other things to do, I'd be more than happy to
tackle this problem in the short term (ie. to get a 3.5 release out). 
The standalone FX driver should work with a V5, right?

-- Gareth

On Mon, Feb 12, 2001 at 12:15:44PM -0700, Brian Paul wrote:
> > PS: Maybe we could even modify the "manual" Makefiles to use these list files.
> >     That way the need for seperate maintainance of the traditional and the
> >     automake lists would disappear. Comments anyone?
> 
> 
> The src/Makefile.X11 file is always up to date.  It's what Keith
> and I use.  If your scripts will help you that's fine.

However, pulling the source file lists out would directly eliminate?
the need for that double maintanence work. That's what I meant.

Do you think we could do that? I would of course do the modification work,
on a seperate branch. You and Keith would just have to agree to use couple of
seperate file for specifying the source lists. Or do you see a problem there?

-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

On Mon, Feb 12, 2001 at 12:17:20PM -0700, Brian Paul wrote:
> "Sven M. Hallberg" wrote:
> > 
> > Greetings,
> > 
> > I have rearranged the configure.in to work with autoconf v2.13 again.
> > Unfortunately it is now no longer possible to use configure to compile a Mesa
> > with missing GLUT and/or demo source directories. However, one might consider
> > making those seperate packages, thus giving them their own configure script...
> > But that's another story.
> 
> As sophisticated as autoconf is, I'm surprised that you can't
> detect whether or not src-glut/, demos/, etc. exist at compile time.

Well, the problem lies in dynamically generating the list of Makefiles to be
created, depending on which directories are present. With the current autoconf
you must pass the entire list to a single call of AC_OUTPUT. The only
way for a dynamic list is to use a variable and pass that one. I guess that
would work with autoconf, _but_ it doesn't with automake because automake
parses configure.in for the call to AC_OUTPUT and if it finds AC_OUTPUT($list)
assumes it should create a file $list.in. *g*

In the new autoconf you have the required flexibility because it uses
a dynamic list internally, i.e. you specify any files to be created by means
of repetitive calls to a certain macro (AC_CONFIG_FILES I think) and call
AC_OUTPUT without any arguments. The new automake is of course aware of
AC_CONFIG_FILES.

> > Anyways, my first show at building died with cpp unable to find
> > GL/include/glcore.h, included from glheader.h. I have not been able to find
> > that file anywhere, however my old locate db indicated it used to reside
> > in the Mesa src/ dir. Am I missing something or is this a bug?
> 
> As Keith said, it's in Mesa/include/GL/internal/glcore.h.

Yes, wasn't able to reach the CVS server last weekend, updating right now.
Just missed that CVS switch. Actually the compile is running now and everything
appears to be fine, at least as far as the include error is concerned.

-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

emanuel stiebler wrote:
> 
> Keith Whitwell wrote:
> >
> > Brian, Gareth, and others,
> >
> > I'm trying to nail down what's left to do for 3.5.
> 
> Win32 Makefiles ?
> ;-)

The Mesa/Windows driver code will need a number of updates in order
to work at all with Mesa 3.5.

As of now, nobody's taking an active role in maintaining the
Windows code.  I'm not likely to postpone the 3.5 release
waiting for anyone to do that.

-Brian

Gareth,

Here's a braindump regarding runtime installation of the api of a tnl
module into the libGL dispatch table.

There are two tricks to this; efficiency and correctness...  

Correctness is complicated by the fact that it is anticipated that
drivers may not know which tnl module they want to use until after a
call to 'gl_update_state()' has completed.  If we wait until we are
inside the tnl code before triggering gl_update_state(), it becomes
necessary to detect if the tnl function that called gl_update_state()
is still attached to the dispatch table, and if not to invoke
the new one.  

This is ugly, and actually quite complex to get right.  All in all it
would be preferable to ensure 'gl_update_state()' is called prior to
entering the tnl code, and to ensure that the correct tnl module is
always invoked.

Efficiency concerns are that installing 20 or 30 function pointers on
a potentially very frequent basis is likely to be a performance issue
in itself. 

My basic idea was to perform the installation in a lazy fashion, as
individual entrypoints are invoked by clients.

A set of stub functions would be initially installed into dispatch, which:

	1) determine whether it is necessary to call
	   gl_update_state(), and if so, do so.

	2) install the 'real' version of the function, eg
	   _tnl_Begin(), into the dispatch table, and pass control to
	   that function.

Consider this invarient:

	When inside any tnl api function, ASSERT(ctx->NewState == 0).

The question then is how/when to uninstall driver tnl functions and
restore the stubs.

It seems at least two triggers are required:
	- A directive from the driver to install a new tnl module.
	- Any statechange (!!)

This seems like overkill -- there are a lot of statechanges.  It may
be necessary instead to require that drivers only swap tnl modules in
statechange callbacks, rather than from ctx->Driver.UpdateState().
Then the calls to gl_update_state() can remain in things like
_tnl_DrawElements(), but they will be guarenteed to never alter the
dispatch tables, or require forwarding of the call back to dispatch.

... But ...

As I said above, the driver may not know until gl_update_state() is
called whether it is able to use an accelerated tnl module.
Specifically it may need to reference one of the values computed in
gl_update_state() to make it's choice.

Thus drivers would have to swap to the neutral tnl module in
response to any dangerous state change callbacks, and have the neutral
vertex format specifically ask the driver to choose (validate) the
installed tnl module, after calling gl_update_state().

An equivalent strategy would be to have the driver register a bitmask
of 'dangerous' statechanges, and only swap to the neutral tnl module
on those statechanges.  However this seems to introduce unnecessary
overhead into each core statechange operation.

======================================================================

So, a second attempt:

- Forbid swapping tnl modules inside ctx->Driver.UpdateState().
- Keep calls to gl_update_state() inside tnl modules.
- Add a new 'ctx->Driver.ValidateTnlModule()' callback.
- Create a neutral tnl module which contains functions which:
	- check if gl_update_state() needs to be called.
	- check if ctx->Driver.ValidateTnlModule() needs to be called.
	- installs the appropriate driver tnl function into dispatch.
	- finally forwards the call to the newly installed driver function.

- Experiment with bitmask vs. callback strategies for swapping back to
  the neutral tnl module.

Then the mechanism of swapping back to the neutral tnl module needs to
be explored.

As I've outlined a lazy method for swapping the driver tnl module in,
a function at a time, it should be possible to keep track of which
dispatch entries have been modified (from the neutral baseline), and
only swap back in the portions of the neutral tnl module which have
been swapped out.  This might typically amount to 5 entries or so.

As you can see, there's a fair bit of experimentation left to get this
right...

There may be yet another approach which bypasses some of these issues.
I haven't given much thought to it, but it may be possible to allow
the driver to swap dispatch entries from gl_update_state(), even when
called from inside a tnl module, providing that the lost data is
somehow rescued later on, perhaps by calling a special 'fallback'
routine.  I guess DrawArrays etc would still need to forward...

Keith

Keith Whitwell wrote:
> 
> Brian, Gareth, and others,
> 
> I'm trying to nail down what's left to do for 3.5.  

Win32 Makefiles ?
;-)

cheers

Mesa 3.4.1 can be downloaded from sourceforge at
https://sourceforge.net/project/showfiles.php?group_id=3
(I've actually got one or two more files to upload)

Here's what's new:

    New:
	- fixed some Linux build problems
	- fixed some Windows build problems
	- GL_EXT_texture_env_dot3 extension (Gareth Hughes)
    Bug fixes:
	- added RENDER_START/RENDER_FINISH macros for glCopyTexImage in DRI
	- various state-update code changes needed for DRI bugs
	- disabled pixel transfer ops in glColorTable commands, not needed
	- fixed bugs in glCopyConvolutionFilter1D/2D, glGetConvolutionFilter
	- updated sources and fixed compile problems in widgets-mesa/
	- GLX_PBUFFER enum value was wrong in glx.h
	- fixed a glColorMaterial lighting bug
	- fixed bad args to Read/WriteStencilSpan in h/w stencil clear function
	- glXCopySubBufferMESA() Y position was off by one
	- Error checking of glTexSubImage3D() was broken (bug 128775)
	- glPopAttrib() didn't restore all derived Mesa state correctly
	- Better glReadPixels accuracy for 16bpp color - fixes lots of OpenGL
	  conformance problems at 16bpp.
	- clearing depth buffer with scissoring was broken, would segfault
	- OSMesaGetDepthBuffer() returned bad bytesPerValue value
	- fixed a line clipping bug (reported by Craig McDaniel)
	- fixed RGB color over/underflow bug for very tiny triangles
    Known problems:
	- NURBS or evaluator surfaces inside display lists don't always work

-Brian

Keith Whitwell wrote:
> 
> Brian, Gareth, and others,
> 
> I'm trying to nail down what's left to do for 3.5.  I've got a list of crucial
> and 'nice' items, maybe you can add your own items to the list & we can get
> some idea how close we are to nailing this down.
> 
> Crucial:
> 
>         - Floating point color support in 'tnl' module.  (in progress)
>         - Restore driver ability to swap in alternate tnl modules.
> 
> Nice:
>         - Finish the 't_dd_' templates.
>         - Port the remaining DRI drivers to 3.5. (tdfx in progress, trying to use the
> templates)
> 
> 
> I think 3.5 is such a big step forward in terms of maintainability and
> cleanliness that it's sensible to see it released as soon as seamliness
> permits...

A few things I'd like to do:

1. clean-up the function namespace.  I.e. replace gl_*() functions with
   _mesa_*().

2. clean-up the INTERP_Z and fog code in the line and triangle template
   code.

3. I've still got some corner cases to fix in the new teximage code.
   glGetTexImage(GL_COLOR_INDEX), for example, doesn't work right.

4. Integrate the SGI SI GLU.

Otherwise, I think I've fixed the last of the conformance bugs.
All color index mode tests now pass (at 8pp) and all RGB tests work
at 24, 16 and 8bpp.  The only exception is a convolution border
mode test at 8bpp.  A comment in the code for that test says that
the test may not work correctly at shallow depths so i'm not too concerned.

-Brian

BTW: I'm trying to upload 3.4.1 to sourceforge but the upload facility
still seems to be broken.

Keith Whitwell wrote:
> 
> > I'd pretty much like to work on any of the above.  I might be
> > particularly useful on the templates, having working copies for 3.4
> > myself.  I'd also like to port at least one driver to 3.5 (r128 and mga
> > are good candidates here).
> 
> You can have either or both of them...

I'll take both.

> > Here's my Nice list:
> >
> >         - General work on driver begin/end objects.
> >         - Code generation for begin/end objects.
> >         - Asm-optimized clipping, lighting code.
> >
> > And after that (Really Nice?  Not As Nice?):
> >
> >         - General work (like the old fastpath) to accelerate driver
> >           rendering paths.
> 
> All this is good stuff but I think we can finalize 3.5 and do this afterwards
> as seperate work.  (I'm not trying to push this back, just pull forwards the
> 3.5 release).  Using my list, I think a 3.5 release could occur after the
> 'crucial' and before the 'nice'...

Sorry, I should have made that clearer.  This is what I meant, I just
wanted to let you guys know what I will be working on in the future. 
After 3.5 goes out, that is...

> The current code matches or beats the old fastpath, but for different
> reasons.  So yes, path improvements are possible.

Exactly.  I'd like to profile the new code and work out nifty ways to
make it run faster.  No matter what, it will be a good chance to really
learn the new code.

> > If you haven't started the tnl module swapping stuff, that might be a
> > good thing for me to work on in the short term.
> 
> I haven't.  I've got a basic design I'll try and detail in a followup email.

Okay, cool.

-- Gareth

Gareth Hughes wrote:
> 
> Keith Whitwell wrote:
> >
> > Brian, Gareth, and others,
> >
> > I'm trying to nail down what's left to do for 3.5.  I've got a list of crucial
> > and 'nice' items, maybe you can add your own items to the list & we can get
> > some idea how close we are to nailing this down.
> >
> > Crucial:
> >
> >         - Floating point color support in 'tnl' module.  (in progress)
> >         - Restore driver ability to swap in alternate tnl modules.
> >
> > Nice:
> >         - Finish the 't_dd_' templates.
> >         - Port the remaining DRI drivers to 3.5. (tdfx in progress, trying
> >           to use the templates)
> >
> >
> > I think 3.5 is such a big step forward in terms of maintainability and
> > cleanliness that it's sensible to see it released as soon as seamliness
> > permits...
> 
> I'm doing a fairly comprehensive reworking of driver texture state and
> texture image handling that will touch core Mesa a bit, as well as
> change/add utility functions.  This will go into 3.5 and would be under
> the "Nice" category.

OK.

> I'd pretty much like to work on any of the above.  I might be
> particularly useful on the templates, having working copies for 3.4
> myself.  I'd also like to port at least one driver to 3.5 (r128 and mga
> are good candidates here).

You can have either or both of them...  

> Here's my Nice list:
> 
>         - General work on driver begin/end objects.
>         - Code generation for begin/end objects.
>         - Asm-optimized clipping, lighting code.
> 
> And after that (Really Nice?  Not As Nice?):
> 
>         - General work (like the old fastpath) to accelerate driver
>           rendering paths.

All this is good stuff but I think we can finalize 3.5 and do this afterwards
as seperate work.  (I'm not trying to push this back, just pull forwards the
3.5 release).  Using my list, I think a 3.5 release could occur after the
'crucial' and before the 'nice'...

The current code matches or beats the old fastpath, but for different
reasons.  So yes, path improvements are possible.  

> If you haven't started the tnl module swapping stuff, that might be a
> good thing for me to work on in the short term.

I haven't.  I've got a basic design I'll try and detail in a followup email.

Keith

Keith Whitwell wrote:
> 
> Brian, Gareth, and others,
> 
> I'm trying to nail down what's left to do for 3.5.  I've got a list of crucial
> and 'nice' items, maybe you can add your own items to the list & we can get
> some idea how close we are to nailing this down.
> 
> Crucial:
> 
>         - Floating point color support in 'tnl' module.  (in progress)
>         - Restore driver ability to swap in alternate tnl modules.
> 
> Nice:
>         - Finish the 't_dd_' templates.
>         - Port the remaining DRI drivers to 3.5. (tdfx in progress, trying
>           to use the templates)
> 
> 
> I think 3.5 is such a big step forward in terms of maintainability and
> cleanliness that it's sensible to see it released as soon as seamliness
> permits...

I'm doing a fairly comprehensive reworking of driver texture state and
texture image handling that will touch core Mesa a bit, as well as
change/add utility functions.  This will go into 3.5 and would be under
the "Nice" category.

I'd pretty much like to work on any of the above.  I might be
particularly useful on the templates, having working copies for 3.4
myself.  I'd also like to port at least one driver to 3.5 (r128 and mga
are good candidates here).

Here's my Nice list:

	- General work on driver begin/end objects.
	- Code generation for begin/end objects.
	- Asm-optimized clipping, lighting code.

And after that (Really Nice?  Not As Nice?):

	- General work (like the old fastpath) to accelerate driver
	  rendering paths.

If you haven't started the tnl module swapping stuff, that might be a
good thing for me to work on in the short term.

-- Gareth

Brian, Gareth, and others,

I'm trying to nail down what's left to do for 3.5.  I've got a list of crucial
and 'nice' items, maybe you can add your own items to the list & we can get
some idea how close we are to nailing this down.

Crucial:

	- Floating point color support in 'tnl' module.  (in progress)
	- Restore driver ability to swap in alternate tnl modules.

Nice:
	- Finish the 't_dd_' templates.
	- Port the remaining DRI drivers to 3.5. (tdfx in progress, trying to use the
templates)

I think 3.5 is such a big step forward in terms of maintainability and
cleanliness that it's sensible to see it released as soon as seamliness
permits...

Keith

On Mon, Feb 12, 2001 at 03:58:01PM +0000, Alan Hourihane wrote:
> On Mon, Feb 12, 2001 at 09:01:31AM -0700, Brian Paul wrote:
> > Alan Hourihane wrote:
> > > 
> > > Brian,
> > > 
> > > Did you pick up Nathan's fix for gloss (compacted normals) and the SI's
> > > libGLU (it's on the trunk DRI branch).
> > > 
> > > I think that should probably go in 3.4.1. - especially now the SI's libGLU
> > > is in the XFree86 tree.
> > 
> > I had asked Keith about this on Friday.  The Mesa 3.4.1 CVS texgen_tmp.h
> > file is still different from the DRI CVS code.  I wasn't sure which is
> > the correct version.
> > 
> > Sounds like the DRI CVS texgen_tmp.h (and texture.c) is the corrected
> > code.  Right?
> > 
> Yep. Nathan should confirm though.

Yep, the DRI CVS trunk has the corrected texture.c and texgen_tmp.h. 

-- 
The more I know about the WIN32 API the more I dislike it. It is complex and
for the most part poorly designed, inconsistent, and poorly documented.
                                                                - David Korn

2000	Jan	Feb	Mar (10)	Apr (28)	May (41)	Jun (91)	Jul (63)	Aug (45)	Sep (37)	Oct (80)	Nov (91)	Dec (47)
2001	Jan (48)	Feb (121)	Mar (126)	Apr (16)	May (85)	Jun (84)	Jul (115)	Aug (71)	Sep (27)	Oct (33)	Nov (15)	Dec (71)
2002	Jan (73)	Feb (34)	Mar (39)	Apr (135)	May (59)	Jun (116)	Jul (93)	Aug (40)	Sep (50)	Oct (87)	Nov (90)	Dec (32)
2003	Jan (181)	Feb (101)	Mar (231)	Apr (240)	May (148)	Jun (228)	Jul (156)	Aug (49)	Sep (173)	Oct (169)	Nov (137)	Dec (163)
2004	Jan (243)	Feb (141)	Mar (183)	Apr (364)	May (369)	Jun (251)	Jul (194)	Aug (140)	Sep (154)	Oct (167)	Nov (86)	Dec (109)
2005	Jan (176)	Feb (140)	Mar (112)	Apr (158)	May (140)	Jun (201)	Jul (123)	Aug (196)	Sep (143)	Oct (165)	Nov (158)	Dec (79)
2006	Jan (90)	Feb (156)	Mar (125)	Apr (146)	May (169)	Jun (146)	Jul (150)	Aug (176)	Sep (156)	Oct (237)	Nov (179)	Dec (140)
2007	Jan (144)	Feb (116)	Mar (261)	Apr (279)	May (222)	Jun (103)	Jul (237)	Aug (191)	Sep (113)	Oct (129)	Nov (141)	Dec (165)
2008	Jan (152)	Feb (195)	Mar (242)	Apr (146)	May (151)	Jun (172)	Jul (123)	Aug (195)	Sep (195)	Oct (138)	Nov (183)	Dec (125)
2009	Jan (268)	Feb (281)	Mar (295)	Apr (293)	May (273)	Jun (265)	Jul (406)	Aug (679)	Sep (434)	Oct (357)	Nov (306)	Dec (478)
2010	Jan (856)	Feb (668)	Mar (927)	Apr (269)	May (12)	Jun (13)	Jul (6)	Aug (8)	Sep (23)	Oct (4)	Nov (8)	Dec (11)
2011	Jan (4)	Feb (2)	Mar (3)	Apr (9)	May (6)	Jun	Jul (1)	Aug (1)	Sep	Oct (2)	Nov	Dec
2012	Jan	Feb	Mar	Apr	May	Jun	Jul (3)	Aug	Sep (1)	Oct	Nov	Dec
2013	Jan (2)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (7)	Nov (1)	Dec
2014	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec