Discussion:
r200 new "revolutionary" lighting
(too old to reply)
Roland Scheidegger
2004-01-31 02:30:20 UTC
Permalink
Hello again

now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
This patch causes the driver to no longer use the PREMULT lighting,
instead it will use the SOURCE_MATERIAL stuff. Looking at r200_reg.h it
looked to me like the chip can handle a lot what is currently done in
software. So I changed that ;-)
What's new:
- no more bazillion calls of update_light_colors with lots of color
multiplications, since the chip handles that now itself.
- two-side-lighting with different materials no longer causes a tcl
fallback (so samples/fog now runs correctly, of course if you use
tcl_mode=0 it is still hosed - it looks like the tcl fallback if both
fog and two-side lighting are enabled is broken on both radeon and r200,
but that's another topic. It was the starting point for this patch
however, but I was unable to figure out what's wrong with the fallback.
The tnl stuff is scary :-().
- removed the strange fallback if materials between begin / end were
discovered. Couldn't figure out why it was there (the comment said the
chip handles it just fine?), I thought maybe because material changes
caused for instance lighting updates, which now no longer happens. Well
so far it didn't lock up...

There are some things I'm unsure about. For one, the
update_global_ambient now has an impossible if condition, but I have no
idea if the function works correctly now or not - it could also work
better than before, who knows ;-). There's also a lot of guesswork
involved, but at first glance things seemed to look quite good - the
patch passes the nwn and glxgears test ;-) (and some others too, but
didn't test extensively yet).

Maybe I missed something important and this lighting code fails in some
cases horribly, but if not I think this lighting code would be much
nicer (it should likely also help TNL performance quite a bit, unless
you run on a P5 10Ghz). The code is also quite a bit simpler than before
IMHO, most of the code is just two large copy/paste if statements.

Comments?

Roland
btw from looking at the radeon_reg.h it seems the same changes could be
done for the radeon, except the two-sided-lighting with materials which
the chip doesn't seem to handle.
Ronny V. Vindenes
2004-01-31 19:18:20 UTC
Permalink
Post by Roland Scheidegger
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
patching file r200_state.c
Hunk #2 succeeded at 810 with fuzz 1.
Hunk #3 FAILED at 820.
1 out of 9 hunks FAILED -- saving rejects to file r200_state.c.rej
patching file r200_state_init.c

Sounds good on paper though :)
--
Ronny V. Vindenes <***@ii.uib.no>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Roland Scheidegger
2004-01-31 21:34:49 UTC
Permalink
Post by Ronny V. Vindenes
Post by Roland Scheidegger
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
patching file r200_state.c
Hunk #2 succeeded at 810 with fuzz 1.
Hunk #3 FAILED at 820.
1 out of 9 hunks FAILED -- saving rejects to file r200_state.c.rej
patching file r200_state_init.c
Sounds good on paper though :)
I guess good on paper isn't quite good enough ;-).
Looks like some whitespace trouble, should be fixed with this patch. It
has also some initialization ugliness fixed, and there is some new code
(but it's outcommented as I can't test it right now and I'm not sure if
it's needed or if will just lock up the chip...) which might fix some
shininess trouble (I don't know if there is trouble or not, I'll try to
test it next week if I manage to hack up some testcase - I've still not
written even the equivalent of a "hello world" program in OpenGL...).

Roland
Dieter Nützel
2004-01-31 21:51:02 UTC
Permalink
Post by Roland Scheidegger
Post by Ronny V. Vindenes
Post by Roland Scheidegger
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
patching file r200_state.c
Hunk #2 succeeded at 810 with fuzz 1.
Hunk #3 FAILED at 820.
1 out of 9 hunks FAILED -- saving rejects to file r200_state.c.rej
patching file r200_state_init.c
Sounds good on paper though :)
I guess good on paper isn't quite good enough ;-).
Looks like some whitespace trouble, should be fixed with this patch.
Sorry Roland, NO go:

182 22:47 patch -p0 -E -N < ~/Dokumente/DRI-Mesa/r200_colormatfix.diff
184 22:47 cd src/mesa/drivers/dri/radeon/
185 22:47 patch -p0 -E -N < ~/Dokumente/DRI-Mesa/radeon_colormatfix.diff
186 22:47 cd -
187 22:47 cd src/mesa/drivers/dri/r200
188 22:47 patch -p0 -E -N < ~/Dokumente/DRI-Mesa/r200_newlight-2.diff

dri/r200> patch -p0 -E -N < ~/Dokumente/DRI-Mesa/r200_newlight-2.diff
patching file r200_state.c
Hunk #3 FAILED at 820.
Hunk #4 succeeded at 945 (offset -6 lines).
Hunk #5 succeeded at 985 (offset -6 lines).
Hunk #6 succeeded at 1233 (offset -6 lines).
Hunk #7 succeeded at 1851 (offset -6 lines).
Hunk #8 succeeded at 2171 (offset -6 lines).
Hunk #9 succeeded at 2184 (offset -6 lines).
1 out of 9 hunks FAILED -- saving rejects to file r200_state.c.rej
patching file r200_state_init.c

What about a new S3TC on-top of this? ;-)

