From: Michel <mi...@da...> - 2002-11-28 12:10:31
|
On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote:=20 >=20 > TaskParallelismWithPorts > The colors of the polyhedron in the middle are missing. > With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. > Some small screenshots could be find in the archive. Sounds like a problem I'm seeing with the amoeba demo, some faces of a spinning cube (with the observer inside) are missing. RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before the Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was already the case before the merge. These aren't the only reasons to check out amoeba, some parts of it are pushing quite hard performance wise, and it's simply fun to watch. :) I can't reproduce your other problems (they seem to be x86 assembler specific?), but I do see some problems with the Mesa demos (though it seems they were already there before the merge): fire: the fog seems to be much too dense around the initial direction, everything is almost white gloss: artifacts with the initial highlight, goes away with SW TCL, seems to be the same problem as the ice in tuxracer pointblast: the points are always pixel sized I wonder if any of these are PPC specific. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Keith W. <ke...@tu...> - 2002-11-28 12:31:17
|
Michel D=E4nzer wrote: > On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote:=20 >=20 >>TaskParallelismWithPorts >>The colors of the polyhedron in the middle are missing. >>With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. >>Some small screenshots could be find in the archive. >=20 >=20 > Sounds like a problem I'm seeing with the amoeba demo, some faces of a > spinning cube (with the observer inside) are missing. > RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before th= e > Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was > already the case before the merge. >=20 > These aren't the only reasons to check out amoeba, some parts of it are > pushing quite hard performance wise, and it's simply fun to watch. :) >=20 >=20 > I can't reproduce your other problems (they seem to be x86 assembler > specific?), but I do see some problems with the Mesa demos (though it > seems they were already there before the merge): >=20 > fire: the fog seems to be much too dense around the initial direction, > everything is almost white This is normal for per vertex fog. The ground plane is too big for the l= inear=20 interpolation of fog coordinates across the polygon to give good looking=20 results. > gloss: artifacts with the initial highlight, goes away with SW TCL, > seems to be the same problem as the ice in tuxracer This is a result of slight differences between geometry generated by soft= ware=20 t&l and hardware t&l. The gloss cylendar is drawn in two passes, and the= =20 crawling you see is a result of differences between the passes. Some work could be done tweaking the vertices (z values?) emitted by swtc= l to=20 get a closer alignemnt. Otherwise, this isn't strictly a bug. GL doesn't require invarience at t= his=20 level. > pointblast: the points are always pixel sized Again, GL allows us to specify a maximum point size. For the radeon, tha= ts=20 set to 1.0 pixels as that's the largest size that the radeon can draw=20 conformantly without sw fallbacks. Keith |
From: Michel <mi...@da...> - 2002-11-28 14:47:33
|
First of all, thanks Keith for sharing your insights ( and Jens for the URL about locking ). On Don, 2002-11-28 at 13:31, Keith Whitwell wrote: >=20 > > gloss: artifacts with the initial highlight, goes away with SW TCL, > > seems to be the same problem as the ice in tuxracer >=20 > This is a result of slight differences between geometry generated by soft= ware=20 > t&l and hardware t&l. The gloss cylendar is drawn in two passes, and the= =20 > crawling you see is a result of differences between the passes. >=20 > Some work could be done tweaking the vertices (z values?) emitted by swtc= l to=20 > get a closer alignemnt. >=20 > Otherwise, this isn't strictly a bug. GL doesn't require invarience at t= his=20 > level. I see. Do you have an idea on how to go about tweaking the vertices? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Keith W. <ke...@tu...> - 2002-11-28 14:59:24
|
Michel D=E4nzer wrote: > First of all, thanks Keith for sharing your insights ( and Jens for the > URL about locking ). >=20 >=20 > On Don, 2002-11-28 at 13:31, Keith Whitwell wrote: >=20 >>>gloss: artifacts with the initial highlight, goes away with SW TCL, >>>seems to be the same problem as the ice in tuxracer >> >>This is a result of slight differences between geometry generated by so= ftware=20 >>t&l and hardware t&l. The gloss cylendar is drawn in two passes, and t= he=20 >>crawling you see is a result of differences between the passes. >> >>Some work could be done tweaking the vertices (z values?) emitted by sw= tcl to=20 >>get a closer alignemnt. >> >>Otherwise, this isn't strictly a bug. GL doesn't require invarience at= this=20 >>level. >=20 >=20 > I see. Do you have an idea on how to go about tweaking the vertices? There are a bunch of ways - tweak the zscale and zoffset viewport parameters but *ONLY* when hardw= are=20 tcl is disabled (probably the best option?) - turn off _radeon_render_stage, and tweak the vertices as they are emit= ted=20 in radeon_draw_triangle() and radeon_draw_quad(). These functions are n= ow=20 generated ty t_dd_triemit.c, so you'll have to dig a little. (might be th= e=20 easiest for debugging). - Modify the vertices as they are generated by t_dd_vbtmp.h. There is=20 facility in there for an additional viewport transformation, for instance. Keith =09 |
From: Brian P. <br...@tu...> - 2002-11-28 15:22:33
|
Michel D=E4nzer wrote: > First of all, thanks Keith for sharing your insights ( and Jens for the > URL about locking ). >=20 >=20 > On Don, 2002-11-28 at 13:31, Keith Whitwell wrote: >=20 >>>gloss: artifacts with the initial highlight, goes away with SW TCL, >>>seems to be the same problem as the ice in tuxracer >> >>This is a result of slight differences between geometry generated by so= ftware=20 >>t&l and hardware t&l. The gloss cylendar is drawn in two passes, and t= he=20 >>crawling you see is a result of differences between the passes. >> >>Some work could be done tweaking the vertices (z values?) emitted by sw= tcl to=20 >>get a closer alignemnt. >> >>Otherwise, this isn't strictly a bug. GL doesn't require invarience at= this=20 >>level. >=20 >=20 > I see. Do you have an idea on how to go about tweaking the vertices? I think this might be a red herring. Firstly, I doubt we'd ever get the = h/w and s/w vertices to be identical in all situations. Secondly, any OpenGL implementation may display this artifact. I've personally seen this prob= lem using a card which did both passes fully in hardware. The real answer is to use a polygon offset in the gloss demo. I'll look into fixing this. If tuxracer is drawing coplaner geometry with substantialy different state, it should also be using polygon offset. -Brian |
From: Keith W. <ke...@tu...> - 2002-11-28 15:38:38
|
Brian Paul wrote: > Michel D=E4nzer wrote: >=20 >> First of all, thanks Keith for sharing your insights ( and Jens for th= e >> URL about locking ). >> >> >> On Don, 2002-11-28 at 13:31, Keith Whitwell wrote: >> >>>> gloss: artifacts with the initial highlight, goes away with SW TCL, >>>> seems to be the same problem as the ice in tuxracer >>> >>> >>> This is a result of slight differences between geometry generated by=20 >>> software t&l and hardware t&l. The gloss cylendar is drawn in two=20 >>> passes, and the crawling you see is a result of differences between=20 >>> the passes. >>> >>> Some work could be done tweaking the vertices (z values?) emitted by=20 >>> swtcl to get a closer alignemnt. >>> >>> Otherwise, this isn't strictly a bug. GL doesn't require invarience=20 >>> at this level. >> >> >> >> I see. Do you have an idea on how to go about tweaking the vertices? >=20 >=20 > I think this might be a red herring. Firstly, I doubt we'd ever get th= e=20 > h/w > and s/w vertices to be identical in all situations. Secondly, any Open= GL > implementation may display this artifact. I've personally seen this=20 > problem > using a card which did both passes fully in hardware. >=20 > The real answer is to use a polygon offset in the gloss demo. I'll loo= k > into fixing this. >=20 > If tuxracer is drawing coplaner geometry with substantialy different > state, it should also be using polygon offset. It is. However I wouldn't mind bringing things as close together as possible. I= t may=20 be easier than we think. The three things I would investigate are: - small positive and negative offsets to Z - stripping out least significant bits from Z (this might be a requireme= nt of=20 the spec, in fact), by addding and then subtracting a large number to for= ce=20 the little bits off the end. - floating point Z buffers (more work). Keith |
From: Brian P. <br...@tu...> - 2002-11-28 15:46:17
|
Michel D=E4nzer wrote: > On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote:=20 >=20 >>TaskParallelismWithPorts >>The colors of the polyhedron in the middle are missing. >>With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. >>Some small screenshots could be find in the archive. >=20 >=20 > Sounds like a problem I'm seeing with the amoeba demo, some faces of a > spinning cube (with the observer inside) are missing. > RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before th= e > Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was > already the case before the merge. Perhaps you can look at the diffs from before and after the merge to find the problem. Using the "Browse CVS" option on the website, this is pretty easy. I did a spot check of some of the radeon sources but didn't find anything wrong. > These aren't the only reasons to check out amoeba, some parts of it are > pushing quite hard performance wise, and it's simply fun to watch. :) >=20 >=20 > I can't reproduce your other problems (they seem to be x86 assembler > specific?), but I do see some problems with the Mesa demos (though it > seems they were already there before the merge): >=20 > fire: the fog seems to be much too dense around the initial direction, > everything is almost white >=20 > gloss: artifacts with the initial highlight, goes away with SW TCL, > seems to be the same problem as the ice in tuxracer >=20 > pointblast: the points are always pixel sized The radeon and r200 drivers don't support the GL_ARB/EXT_point_parameters extension and the max point size is 1 pixel. -Brian |
From: Dieter <Die...@ha...> - 2002-11-28 22:19:25
|
Am Donnerstag, 28. November 2002 13:10 schrieb Michel D=E4nzer: > On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote: > > TaskParallelismWithPorts > > The colors of the polyhedron in the middle are missing. > > With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. > > Some small screenshots could be find in the archive. > > Sounds like a problem I'm seeing with the amoeba demo, some faces of a > spinning cube (with the observer inside) are missing. > RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before the > Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was > already the case before the merge. > > These aren't the only reasons to check out amoeba, some parts of it are > pushing quite hard performance wise, and it's simply fun to watch. :) Pointers? I'll have a "look", too ;-) > I can't reproduce your other problems (they seem to be x86 assembler > specific?), but I do see some problems with the Mesa demos (though it > seems they were already there before the merge): Yes, I reported some "floating exception" to Brian after MesaCVS 5.1 come u= p. Same stuff (stex3d for example) worked OK with 4.0.4 and 5.0. Plane old gcc-2.95.3. Even -mcup=3Dk6 (no athlon, mmx, 3dnow!). Don't tell me to use GCC-3.2.1/3.3.x and disable MMX/3DNow!. All the hard work on this gave very nice results before. Even better than S= SE=20 on Athlon/Duron. So we need the (kernel) asm experts, here? Something like (s)fence etc? I'll see if I get some asm for comparison. Mesa/demos> ./cubemap MMX cpu detected. 3DNow! cpu detected. Testing OS support for SSE... yes. Testing OS support for SSE unmasked exceptions... SIGFPE, yes. Tests of OS support for SSE passed. SSE cpu detected. GL_RENDERER: Mesa X11 GL_REFLECTION_MAP_ARB mode keys: SPACE - toggle animation CURSOR KEYS - rotation m - toggle texgen reflection mode z/Z - change viewing distance Floating exception (core dumped) (gdb) bt #0 0x400f8bbb in _mesa_sse_transform_points3_general () from=20 /opt/Mesa/lib/libGL.so.1 #1 0x081dc040 in ?? () #2 0x4025be56 in init_vertex_stage () from /opt/Mesa/lib/libGL.so.1 #3 0x402145eb in _tnl_run_pipeline () from /opt/Mesa/lib/libGL.so.1 #4 0x40212bed in _tnl_run_cassette () from /opt/Mesa/lib/libGL.so.1 #5 0x40212c58 in exec_vert_cassette () from /opt/Mesa/lib/libGL.so.1 #6 0x40212e1a in _tnl_execute_cassette () from /opt/Mesa/lib/libGL.so.1 #7 0x40208f07 in _tnl_flush_immediate () from /opt/Mesa/lib/libGL.so.1 #8 0x40208f95 in _tnl_flush_vertices () from /opt/Mesa/lib/libGL.so.1 #9 0x4016c7ab in _mesa_PopMatrix () from /opt/Mesa/lib/libGL.so.1 #10 0x08049c8e in draw () #11 0x400292da in processWindowWorkList () from /opt/Mesa/lib/libglut.so.3 #12 0x40029374 in __glutProcessWindowWorkLists () from=20 /opt/Mesa/lib/libglut.so.3 #13 0x400293dc in glutMainLoop () from /opt/Mesa/lib/libglut.so.3 #14 0x0804a7b0 in main () #15 0x403227d1 in __libc_start_main () from /lib/libc.so.6 =20 Cheers, Dieter |
From: Michel <mi...@da...> - 2002-11-28 23:02:51
|
On Don, 2002-11-28 at 23:19, Dieter N=FCtzel wrote: > Am Donnerstag, 28. November 2002 13:10 schrieb Michel D=E4nzer: > > > > These aren't the only reasons to check out amoeba, some parts of it are > > pushing quite hard performance wise, and it's simply fun to watch. :) >=20 > Pointers? I'll have a "look", too ;-) apt-get install amoeba :) or http://www.scene.org/file.php?file=3D/parties/2002/underscore02/demo/e_amoe= ba-final.zip --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Dieter <Die...@ha...> - 2002-11-28 23:10:52
|
Am Freitag, 29. November 2002 00:02 schrieb Michel D=E4nzer: > On Don, 2002-11-28 at 23:19, Dieter N=FCtzel wrote: > > Am Donnerstag, 28. November 2002 13:10 schrieb Michel D=E4nzer: > > > These aren't the only reasons to check out amoeba, some parts of it a= re > > > pushing quite hard performance wise, and it's simply fun to watch. :) > > > > Pointers? I'll have a "look", too ;-) > > apt-get install amoeba :) I'm not a "debianer"...;-) > > http://www.scene.org/file.php?file=3D/parties/2002/underscore02/demo/e_am= oeba >-final.zip Thanks! =2DDieter |
From: Dieter <Die...@ha...> - 2002-11-28 22:34:11
|
Am Donnerstag, 28. November 2002 13:10 schrieb Michel D=E4nzer: > On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote: > > TaskParallelismWithPorts > > The colors of the polyhedron in the middle are missing. > > With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. > > Some small screenshots could be find in the archive. [-] > fire: the fog seems to be much too dense around the initial direction, > everything is almost white trunk on 2.4.19-ck (1.6.0 radeon module) Directory: /opt/Mesa/demos Mesa/demos> ./fire =46ire V1.5 Written by David Bucciarelli (tec...@pl...) drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) > gloss: artifacts with the initial highlight, goes away with SW TCL, > seems to be the same problem as the ice in tuxracer Mesa/demos> ./gloss drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) [drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed [drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed [drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed =2DDieter |
From: Michel <mi...@da...> - 2002-11-29 10:31:46
|
On Don, 2002-11-28 at 16:51, Brian Paul wrote: > Michel D=E4nzer wrote: > > On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote:=20 > >=20 > >>TaskParallelismWithPorts > >>The colors of the polyhedron in the middle are missing. > >>With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. > >>Some small screenshots could be find in the archive. > >=20 > >=20 > > Sounds like a problem I'm seeing with the amoeba demo, some faces of a > > spinning cube (with the observer inside) are missing. > > RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before th= e > > Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was > > already the case before the merge. >=20 > Perhaps you can look at the diffs from before and after the merge > to find the problem. Using the "Browse CVS" option on the website, > this is pretty easy. I think cvs diff is easier. :) > I did a spot check of some of the radeon sources but didn't find > anything wrong. Me neither, unsurprisingly. Could it be caused by a Mesa change? I'm even more lost there... --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Brian P. <br...@tu...> - 2002-11-29 15:21:55
|
Michel D=E4nzer wrote: > On Don, 2002-11-28 at 16:51, Brian Paul wrote: >=20 >>Michel D=E4nzer wrote: >> >>>On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote:=20 >>> >>> >>>>TaskParallelismWithPorts >>>>The colors of the polyhedron in the middle are missing. >>>>With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. >>>>Some small screenshots could be find in the archive. >>> >>> >>>Sounds like a problem I'm seeing with the amoeba demo, some faces of a >>>spinning cube (with the observer inside) are missing. >>>RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before t= he >>>Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was >>>already the case before the merge. >> >>Perhaps you can look at the diffs from before and after the merge >>to find the problem. Using the "Browse CVS" option on the website, >>this is pretty easy. >=20 >=20 > I think cvs diff is easier. :) >=20 >=20 >>I did a spot check of some of the radeon sources but didn't find >>anything wrong. >=20 >=20 > Me neither, unsurprisingly. Could it be caused by a Mesa change? I'm > even more lost there... But if it works correctly with RADEON_TCL_FORCE_DISABLE that indicates that the Mesa code is correct. -Brian |
From: Michel <mi...@da...> - 2002-11-30 16:22:21
|
On Fre, 2002-11-29 at 16:27, Brian Paul wrote:=20 > Michel D=E4nzer wrote: > > On Don, 2002-11-28 at 16:51, Brian Paul wrote: > >=20 > >>Michel D=E4nzer wrote: > >>> > >>>Sounds like a problem I'm seeing with the amoeba demo, some faces of a > >>>spinning cube (with the observer inside) are missing. > >>>RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before t= he > >>>Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was > >>>already the case before the merge. [...] > >>I did a spot check of some of the radeon sources but didn't find > >>anything wrong. > >=20 > >=20 > > Me neither, unsurprisingly. Could it be caused by a Mesa change? I'm > > even more lost there... >=20 > But if it works correctly with RADEON_TCL_FORCE_DISABLE that indicates > that the Mesa code is correct. Are exactly the same code paths exercised in both cases? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Dieter <Die...@ha...> - 2002-11-29 18:02:19
|
Am Freitag, 29. November 2002 16:27 schrieb Brian Paul: > Michel D=E4nzer wrote: > > On Don, 2002-11-28 at 16:51, Brian Paul wrote: > >>Michel D=E4nzer wrote: > >>>On Mit, 2002-11-27 at 08:32, Dieter N=FCtzel wrote: > >>>>TaskParallelismWithPorts > >>>>The colors of the polyhedron in the middle are missing. > >>>>With LIBGL_ALWAYS_INDIRECT or R200_NO_TCL they are fine. > >>>>Some small screenshots could be find in the archive. > >>> > >>>Sounds like a problem I'm seeing with the amoeba demo, some faces of a > >>>spinning cube (with the observer inside) are missing. > >>>RADEON_TCL_FORCE_DISABLE=3D1 fixes it, which wasn't necessary before t= he > >>>Mesa 5.0 merge. Also, it hangs near the end with HW TCL, but this was > >>>already the case before the merge. > >> > >>Perhaps you can look at the diffs from before and after the merge > >>to find the problem. Using the "Browse CVS" option on the website, > >>this is pretty easy. > > > > I think cvs diff is easier. :) > > > >>I did a spot check of some of the radeon sources but didn't find > >>anything wrong. > > > > Me neither, unsurprisingly. Could it be caused by a Mesa change? I'm > > even more lost there... > > But if it works correctly with RADEON_TCL_FORCE_DISABLE that indicates > that the Mesa code is correct. How is it called for the r200? RADEON_TCL_FORCE_DISABLE / R200_TCL_FORCE_DISABLE both didn't work. =2DDieter |
From: Felix <fx...@gm...> - 2002-11-29 18:38:58
|
On Fri, 29 Nov 2002 19:02:14 +0100 Dieter Nützel <Die...@ha...> wrote: > > But if it works correctly with RADEON_TCL_FORCE_DISABLE that indicates > > that the Mesa code is correct. > > How is it called for the r200? > RADEON_TCL_FORCE_DISABLE / R200_TCL_FORCE_DISABLE both didn't work. R200_NO_TCL. There is a complete list of environment variables on http://dri.sourceforge.net/doc/feature_table.html. Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Dieter <Die...@ha...> - 2002-11-29 23:03:31
|
Am Freitag, 29. November 2002 19:38 schrieb Felix K=FChling: > On Fri, 29 Nov 2002 19:02:14 +0100 > > Dieter N=FCtzel <Die...@ha...> wrote: > > > But if it works correctly with RADEON_TCL_FORCE_DISABLE that indicates > > > that the Mesa code is correct. > > > > How is it called for the r200? > > RADEON_TCL_FORCE_DISABLE / R200_TCL_FORCE_DISABLE both didn't work. > > R200_NO_TCL. There is a complete list of environment variables on > http://dri.sourceforge.net/doc/feature_table.html. I know, but thought there is a new "magic" one ;-) =2DDieter |