On Thu, Jul 17, 2003 at 08:03:47AM -0500, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
As you state, the trouble with this patch is that all rasterization falls back to software when poinsize != 1, even if no points are actually rendered.
To get good behaviour you really need to do something a little different.
First, yes, you will want a rasterization fallback for points. That means at least you have to turn of HW TCL when (pointsize != 1), otherwise you won't find it so easy to catch points with the existing infrastructure. (We could try & get fancy, but let's keep it simpler).
Then, have a look at radeonChooseRenderState() in radeon_swtcl.c. In here you will need to figure out how to hook in a software rasterization fallback *only* for points. This isn't something the radeon driver currently does, but other drivers *do*. Take a look at the equivalent function in the mga driver -- mgaChooseRenderState() -- which does hook in per-primitive-type fallbacks.
Shouldn't it be possible to simulate large (or small) points by replacing them with a polygon? There would be some trickery involved to get it right, but I'd thing that on TCL hardware this would be a much better way to go. Could this be done by adding another pipeline stage? I've kind of permanently kept this issue on my back-burner, but it seems to be heating up lately. :) Maybe it's time to stir the pot...
Yep, in fact emitting a polygon in this fallback is probably a better idea (and easier) than trying to go to software rendering. In fact all the old drivers do it this way -- emit two triangles in the point routine.
Keith
Attached is another point size patch. Thanks for taking the time to look through my first patch. This one uses per-primitive fallbacks as you suggested.
I originally had radeon_point_fallback calling swrast but this caused a lot of rendering glitches (I'm fairly certain the Z-buffer format was responsible). Currently I'm altering the reduced_hw_prim and hw_prim values and emitting two triangles when the fallback is in effect.
So far it seems to be a big improvement from the original hack but it's still a
work in progress.
Dylan
Dylan,
The patch is starting to look pretty good. Probably the glitches you saw were because there was no synchronization between swrast & hardware rasterization. You'd need to call radeonSpanRenderStart() and radeonSpanRenderFinish() before & after groups of points. (Hopefully not before/after each individual point, but that would work too).
Index: xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c
===================================================================
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c,v
retrieving revision 1.19
diff -u -r1.19 radeon_swtcl.c
--- xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c 10 Jun 2003 18:50:46 -0000 1.19
+++ xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c 19 Jul 2003 14:26:14 -0000
@@ -531,7 +531,7 @@
#define HAVE_POLYGONS 0
#define HAVE_ELTS 1
-static const GLuint hw_prim[GL_POLYGON+1] = {
+static GLuint hw_prim[GL_POLYGON+1] = {
RADEON_CP_VC_CNTL_PRIM_TYPE_POINT,
RADEON_CP_VC_CNTL_PRIM_TYPE_LINE,
0,
@@ -701,7 +701,7 @@
return GL_TRUE; /* too many vertices */
}
- for (i = 0 ; !(flags & PRIM_LAST) ; i += length)
+ for (i = VB->FirstPrimitive ; !(flags & PRIM_LAST) ; i += length)
{
flags = VB->Primitive[i];
length = VB->PrimitiveLength[i];
Is this something you see as a general bug, or is it somehow related to your patch?
Keith
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