Greetings,
Dieter


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Roland Scheidegger
2004-02-01 01:45:07 UTC
Permalink
Post by Dieter Nützel
182 22:47 patch -p0 -E -N < ~/Dokumente/DRI-Mesa/r200_colormatfix.diff
184 22:47 cd src/mesa/drivers/dri/radeon/
185 22:47 patch -p0 -E -N < ~/Dokumente/DRI-Mesa/radeon_colormatfix.diff
186 22:47 cd -
187 22:47 cd src/mesa/drivers/dri/r200
188 22:47 patch -p0 -E -N < ~/Dokumente/DRI-Mesa/r200_newlight-2.diff
patching this with the earlier colormaterial fix won't work - it
replaces the code touched there anyway.
Post by Dieter Nützel
(patch against cvs, without the earlier colormat fix).
What about a new S3TC on-top of this? ;-)
I won't publish s3tc patches done against other patches - that's
patching hell. The last patch should still work fine though I believe
(except that broken debug printf which you'll need to fix), it touches
completely different sections of the driver.

Roland


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Dieter Nützel
2004-02-02 21:31:09 UTC
Permalink
Post by Roland Scheidegger
Post by Ronny V. Vindenes
Post by Roland Scheidegger
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
patching file r200_state.c
Hunk #2 succeeded at 810 with fuzz 1.
Hunk #3 FAILED at 820.
1 out of 9 hunks FAILED -- saving rejects to file r200_state.c.rej
patching file r200_state_init.c
Sounds good on paper though :)
I guess good on paper isn't quite good enough ;-).
Looks like some whitespace trouble, should be fixed with this patch. It
has also some initialization ugliness fixed, and there is some new code
(but it's outcommented as I can't test it right now and I'm not sure if
it's needed or if will just lock up the chip...) which might fix some
shininess trouble (I don't know if there is trouble or not, I'll try to
test it next week if I manage to hack up some testcase - I've still not
written even the equivalent of a "hello world" program in OpenGL...).
This time WITHOUT r200_colormatfix.diff...

...where are my copies of DRI-Devel?
Some server slowdown?

Your are the MAN!

Finally RIGHT light _with TCL on VTK.

PipelineParallelism
ParallelIso
ParallelIsoTest
TaskParallelismWithPorts

TaskParallelism colors are right, too but multi context (two) problems
(hangs).


HIGHLIGHT:

VTK Simple Sphere Benchmark 2.1

- Robert Riviere (results) : ***@sophia.inria.fr
www.inria.fr/caiman/personnel/Robert.Riviere/vtk/sphere-bench.html

- Sebastien Barre (script) : ***@utc.fr
www.hds.utc.fr/~barre/vtk/sphere-bench.html

Find the best sphere resolutions for your card, launch *bench combinations*
and send us your results (copy the session with <Control />) along with a
complete description of your system (VTK/OS version, hardware description).

System :
- i686 running Linux 2.6.1-0-smp-DN
- VTK 4.5.0 (rev: 1.1810, 2004/02/02 02:45:41)
- OpenGL
- Visual is 1280x1024, truecolor/truecolor/24
- Tcl/Tk 8.4.4

Defaults :
WARNING : $active_camera GetClippingRange was 2.45199 4.78654 , should be
0.348564 17.4282
- VTK : wrong, please report us your values...
- Rotation limit, increment, number : (300 by 30) x 3
- Sphere opacity (if transparency activated) : 0.3
- Sphere radius and small radius (if small_sphere activated) : 0.9, 0.5
- Combinations : [stripper] [small_sphere] [] [transparency] [wireframe]
[texture] [texture, transparency]

NOTE : the 512x512 and above sphere resolutions are *really* high, use them
carefully, as it might hang your system for a while. Moreover, they have no
real signification in 400x400 or less window.

IMPORTANT : move the camera a little to interact with the sphere before
playing with this bench...

Benching for sphere resolutions : 32, 64, 128, 256, 512
Setting(s) : window is 400 x 400, sphere radius is 0.9
Option(s) : [stripper]
32x32 : 861.3 kpolys/s
64x64 : 2714.2 kpolys/s
128x128 : 4407.5 kpolys/s
256x256 : 4598.0 kpolys/s
512x512 : 5862.9 kpolys/s

Without the 50% regression (take place during Mesa 6.0/6.1 merge) we were the
leader...;-)

Same with TimeRenderer and TimeRenderer2.

Cheers,
Dieter


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Michel Dänzer
2004-02-02 21:48:15 UTC
Permalink
Post by Roland Scheidegger
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
Good work! This fixes neverball and neverputt here, and improves
trackballs a lot (in foggy levels, the ground used to be mostly
invisible; now it's visible, but white (the fog colour) instead of the
correct colour about half the time).
[...] some whitespace trouble, should be fixed with this patch. It
has also some initialization ugliness fixed, and there is some new code
(but it's outcommented as I can't test it right now and I'm not sure if
it's needed or if will just lock up the chip...) which might fix some
shininess trouble [...]
Any news on that?
@@ -2130,29 +2177,10 @@
r200VtxfmtInvalidate( ctx );
}
-/* A hack. The r200 can actually cope just fine with materials
- * between begin/ends, so fix this.
- */
-static GLboolean check_material( GLcontext *ctx )
-{
- TNLcontext *tnl = TNL_CONTEXT(ctx);
- GLint i;
-
- for (i = _TNL_ATTRIB_MAT_FRONT_AMBIENT;
- i < _TNL_ATTRIB_MAT_BACK_INDEXES;
- i++)
- if (tnl->vb.AttribPtr[i] &&
- tnl->vb.AttribPtr[i]->stride)
- return GL_TRUE;
-
- return GL_FALSE;
-}
-
static void r200WrapRunPipeline( GLcontext *ctx )
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
- GLboolean has_material;
if (0)
fprintf(stderr, "%s, newstate: %x\n", __FUNCTION__, rmesa->NewGLState);
@@ -2162,19 +2190,11 @@
if (rmesa->NewGLState)
r200ValidateState( ctx );
- has_material = (ctx->Light.Enabled && check_material( ctx ));
-
- if (has_material) {
- TCL_FALLBACK( ctx, R200_TCL_FALLBACK_MATERIAL, GL_TRUE );
- }
/* Run the pipeline.
*/
_tnl_run_pipeline( ctx );
- if (has_material) {
- TCL_FALLBACK( ctx, R200_TCL_FALLBACK_MATERIAL, GL_FALSE );
- }
}
Reverting this part (which you suspect causes a viewperf segfault,
right?) returns trackballs to the old, very broken behaviour, so there
seems to be some good to it after all. :)


