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).
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.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
It should look correct with only the colormat fixed applied too.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.
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 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
