From: Roland S. <rsc...@hi...> - 2004-01-31 02:26:09
Attachments:
r200_newlight.diff
|
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. |
From: Ronny V. V. <s8...@ii...> - 2004-01-31 19:18:40
|
On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote: > 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 <s8...@ii...> |
From: Roland S. <rsc...@hi...> - 2004-01-31 21:29:43
Attachments:
r200_newlight-2.diff
|
Ronny V. Vindenes wrote: > On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote: > >>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 |
From: Dieter <Die...@ha...> - 2004-01-31 21:46:44
|
Am Samstag, 31. Januar 2004 22:34 schrieb Roland Scheidegger: > Ronny V. Vindenes wrote: > > On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote: > >>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 |
From: Roland S. <rsc...@hi...> - 2004-02-01 01:39:47
|
Dieter N=FCtzel wrote: > Sorry Roland, NO go: >=20 > 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_colormatf= ix.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=20 replaces the code touched there anyway. >>>> (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=20 patching hell. The last patch should still work fine though I believe=20 (except that broken debug printf which you'll need to fix), it touches=20 completely different sections of the driver. Roland |
From: Dieter <Die...@ha...> - 2004-02-02 21:29:50
|
Am Samstag, 31. Januar 2004 22:34 schrieb Roland Scheidegger: > Ronny V. Vindenes wrote: > > On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote: > >>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) : Rob...@so... www.inria.fr/caiman/personnel/Robert.Riviere/vtk/sphere-bench.html - Sebastien Barre (script) : Seb...@ut... 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 |
From: Michel <mi...@da...> - 2004-02-02 21:48:22
|
On Sat, 2004-01-31 at 22:34, Roland Scheidegger wrote: > > > >>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 |
From: Alan H. <al...@fa...> - 2004-02-02 22:08:14
|
On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel D=E4nzer wrote: > About keeping track of your patches: I wonder what others think about > giving you write access? Go for it. Alan. |
From: Michel <mi...@da...> - 2004-02-02 22:10:02
|
On Mon, 2004-02-02 at 23:08, Alan Hourihane wrote: > On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel Dänzer wrote: > > 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 |
From: Alan H. <al...@fa...> - 2004-02-02 22:11:45
|
On Mon, Feb 02, 2004 at 11:09:57PM +0100, Michel D=E4nzer wrote: > On Mon, 2004-02-02 at 23:08, Alan Hourihane wrote: > > On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel D=E4nzer wrote: > > > About keeping track of your patches: I wonder what others think abo= ut > > > giving you write access? > >=20 > > Go for it. >=20 > 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. |
From: Michel <mi...@da...> - 2004-02-02 22:39:40
|
On Mon, 2004-02-02 at 23:11, Alan Hourihane wrote: > On Mon, Feb 02, 2004 at 11:09:57PM +0100, Michel Dänzer wrote: > > On Mon, 2004-02-02 at 23:08, Alan Hourihane wrote: > > > On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel Dänzer wrote: > > > > 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 |
From: Keith W. <ke...@tu...> - 2004-02-03 11:32:00
|
Michel Dänzer wrote: > On Mon, 2004-02-02 at 23:11, Alan Hourihane wrote: > >>On Mon, Feb 02, 2004 at 11:09:57PM +0100, Michel Dänzer wrote: >> >>>On Mon, 2004-02-02 at 23:08, Alan Hourihane wrote: >>> >>>>On Mon, Feb 02, 2004 at 10:48:15PM +0100, Michel Dänzer wrote: >>>> >>>>>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 |
From: Dave A. <ai...@sk...> - 2004-02-02 22:33:47
|
> > 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. > > 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 > Dri...@li... > 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 |
From: Keith W. <ke...@tu...> - 2004-01-31 20:12:40
|
Roland Scheidegger wrote: > 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. > 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... Another hangover from the r100, which can't handle this at all. The r200 should do just fine. > 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 |
From: Dieter <Die...@ha...> - 2004-01-31 21:40:43
|
Am Samstag, 31. Januar 2004 03:30 schrieb 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. |
From: Ronny V. V. <s8...@ii...> - 2004-02-01 13:40:21
|
On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote: > 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? 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 <s8...@ii...> |
From: Roland S. <rsc...@hi...> - 2004-02-02 21:13:04
|
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 #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 > 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 |
From: Keith W. <ke...@tu...> - 2004-02-03 09:01:16
|
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 |
From: Roland S. <rsc...@hi...> - 2004-02-03 12:58:21
|
Keith Whitwell wrote: > 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 |
From: Keith W. <ke...@tu...> - 2004-02-04 06:42:14
|
Roland Scheidegger wrote: > Keith Whitwell wrote: > >> 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). 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 |
From: Roland S. <rsc...@hi...> - 2004-02-03 22:47:49
|
Keith Whitwell wrote: >> 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 |
From: Chris I. <ci...@bi...> - 2004-02-03 21:50:27
|
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. |
From: Michel <mi...@da...> - 2004-02-04 11:45:20
|
On Tue, 2004-02-03 at 21:30, Chris Ison wrote: > 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 |
From: Dave A. <ai...@cs...> - 2004-02-04 11:57:17
|
> 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 |
From: Chris I. <wil...@us...> - 2004-02-04 12:53:33
|
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. |