About keeping track of your patches: I wonder what others think about
giving you write access?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Alan Hourihane
2004-02-02 22:08:02 UTC
Permalink
Post by Michel Dänzer
About keeping track of your patches: I wonder what others think about
giving you write access?
Go for it.

Alan.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Michel Dänzer
2004-02-02 22:09:57 UTC
Permalink
Post by Alan Hourihane
Post by Michel Dänzer
About keeping track of your patches: I wonder what others think about
giving you write access?
Go for it.
I would, but I can't.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Alan Hourihane
2004-02-02 22:11:35 UTC
Permalink
Post by Michel Dänzer
Post by Alan Hourihane
Post by Michel Dänzer
About keeping track of your patches: I wonder what others think about
giving you write access?
Go for it.
I would, but I can't.
Maybe Eric can do it, but I think there should be others with Eric's
access ability so these others can do it too.

Alan.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Michel Dänzer
2004-02-02 22:39:36 UTC
Permalink
Post by Alan Hourihane
Post by Michel Dänzer
Post by Alan Hourihane
Post by Michel Dänzer
About keeping track of your patches: I wonder what others think about
giving you [Roland Scheidegger] write access?
Go for it.
I would, but I can't.
Maybe Eric can do it, but I think there should be others with Eric's
access ability so these others can do it too.
At any rate, we should probably wait for Keith's opinion.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Keith Whitwell
2004-02-03 11:29:31 UTC
Permalink
Post by Michel Dänzer
Post by Alan Hourihane
Post by Michel Dänzer
Post by Alan Hourihane
Post by Michel Dänzer
About keeping track of your patches: I wonder what others think about
giving you [Roland Scheidegger] write access?
Go for it.
I would, but I can't.
Maybe Eric can do it, but I think there should be others with Eric's
access ability so these others can do it too.
At any rate, we should probably wait for Keith's opinion.
Yep, all for it, in fact I finally woke up to just how much work Roland has
been doing a couple of days ago and "popped the question" in another email...
If he doesn't have it already, it's down to the fd.o guys to sort it out. I
think Eric's on holiday.

Keith




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Dave Airlie
2004-02-02 22:33:36 UTC
Permalink
Post by Alan Hourihane
Post by Michel Dänzer
I would, but I can't.
Maybe Eric can do it, but I think there should be others with Eric's
access ability so these others can do it too.
I think contacting keithp if Eric is away...

Dave.
Post by Alan Hourihane
Alan.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
_______________________________________________
Dri-devel mailing list
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Roland Scheidegger
2004-02-02 22:57:56 UTC
Permalink
Post by Michel Dänzer
Post by Roland Scheidegger
now that the lighting bugs are finally mostly gone, I've just
gone ahead and changed the lighting code a bit more... (patch
against cvs, without the earlier colormat fix).
Good work! This fixes neverball and neverputt here, and improves
trackballs a lot (in foggy levels, the ground used to be mostly
invisible; now it's visible, but white (the fog colour) instead of
the correct colour about half the time).
[...] some whitespace trouble, should be fixed with this patch. It
has also some initialization ugliness fixed, and there is some new
code (but it's outcommented as I can't test it right now and I'm
not sure if it's needed or if will just lock up the chip...) which
might fix some shininess trouble [...]
Any news on that?
Looks like it's not necessary. The OpenGL spec doesn't explicitly say
it, but the specular exponent always seems to use what's specified with
the color material - even if it is set to track the specular value of
the current vertex (the spec DOES say it tracks the specular value, and
says nothing about the specualar exponent, so I guess it implicitly says
the specular value will still use the value from the color material).
Using some hacked-up samples/wave demo, mesa at least acts that way too.
I guess changing this shininess parameter there in the lighing model
would only be useful for some funky vertex programs...
Post by Michel Dänzer
@@ -2130,29 +2177,10 @@ r200VtxfmtInvalidate( ctx ); }
-/* A hack. The r200 can actually cope just fine with materials -
* between begin/ends, so fix this. - */ -static GLboolean
check_material( GLcontext *ctx ) -{ - TNLcontext *tnl =
TNL_CONTEXT(ctx); - GLint i; - - for (i =
_TNL_ATTRIB_MAT_FRONT_AMBIENT; - i < _TNL_ATTRIB_MAT_BACK_INDEXES;
- i++) - if (tnl->vb.AttribPtr[i] && -
tnl->vb.AttribPtr[i]->stride) - return GL_TRUE; - - return
GL_FALSE; -} -
static void r200WrapRunPipeline( GLcontext *ctx ) { r200ContextPtr
rmesa = R200_CONTEXT(ctx); - GLboolean has_material;
if (0) fprintf(stderr, "%s, newstate: %x\n", __FUNCTION__,
r200ValidateState( ctx );
- has_material = (ctx->Light.Enabled && check_material( ctx )); -
- if (has_material) { - TCL_FALLBACK( ctx,
R200_TCL_FALLBACK_MATERIAL, GL_TRUE ); - }
/* Run the pipeline. */ _tnl_run_pipeline( ctx );
- if (has_material) { - TCL_FALLBACK( ctx,
R200_TCL_FALLBACK_MATERIAL, GL_FALSE ); - } }
Reverting this part (which you suspect causes a viewperf segfault,
right?) returns trackballs to the old, very broken behaviour, so
there seems to be some good to it after all. :)
Actually, no it doesn't cause the segfault, regardless if it's there or
not running with tcl_mode=0 always segfaults specviewperf proe02. It
"only" causes the rendering errors in viewperf proe-02 (which is what's
so strange, the other parts of the patch look completely innocent
regarding the sw tcl pipeline). Without switching tcl off, it will not
segfault, neither with this applied or not (even though it will cause a
fallback).
The rendering errors look like some material changes simply are missed
(or maybe submitted too late, after the primitive is already drawn?), as
the color used isn't arbitrary - it always seems to be one used by
adjacent vertices.
Does trackball use two-sided lighting and fog? The TCL fallback for this
case seems to be broken (playing a bit with samples/fog indicates that
switching off either of them fixes the problem, though I've no idea
where to look for the problem, software mesa works just fine).
Post by Michel Dänzer
About keeping track of your patches: I wonder what others think about
giving you write access?
Looks like that's already in the works (it was Keith's suggestion), I've
submitted a ssh key yesterday :-).

