Hi kids,
I've created a new branch to hold some less-than-beta quality code I've
been working on until
1) it gets really stable
and
2) we've got 3.1beta2 out
Or that's the plan anyway. The code is located on a branch named
'experimental-1'. If you want to get it, you should do:
cd MesaCVS/src
cvs update -r experimental-1
>From then on, all your updates and commits will be to the experimental
branch. You may well want to have two 'src' directories, one stable and
one experimental. To do this is easy:
cd MesaCVS
cp -pR src experimental-src
cd experimental-src
cvs update -r experimental-1
et voila! you have twice as many source directories as when we started!
Now you can have fun trying to remember which one you built most
recently, and whether the libs in the lib dir are stable or not.
THE CODE
========
I've committed some new code on that branch too. The most important
changes are
1) New fx_clip_tri routines, which do all clipping using floats (no
ubyte<->float color conversions), and which can cope with any data input
stride (removing a redundant copy, gads). These also do the 'fx_setup'
task inline, rather than calling back to the generic functions.
These seem to be about twice as fast (7ns/triangle) as the old way
(13ns/triangle).
2) Short-circuited gl_update_state() and gl_build_pipelines(). Removes
about half of the pipeline rebuilds in a normal Q3 run, and a similar
number of state updates.
3) Removed the old 'immediate' pipeline. Immediate mode is now a
special case of CVA, where nothing is precalculated. This isn't as
scary as it sounds, and makes a lot of sense at the coding level.
4) Pseudo-arrays for ctx->Current values (with zero stride) allow these
to be used as inputs to the precalc pipeline.
5) Pseudo-array for 'elts' in glDrawElements() allows us to reason
about this input in the same way as the others when building the precalc
pipeline.
6) Added a 'render_elts' pipeline stage for the _precalc_ pipeline,
meaning that if the elt input is present, the precalc pipeline does the
whole of the glDrawElements processing, including render. This is a lot
cleaner and makes it very clear when we have to fall back to the
immediate pipeline to finish the job.
7) Committed Josh's linux shared-lib profiling patch, and a couple of
(commented) makefile entries to make it go.
I'm sure there's more.
So, all in all, Quake3 is running something like 10-15% faster on that
branch. As I don't have a working timedemo, those figures could be out
by a mile. But 10% is a conservative guess based on the drawFPS output.
I'm now working on a single fast stage which does all of the transform,
setup, clip and render operations required in the normal Q3 precalc
pipeline. This will have a much better approach to clipping and setup
than is possible in the general pipeline, and will shave off a couple of
copy operations here and there. If this proves successful, I'll look at
pushing some of these techniques back into the greater Mesa.
Keith
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
