Roland Scheidegger wrote:
Ronny V. Vindenes wrote:
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).
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
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 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