Roland


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Michel Dänzer
2004-02-03 00:04:32 UTC
Permalink
Post by Roland Scheidegger
The rendering errors look like some material changes simply are missed
(or maybe submitted too late, after the primitive is already drawn?),
My suspicion as well.
Post by Roland Scheidegger
as the color used isn't arbitrary - it always seems to be one used by
adjacent vertices.
Does trackball use two-sided lighting and fog?
Dunno, possibly, but I noticed it also happens without fog; all ground
vertices seem to be the colour of a random vertex. With tcl_mode=1 there
are several colours, but it's still not correct.
Post by Roland Scheidegger
The TCL fallback for this case seems to be broken (playing a bit with
samples/fog indicates that switching off either of them fixes the
problem, though I've no idea where to look for the problem, software
mesa works just fine).
As does SW TCL for trackballs.
Post by Roland Scheidegger
Post by Michel Dänzer
About keeping track of your patches: I wonder what others think about
giving you write access?
Looks like that's already in the works (it was Keith's suggestion), I've
submitted a ssh key yesterday :-).
Great.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Keith Whitwell
2004-01-31 20:12:29 UTC
Permalink
Post by Roland Scheidegger
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
This patch causes the driver to no longer use the PREMULT lighting,
instead it will use the SOURCE_MATERIAL stuff. Looking at r200_reg.h it
looked to me like the chip can handle a lot what is currently done in
software. So I changed that ;-)
Most of the restrictions in the r200 code are caused by the driver being
forked off the original radeon - the restrictions relate to that chip, not the
r200. Lifting them has been a long-time todo item. The new tnl code which
treats materials in much the same way as other vertex attributes was a step in
this direction.
Post by Roland Scheidegger
- no more bazillion calls of update_light_colors with lots of color
multiplications, since the chip handles that now itself.
- two-side-lighting with different materials no longer causes a tcl
fallback (so samples/fog now runs correctly, of course if you use
tcl_mode=0 it is still hosed - it looks like the tcl fallback if both
fog and two-side lighting are enabled is broken on both radeon and r200,
but that's another topic. It was the starting point for this patch
however, but I was unable to figure out what's wrong with the fallback.
The tnl stuff is scary :-().
- removed the strange fallback if materials between begin / end were
discovered. Couldn't figure out why it was there (the comment said the
chip handles it just fine?), I thought maybe because material changes
caused for instance lighting updates, which now no longer happens. Well
so far it didn't lock up...
Another hangover from the r100, which can't handle this at all. The r200
should do just fine.
Post by Roland Scheidegger
There are some things I'm unsure about. For one, the
update_global_ambient now has an impossible if condition, but I have no
idea if the function works correctly now or not - it could also work
better than before, who knows ;-). There's also a lot of guesswork
involved, but at first glance things seemed to look quite good - the
patch passes the nwn and glxgears test ;-) (and some others too, but
didn't test extensively yet).
Maybe I missed something important and this lighting code fails in some
cases horribly, but if not I think this lighting code would be much
nicer (it should likely also help TNL performance quite a bit, unless
you run on a P5 10Ghz). The code is also quite a bit simpler than before
IMHO, most of the code is just two large copy/paste if statements.
No, just clearing out the cobwebs. Good work. I'll try and have a closer
look at the patch.

Keith



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Dieter Nützel
2004-01-31 21:45:01 UTC
Permalink
Post by Roland Scheidegger
Comments?
Roland
btw from looking at the radeon_reg.h it seems the same changes could be
done for the radeon, except the two-sided-lighting with materials which
the chip doesn't seem to handle.
I get this (after applying radeon_colormatfix.diff and r200_colormatfix.diff):

dri/r200> patch -p0 -E -N < ~/Dokumente/DRI-Mesa/r200_newlight.diff
patching file r200_state.c
Hunk #2 succeeded at 810 with fuzz 1.
Hunk #3 FAILED at 820.
Hunk #4 succeeded at 926 (offset -6 lines).
Hunk #5 succeeded at 966 (offset -6 lines).
Hunk #6 succeeded at 1213 (offset -6 lines).
Hunk #7 succeeded at 1834 (offset -6 lines).
Hunk #8 succeeded at 2154 (offset -6 lines).
Hunk #9 succeeded at 2167 (offset -6 lines).
1 out of 9 hunks FAILED -- saving rejects to file r200_state.c.rej
patching file r200_state_init.c

Cheers,
Dieter

BTW Can't wait to see the speedup and hopefully "right" colors with TCL on
VTK.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Ronny V. Vindenes
2004-02-01 13:40:08 UTC
Permalink
Post by Roland Scheidegger
Hello again
now that the lighting bugs are finally mostly gone, I've just gone ahead
and changed the lighting code a bit more... (patch against cvs, without
the earlier colormat fix).
This patch causes the driver to no longer use the PREMULT lighting,
instead it will use the SOURCE_MATERIAL stuff. Looking at r200_reg.h it
looked to me like the chip can handle a lot what is currently done in
software. So I changed that ;-)
- no more bazillion calls of update_light_colors with lots of color
multiplications, since the chip handles that now itself.
- two-side-lighting with different materials no longer causes a tcl
fallback (so samples/fog now runs correctly, of course if you use
tcl_mode=0 it is still hosed - it looks like the tcl fallback if both
fog and two-side lighting are enabled is broken on both radeon and r200,
but that's another topic. It was the starting point for this patch
however, but I was unable to figure out what's wrong with the fallback.
The tnl stuff is scary :-().
- removed the strange fallback if materials between begin / end were
discovered. Couldn't figure out why it was there (the comment said the
chip handles it just fine?), I thought maybe because material changes
caused for instance lighting updates, which now no longer happens. Well
so far it didn't lock up...
There are some things I'm unsure about. For one, the
update_global_ambient now has an impossible if condition, but I have no
idea if the function works correctly now or not - it could also work
better than before, who knows ;-). There's also a lot of guesswork
involved, but at first glance things seemed to look quite good - the
patch passes the nwn and glxgears test ;-) (and some others too, but
didn't test extensively yet).
Maybe I missed something important and this lighting code fails in some
cases horribly, but if not I think this lighting code would be much
nicer (it should likely also help TNL performance quite a bit, unless
you run on a P5 10Ghz). The code is also quite a bit simpler than before
IMHO, most of the code is just two large copy/paste if statements.
Comments?
OK, I've spent a few hours playing with the updated patch today, and all
I can say is: Good work! It fixes lighting and fog issues in many cases
(including one program that segfaults without it). Also, in most the
programs I've tested there are small performance improvements* (~5 fps),
but the most noticable improvement (other than visual issues) is that
cpu load is much lower now, especially in combination with wine.

I haven't found any regressions, and unless someone finds some big
error, I think this should be merged asap.

My setup is Athlon64 3200, 1gb ram and radeon 9000 128mb running linux
2.6.2-rc2-mm2. Programs tested include ET, UT, Postal 2, NWN, Quake 3,
Civ 3 (wine) and tons of OpenGL (native and wine) and Direct3D demos.

* Notable exception being nwn which is still just as slow, but atleast
it looks correct now.
--
Ronny V. Vindenes <***@ii.uib.no>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Roland Scheidegger
2004-02-02 21:17:30 UTC
Permalink
Post by Ronny V. Vindenes
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are small performance
improvements* (~5 fps), but the most noticable improvement (other
than visual issues) is that cpu load is much lower now, especially in
combination with wine.
good to know. Those things I tested didn't really get much of a
performance improvement, except some of the specviewperf benchmarks
(probably those which used two-sided lighting).
Post by Ronny V. Vindenes
I haven't found any regressions, and unless someone finds some big
error, I think this should be merged asap.
Not so fast, I did find some errors, though they are strange. Both can
easily be seen with specviewperf 7.1 proe-02. First, the elimination of
the tcl fallback if materials between begin/end were discovered
introduced some severe rendering errors (looks like the wrong materials
are used in some parts of the car).
Second, and I have absolutely no idea what the heck caused this, running
the same proe-02 test with tcl_mode=0 now causes a segfault. The patch
doesn't seem to touch anything which could be related to that (and the
reintroduction of the material between begin/end fallback didn't help
here neither), any ideas?
gdb shows this:
Program received signal SIGSEGV, Segmentation fault.
triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
179 GLfloat (*vbcolor)[4] = VB->ColorPtr[1]->data;
(gdb) bt
#0 triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
#1 0x3b03bb45 in _tnl_render_tri_strip_verts (ctx=0x8139220, start=7,
count=8, flags=53)
at t_vb_rendertmp.h:211
#2 0x3b03ccd0 in run_render (ctx=0x8139220, stage=0x0) at t_vb_render.c:323
#3 0x3b02ac22 in _tnl_run_pipeline (ctx=0x8139220) at t_pipeline.c:159
#4 0x3b0496a6 in _tnl_flush_vtx (ctx=0x8139220) at t_vtx_exec.c:282
#5 0x3b048597 in _tnl_FlushVertices (ctx=0x8139220, flags=1) at
t_vtx_api.c:1131
#6 0x3b068a45 in r200FlushVertices (ctx=0x8139220, flags=1) at
r200_swtcl.c:1215
#7 0x3af9411c in _mesa_PopMatrix () at matrix.c:269
#8 0x0805dd9d in my_glLoadMatrix ()
#9 0x0807eacb in varrayRmmVn ()
#10 0x0805dc67 in mesh3Event ()
#11 0x080606c6 in evtI ()
#12 0x0805b10b in main ()
#13 0x3ad1f4c2 in __libc_start_main () from /lib/i686/libc.so.6
Post by Ronny V. Vindenes
My setup is Athlon64 3200, 1gb ram and radeon 9000 128mb running
linux 2.6.2-rc2-mm2. Programs tested include ET, UT, Postal 2, NWN,
Quake 3, Civ 3 (wine) and tons of OpenGL (native and wine) and
Direct3D demos.
* Notable exception being nwn which is still just as slow, but
atleast it looks correct now.
It should look correct with only the colormat fixed applied too.
For me, it does seem to run slightly better (didn't really measure it
though, but my pc is only half as fast as yours, so it's natural I'd
benefit more from moving some light calculations from the cpu the the
gpu). I've oprofiled it a bit, but couldn't see something special. Looks
like it's just not meant to be fast (and I'm sure you know that this
game is known to run at suboptimal speed at pretty much anything other
than Nvidia GF4, even the GFFX and ATI 9800XT with the latest windows
drivers won't be as fast). Hyper-Z would almost certainly help though...

