Re: [Dri-devel] Re: Mach64 flatshading
On 17 Jul 2002, Michel Dänzer wrote: On Tue, 2002-07-16 at 20:17, Leif Delgass wrote: On Tue, 16 Jul 2002, Keith Whitwell wrote: Well, it's not high on my list. I don't think flat-shading is used that often, and the changes don't have any effect on smooth shading. Actually, it _eliminates_ some saves/restores necessary for unfilled polygons with hardware flat-shading. Actually, I think the problem is larger than mach64. Rage128 has the same problem and it appears to have GL compliant flat-shading based on the primitive. The problem is that for clipped polygons, the primitive type changes, so flat-shading breaks down in that case (like with unfilled polygons). I think the templates would have to be changed to copy the provoking-vertex color of the polygon being clipped into the vertices of the triangles generated by clipping, rather than interpolating the color. I'm surprised that this isn't working. Can you verify? I tested on the i810 at the time definitely got clipping working there... Here's a couple screenshots with the r128 driver (20020629 build): http://www.retinalburn.net/linux/r128-unclipped-flat.png http://www.retinalburn.net/linux/r128-clipped-flat.png Allen's test program is attached. Maybe someone could check this on Radeon with software tcl as well? Broken, as expected. As we've both been reporting for some time, software clipping is broken in the r128 and radeon drivers. I used to suspect a Mesa problem, but the mga driver works. I wish I knew what to look for about this problem... Actually, since mga uses DO_FLAT in the templates, the provoking-vertex color gets copied to all vertices. I think the problem is with interpolation and drivers that define DO_FLAT as zero. Keith said that i810 worked, but it _doesn't_ set DO_FLAT, which is the define that controls whether colors are copied. It sets HAVE_HW_FLATSHADE, but that just causes colors to be saved and restored when working with unfilled tris. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Re: Mach64 flatshading
On Wed, 17 Jul 2002, Leif Delgass wrote: On 17 Jul 2002, Michel Dänzer wrote: On Tue, 2002-07-16 at 20:17, Leif Delgass wrote: On Tue, 16 Jul 2002, Keith Whitwell wrote: Well, it's not high on my list. I don't think flat-shading is used that often, and the changes don't have any effect on smooth shading. Actually, it _eliminates_ some saves/restores necessary for unfilled polygons with hardware flat-shading. Actually, I think the problem is larger than mach64. Rage128 has the same problem and it appears to have GL compliant flat-shading based on the primitive. The problem is that for clipped polygons, the primitive type changes, so flat-shading breaks down in that case (like with unfilled polygons). I think the templates would have to be changed to copy the provoking-vertex color of the polygon being clipped into the vertices of the triangles generated by clipping, rather than interpolating the color. I'm surprised that this isn't working. Can you verify? I tested on the i810 at the time definitely got clipping working there... Here's a couple screenshots with the r128 driver (20020629 build): http://www.retinalburn.net/linux/r128-unclipped-flat.png http://www.retinalburn.net/linux/r128-clipped-flat.png Allen's test program is attached. Maybe someone could check this on Radeon with software tcl as well? Broken, as expected. As we've both been reporting for some time, software clipping is broken in the r128 and radeon drivers. I used to suspect a Mesa problem, but the mga driver works. I wish I knew what to look for about this problem... Actually, since mga uses DO_FLAT in the templates, the provoking-vertex color gets copied to all vertices. I think the problem is with interpolation and drivers that define DO_FLAT as zero. Keith said that i810 worked, but it _doesn't_ set DO_FLAT, which is the define that controls whether colors are copied. It sets HAVE_HW_FLATSHADE, but that just causes colors to be saved and restored when working with unfilled tris. Oops, I confused myself there. :) If i810 works with DO_FLAT defined as zero, that doesn't support this theory. Maybe there's some other differenece in the way it handles clipped polygons. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach64 flatshading
Michel Dänzer wrote: On Tue, 2002-07-16 at 20:17, Leif Delgass wrote: On Tue, 16 Jul 2002, Keith Whitwell wrote: Well, it's not high on my list. I don't think flat-shading is used that often, and the changes don't have any effect on smooth shading. Actually, it _eliminates_ some saves/restores necessary for unfilled polygons with hardware flat-shading. Actually, I think the problem is larger than mach64. Rage128 has the same problem and it appears to have GL compliant flat-shading based on the primitive. The problem is that for clipped polygons, the primitive type changes, so flat-shading breaks down in that case (like with unfilled polygons). I think the templates would have to be changed to copy the provoking-vertex color of the polygon being clipped into the vertices of the triangles generated by clipping, rather than interpolating the color. I'm surprised that this isn't working. Can you verify? I tested on the i810 at the time definitely got clipping working there... Here's a couple screenshots with the r128 driver (20020629 build): http://www.retinalburn.net/linux/r128-unclipped-flat.png http://www.retinalburn.net/linux/r128-clipped-flat.png Allen's test program is attached. Maybe someone could check this on Radeon with software tcl as well? Broken, as expected. As we've both been reporting for some time, software clipping is broken in the r128 and radeon drivers. I used to suspect a Mesa problem, but the mga driver works. I wish I knew what to look for about this problem... Sorry, I hadn't noticed the bug reports... I imagine the r200 is doing the same thing, so I can look into it today. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach64 flatshading
On 17 Jul 2002, Michel Dänzer wrote: On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote: I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon and r200. Great job! The clipping problems I originally reported with the xscreensaver gears hack and fsv are fixed. I've applied this fix to the mach64 FastRenderClippedPoly function and reverted my previous fix. I've tested the fix on r128 and it works there as well. It looks like it needs to be applied to all drivers with the FastRenderClippedPoly function, but I can't test any of the other drivers. There's another fix I made to the mach64 driver that I think needs to be applied to all drivers, and that's setting the read buffer equal to the draw buffer when switching draw buffers. This fixes software fallbacks when drawing on the front buffer. I've tested it on r128 and it works. Should I try my hand at combining these into a single patch for all the drivers? -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach64 flatshading
On Wed, 17 Jul 2002, Leif Delgass wrote:
On 17 Jul 2002, Michel Dänzer wrote:
On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
and r200.
Great job! The clipping problems I originally reported with the
xscreensaver gears hack and fsv are fixed.
I've applied this fix to the mach64 FastRenderClippedPoly function and
reverted my previous fix.
I've tested the fix on r128 and it works there as well. It looks like it
needs to be applied to all drivers with the FastRenderClippedPoly
function, but I can't test any of the other drivers.
There's another fix I made to the mach64 driver that I think needs to be
applied to all drivers, and that's setting the read buffer equal to the
draw buffer when switching draw buffers. This fixes software fallbacks
when drawing on the front buffer. I've tested it on r128 and it works.
Should I try my hand at combining these into a single patch for all the
drivers?
At any rate, the patch for r128 with the read buffer + flatshade fix is
attached. If nobody has any objections, I can commit this. Maybe someone
with access to other cards would like to try making the changes for other
drivers?
--
Leif Delgass
http://www.retinalburn.net
? r128-drawbuffer+flatshade.diff
Index: r128_state.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r128/r128_state.c,v
retrieving revision 1.22
diff -u -r1.22 r128_state.c
--- r128_state.c12 Jun 2002 15:50:25 - 1.22
+++ r128_state.c17 Jul 2002 19:27:03 -
-689,13 +689,13
switch ( mode ) {
case GL_FRONT_LEFT:
-rmesa-drawOffset = rmesa-r128Screen-frontOffset;
-rmesa-drawPitch = rmesa-r128Screen-frontPitch;
+rmesa-drawOffset = rmesa-readOffset = rmesa-r128Screen-frontOffset;
+rmesa-drawPitch = rmesa-readPitch = rmesa-r128Screen-frontPitch;
FALLBACK( rmesa, R128_FALLBACK_DRAW_BUFFER, GL_FALSE );
break;
case GL_BACK_LEFT:
-rmesa-drawOffset = rmesa-r128Screen-backOffset;
-rmesa-drawPitch = rmesa-r128Screen-backPitch;
+rmesa-drawOffset = rmesa-readOffset = rmesa-r128Screen-backOffset;
+rmesa-drawPitch = rmesa-readPitch = rmesa-r128Screen-backPitch;
FALLBACK( rmesa, R128_FALLBACK_DRAW_BUFFER, GL_FALSE );
break;
default:
Index: r128_tris.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r128/r128_tris.c,v
retrieving revision 1.17
diff -u -r1.17 r128_tris.c
--- r128_tris.c 2 Jun 2002 16:00:43 - 1.17
+++ r128_tris.c 17 Jul 2002 19:27:04 -
-501,9 +501,9
rmesa-num_verts += (n-2) * 3;
for (i = 2 ; i n ; i++) {
- COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) start );
COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) VERT(elts[i-1]) );
COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) VERT(elts[i]) );
+ COPY_DWORDS( j, vb, vertsize, (r128VertexPtr) start );
}
}
Re: [Dri-devel] Re: Mach64 flatshading
Leif Delgass wrote: On Wed, 17 Jul 2002, Leif Delgass wrote: On 17 Jul 2002, Michel Dänzer wrote: On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote: I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon and r200. Great job! The clipping problems I originally reported with the xscreensaver gears hack and fsv are fixed. I've applied this fix to the mach64 FastRenderClippedPoly function and reverted my previous fix. I've tested the fix on r128 and it works there as well. It looks like it needs to be applied to all drivers with the FastRenderClippedPoly function, but I can't test any of the other drivers. There's another fix I made to the mach64 driver that I think needs to be applied to all drivers, and that's setting the read buffer equal to the draw buffer when switching draw buffers. This fixes software fallbacks when drawing on the front buffer. I've tested it on r128 and it works. Should I try my hand at combining these into a single patch for all the drivers? At any rate, the patch for r128 with the read buffer + flatshade fix is attached. If nobody has any objections, I can commit this. Maybe someone with access to other cards would like to try making the changes for other drivers? I've done all the others. Lets see if testing was required... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach64 flatshading
On Wed, 17 Jul 2002, Keith Whitwell wrote: I've done all the others. Lets see if testing was required... So, should I commit the fix for r128? I've tested that and it works fine. Yes, go ahead. I took a look at the other drivers concerning the read buffer fix. It looks like mga, i810, and i830 already do this correctly. Reading from a separate read buffer doesn't seem to be implemented on tdfx and sis. It looks like ffb, gamma, r128, and radeon need the fix. The attached patch has fixes for all the drivers except sis (I included tdfx even though the ReadBuffer isn't used). I've tested the read buffer fix on mach64 and r128 with texenv (single-buffer mode), checking to see that textures done in software are correctly blended with the front buffer when the background is turned off (the checker-board should show through in the transparent areas). You'd have to force a fallback to test this on Radeon or other drivers without texture fallbacks. Sounds good - go ahead commit this to. OK, these are both committed. I've only tested the read buffer fix on r128, but I don't forsee any problems. For most drivers with few fallbacks, the problem probably went unnoticed anyway. Thanks for the clipping fix Keith, your one line beat my original 'fix' by a mile! -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