Roland


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Keith Whitwell
2004-02-03 09:01:01 UTC
Permalink
Post by Roland Scheidegger
Post by Ronny V. Vindenes
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are small performance
improvements* (~5 fps), but the most noticable improvement (other
than visual issues) is that cpu load is much lower now, especially in
combination with wine.
good to know. Those things I tested didn't really get much of a
performance improvement, except some of the specviewperf benchmarks
(probably those which used two-sided lighting).
Post by Ronny V. Vindenes
I haven't found any regressions, and unless someone finds some big
error, I think this should be merged asap.
Not so fast, I did find some errors, though they are strange. Both can
easily be seen with specviewperf 7.1 proe-02. First, the elimination of
the tcl fallback if materials between begin/end were discovered
introduced some severe rendering errors (looks like the wrong materials
are used in some parts of the car).
Second, and I have absolutely no idea what the heck caused this, running
the same proe-02 test with tcl_mode=0 now causes a segfault. The patch
doesn't seem to touch anything which could be related to that (and the
reintroduction of the material between begin/end fallback didn't help
here neither), any ideas?
Program received signal SIGSEGV, Segmentation fault.
triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
179 GLfloat (*vbcolor)[4] = VB->ColorPtr[1]->data;
(gdb) bt
#0 triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
Looks like the triangle function chosen by the driver is out of step with the
actual state. IE, the trifunc is set for two-sided lighting, but it hasn't
actually been performed, because it's not enabled.

This is occuring in a swtcl fallback, so the code to look at is probably
called r200ChooseRenderFunc() or similar in r200_swtcl.c.

It could also be the opposite, that 2-sided lighting hasn't been performed
when it should have been, but I think this less likely.

Keith





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Roland Scheidegger
2004-02-03 13:02:57 UTC
Permalink
Post by Keith Whitwell
Post by Roland Scheidegger
Post by Ronny V. Vindenes
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are small performance
improvements* (~5 fps), but the most noticable improvement (other
than visual issues) is that cpu load is much lower now, especially in
combination with wine.
good to know. Those things I tested didn't really get much of a
performance improvement, except some of the specviewperf benchmarks
(probably those which used two-sided lighting).
Post by Ronny V. Vindenes
I haven't found any regressions, and unless someone finds some big
error, I think this should be merged asap.
Not so fast, I did find some errors, though they are strange. Both can
easily be seen with specviewperf 7.1 proe-02. First, the elimination
of the tcl fallback if materials between begin/end were discovered
introduced some severe rendering errors (looks like the wrong
materials are used in some parts of the car).
Second, and I have absolutely no idea what the heck caused this,
running the same proe-02 test with tcl_mode=0 now causes a segfault.
The patch doesn't seem to touch anything which could be related to
that (and the reintroduction of the material between begin/end
fallback didn't help here neither), any ideas?
Program received signal SIGSEGV, Segmentation fault.
triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
179 GLfloat (*vbcolor)[4] = VB->ColorPtr[1]->data;
(gdb) bt
#0 triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
Looks like the triangle function chosen by the driver is out of step
with the actual state. IE, the trifunc is set for two-sided lighting,
but it hasn't actually been performed, because it's not enabled.
This is occuring in a swtcl fallback, so the code to look at is probably
called r200ChooseRenderFunc() or similar in r200_swtcl.c.
It could also be the opposite, that 2-sided lighting hasn't been
performed when it should have been, but I think this less likely.
Keith
Oops! You're right on track, I've removed the call to
r200ChooseRenderstate when the lighting model changed to two-side
together with the twoside fallback check. Really bad idea, works now again.

The rendering errors are a harder problem though, I can see now why the
material between begin/end fallback was needed in the first place. There
doesn't seem to be an easy way currently to submit material changes
between vertices, so it looks like the fallback needs to stay (even
though it doesn't really seem to work correctly neither for some reason).

Roland


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Roland Scheidegger
2004-02-03 22:52:23 UTC
Permalink
Post by Roland Scheidegger
The rendering errors are a harder problem though, I can see now why
the material between begin/end fallback was needed in the first place.
There doesn't seem to be an easy way currently to submit material
changes between vertices, so it looks like the fallback needs to stay
(even though it doesn't really seem to work correctly neither for some
reason).
Certainly the bug with the current code should be resolved - I can't
think it's too difficult - as the r100 will need it.
The r200 *can* do material changes inside begin/end - basically by using
the R200_LM1_SOURCE_VERTEX_COLOR_0..7 arrays to track the material
attributes and then wiring each of these up just like in the
glColorMaterial case.
I don't doubt the *chip* can do - I just doubt *I* can do it ;-).
Wouldn't it be necessary (and sufficient) just to update the two (front
and back) materials, or are you suggesting that it's necessary to send
the materials along with the other vertex parameters such as the
normals, colors etc.
But updating the current materials would mean that the vertices up to
now have to be flushed (?), since as far as I understand the driver it
doesn't allow vertex data to be mixed arbitrarily with other state
change commands. I'll admit though I don't understand it really...
I tried to implement something like that as a quick hack - it fixed the
errors, but looking a bit closer not for the reasons I thought it might
help. I just called _tnl_FlushVertices( ctx, ~0 ) at the end of
_tnl_Materialfv (t_vtx_api.c), but the strange thing is as far as I can
see this won't do anything if it's called inside a primitive.
Nevertheless, it fixed the rendering errors in specivewperf proe-02. Wierd.

Roland


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Keith Whitwell
2004-02-03 15:37:04 UTC
Permalink
Post by Roland Scheidegger
Post by Keith Whitwell
Post by Roland Scheidegger
Post by Ronny V. Vindenes
OK, I've spent a few hours playing with the updated patch today, and
all I can say is: Good work! It fixes lighting and fog issues in many
cases (including one program that segfaults without it). Also, in
most the programs I've tested there are small performance
improvements* (~5 fps), but the most noticable improvement (other
than visual issues) is that cpu load is much lower now, especially in
combination with wine.
good to know. Those things I tested didn't really get much of a
performance improvement, except some of the specviewperf benchmarks
(probably those which used two-sided lighting).
Post by Ronny V. Vindenes
I haven't found any regressions, and unless someone finds some big
error, I think this should be merged asap.
Not so fast, I did find some errors, though they are strange. Both
can easily be seen with specviewperf 7.1 proe-02. First, the
elimination of the tcl fallback if materials between begin/end were
discovered introduced some severe rendering errors (looks like the
wrong materials are used in some parts of the car).
Second, and I have absolutely no idea what the heck caused this,
running the same proe-02 test with tcl_mode=0 now causes a segfault.
The patch doesn't seem to touch anything which could be related to
that (and the reintroduction of the material between begin/end
fallback didn't help here neither), any ideas?
Program received signal SIGSEGV, Segmentation fault.
triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
179 GLfloat (*vbcolor)[4] = VB->ColorPtr[1]->data;
(gdb) bt
#0 triangle_twoside (ctx=0x8139220, e0=4, e1=5, e2=6) at
/usr/tmp/Mesa/src/mesa/tnl_dd/t_dd_tritmp.h:179
Looks like the triangle function chosen by the driver is out of step
with the actual state. IE, the trifunc is set for two-sided lighting,
but it hasn't actually been performed, because it's not enabled.
This is occuring in a swtcl fallback, so the code to look at is
probably called r200ChooseRenderFunc() or similar in r200_swtcl.c.
It could also be the opposite, that 2-sided lighting hasn't been
performed when it should have been, but I think this less likely.
Keith
Oops! You're right on track, I've removed the call to
r200ChooseRenderstate when the lighting model changed to two-side
together with the twoside fallback check. Really bad idea, works now again.
The rendering errors are a harder problem though, I can see now why the
material between begin/end fallback was needed in the first place. There
doesn't seem to be an easy way currently to submit material changes
between vertices, so it looks like the fallback needs to stay (even
though it doesn't really seem to work correctly neither for some reason).
Certainly the bug with the current code should be resolved - I can't think
it's too difficult - as the r100 will need it.

The r200 *can* do material changes inside begin/end - basically by using the
R200_LM1_SOURCE_VERTEX_COLOR_0..7 arrays to track the material attributes and
then wiring each of these up just like in the glColorMaterial case.

Keith



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Chris Ison
2004-02-03 20:30:00 UTC
Permalink
I've compiled compiled and installed Xfree86, DRI from cvs, with mesa cvs,
last night, thismorning I confirmed it all worked by loading the radeon drm
and running glxinfo showing direct rendering enabled

however, when I ran glxgears, I get a libGL error saying it couldn't load
the drm and it was reverting to indirect rendering :/


Any ideas at all? a step I missed?
grabed cvs of xfree86 xc, dri xc, mesa
make World of xfree86, make install
make World of dri, make install
move radeon.ko to /lib/module/2.6.2-rc3-mm1/kernel/drivers/char/drm/
insmod radeon.ko
startx
glxgears to confirm

There are No errors in the xfree86 log, this seems to be a libGL error


The card has the r250 chip.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Michel Dänzer
2004-02-04 11:45:16 UTC
Permalink
Post by Chris Ison
I've compiled compiled and installed Xfree86, DRI from cvs, with mesa cvs,
last night, thismorning I confirmed it all worked by loading the radeon drm
and running glxinfo showing direct rendering enabled
however, when I ran glxgears, I get a libGL error saying it couldn't load
the drm and it was reverting to indirect rendering :/
Please post the actual output of LIBGL_DEBUG=verbose glxgears instead of
paraphrasing.


PS: With my list admin hat on: Please don't follow up to an existing
thread when posting on a new, unrelated topic. And this was the last time
I manually approved a post of yours. Please subscribe like everyone else.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Dave Airlie
2004-02-04 11:57:07 UTC
Permalink
Post by Chris Ison
however, when I ran glxgears, I get a libGL error saying it couldn't load
the drm and it was reverting to indirect rendering :/
do you have your board agp module installed? and insmodded? this in't done
automatically since 2.6 kernels .. for Intel you need modprobe intel-agp
somewhere..

Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Chris Ison
2004-02-04 12:53:22 UTC
Permalink
thanks, turned out to be a permissions thing, dunno how they changed.

Also note, its a PCI Radeon 9000, this AMD athlon 2000+ only seems to be
able to push about 450fps out of glxgears with direct rendering, can't help
wondering if something is setup wrong, but as discussed here several times,
there are slowness issues with the PCI side of the radeon driver.

To Admin: Sorry, though I'm sure I did hit create mail (all email done in
windows atm), also I accidently sent from wrong account, but last time I
corrected by resending from the right one, I got flamed privately for double
posting. Guess I don't win either way.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Dieter Nützel
2004-02-05 19:19:40 UTC
Permalink
--
Dieter Nützel
@home: <Dieter.Nuetzel () hamburg ! de>


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
Dieter Nützel
2004-02-05 19:30:57 UTC
Permalink
Post by Roland Scheidegger
Post by Roland Scheidegger
The rendering errors are a harder problem though, I can see now why
the material between begin/end fallback was needed in the first place.
There doesn't seem to be an easy way currently to submit material
changes between vertices, so it looks like the fallback needs to stay
(even though it doesn't really seem to work correctly neither for some
reason).
Certainly the bug with the current code should be resolved - I can't
think it's too difficult - as the r100 will need it.
The r200 *can* do material changes inside begin/end - basically by using
the R200_LM1_SOURCE_VERTEX_COLOR_0..7 arrays to track the material
attributes and then wiring each of these up just like in the
glColorMaterial case.
I don't doubt the *chip* can do - I just doubt *I* can do it ;-).
Wouldn't it be necessary (and sufficient) just to update the two (front
and back) materials, or are you suggesting that it's necessary to send
the materials along with the other vertex parameters such as the
normals, colors etc.
But updating the current materials would mean that the vertices up to
now have to be flushed (?), since as far as I understand the driver it
doesn't allow vertex data to be mixed arbitrarily with other state
change commands. I'll admit though I don't understand it really...
I tried to implement something like that as a quick hack - it fixed the
errors, but looking a bit closer not for the reasons I thought it might
help. I just called _tnl_FlushVertices( ctx, ~0 ) at the end of
_tnl_Materialfv (t_vtx_api.c), but the strange thing is as far as I can
see this won't do anything if it's called inside a primitive.
Nevertheless, it fixed the rendering errors in specivewperf proe-02. Wierd.
Your GREAT patch let me run viewperf-6.1.2 DRV-07 for the FIRST time.
_All_ trials before hang the chip (even killing X remotely) lock the system
solid. But some broken (huge) triangles with right (?) colors.
Picture available.

Impressive speedup for all the other tests.
Wireframe could be faster (and was).

Advanced Visualizer (AWadvs-04) Viewset
-------------------------------------------------------------------------------
Test Weight Frames DList Visual Double Frame Buffer Accumulation
# % Per Sec Build ID Buffer R G B A Z Stencil R G B A
-------------------------------------------------------------------------------
1 21.00 86.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
2 21.00 97.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
3 14.00 89.60 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
4 14.00 86.10 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
5 6.00 97.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
6 5.00 90.20 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
7 5.00 96.10 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
8 4.00 102.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
9 4.00 107.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
10 3.00 102.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
11 3.00 107.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
--------------------------------------------------------------------------------
Weighted Geometric Mean = 92.746

Design Review (DRV-07) Viewset
-------------------------------------------------------------------------------
Test Weight Frames DList Visual Double Frame Buffer Accumulation
# % Per Sec Build ID Buffer R G B A Z Stencil R G B A
-------------------------------------------------------------------------------
1 75.00 6.60 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16
2 13.00 5.30 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16
3 4.00 6.60 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16
4 4.00 5.70 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16
5 4.00 4.10 0.000 0X29 True 8 8 8 8 24 0 16 16 16 16
--------------------------------------------------------------------------------
Weighted Geometric Mean = 6.256

Data Explorer (DX-06) Viewset
-------------------------------------------------------------------------------
Test Weight Frames DList Visual Double Frame Buffer Accumulation
# % Per Sec Build ID Buffer R G B A Z Stencil R G B A
-------------------------------------------------------------------------------
1 40.00 29.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
2 20.00 29.90 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
3 10.00 28.20 0.060 0X27 True 8 8 8 8 24 0 0 0 0 0
4 8.00 31.80 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
5 5.00 28.20 0.050 0X27 True 8 8 8 8 24 0 0 0 0 0
6 5.00 32.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
7 5.00 29.60 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
8 2.50 6.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
9 2.50 29.60 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
10 2.00 28.30 0.050 0X27 True 8 8 8 8 24 0 0 0 0 0
--------------------------------------------------------------------------------
Weighted Geometric Mean = 28.661

Lightscape (Light-04) Viewset
-------------------------------------------------------------------------------
Test Weight Frames DList Visual Double Frame Buffer Accumulation
# % Per Sec Build ID Buffer R G B A Z Stencil R G B A
-------------------------------------------------------------------------------
1 25.00 2.80 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
2 25.00 8.20 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
3 25.00 1.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
4 25.00 4.50 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
--------------------------------------------------------------------------------
Weighted Geometric Mean = 3.633

MedMCAD (MedMCAD-01) Viewset
-------------------------------------------------------------------------------
Test Weight Frames DList Visual Double Frame Buffer Accumulation
# % Per Sec Build ID Buffer R G B A Z Stencil R G B A
-------------------------------------------------------------------------------
1 10.00 24.10 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
2 10.00 24.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
3 10.00 19.80 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
4 10.00 19.70 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
5 7.50 8.40 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
6 7.50 8.40 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
7 7.50 7.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
8 7.50 7.00 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
9 7.50 6.60 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
10 7.50 6.60 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
11 7.50 8.40 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
12 7.50 8.40 0.000 0X27 True 8 8 8 8 24 0 0 0 0 0
--------------------------------------------------------------------------------
Weighted Geometric Mean = 11.559

Pro/Designer (ProCDRS-03) Viewset
-------------------------------------------------------------------------------
Test Weight Frames DList Visual Double Frame Buffer Accumulation
# % Per Sec Build ID Buffer R G B A Z Stencil R G B A
-------------------------------------------------------------------------------
1 25.00 21.80 0.040 0X27 True 8 8 8 8 24 0 0 0 0 0
2 25.00 21.90 0.040 0X27 True 8 8 8 8 24 0 0 0 0 0
3 10.00 6.80 0.070 0X27 True 8 8 8 8 24 0 0 0 0 0
4 10.00 8.30 0.060 0X27 True 8 8 8 8 24 0 0 0 0 0
5 5.00 5.70 0.090 0X27 True 8 8 8 8 24 0 0 0 0 0
6 5.00 7.00 0.090 0X27 True 8 8 8 8 24 0 0 0 0 0
7 3.00 3.70 0.070 0X27 True 8 8 8 8 24 0 0 0 0 0
8 3.00 4.50 0.060 0X27 True 8 8 8 8 24 0 0 0 0 0
9 7.00 12.30 0.110 0X27 True 8 8 8 8 24 0 0 0 0 0
10 7.00 12.50 0.100 0X27 True 8 8 8 8 24 0 0 0 0 0
--------------------------------------------------------------------------------
Weighted Geometric Mean = 13.024

Cheers,
Dieter


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--

Continue reading on narkive:
Loading...