Re: Roland's point size patch. Was: Re: [Bug 702] Radeon only supports a maximum point size of 1.0.
Philipp Klaus Krause wrote: Roland found out how to do bigger aliased points on r200 hardware a long time ago. AFAIK the patch was never applied since people failed to see it's importance. 3D modellers use points to mark the currently selected vertices. A maximum point size of 1 means they are invisible with today's screen resolutions. This makes the r200 DRI driver useless for 3D modelling with those applications. Bigger point sizes are really necessary! Roland's patch supported only aliased points, but since the maximum point sizes for aliased and antialised points can be different that would never cause a software fallback. I know that the popular free wings3d modeller uses only aliased points and think that it's the same with other 3d modellers. Ok here's a patch. It needs a semi-recent drm. It is downright trivial, all points with size != 1.0 are simply rendered with the point sprite primitive. Up to size 2047.0 - that should be enough for everyone :-). No point parameters or point sprites for now. In fact it would be possible to do it without a new drm - since the hardware can clamp the point size. But I'm not too sure if it's a good idea to do the point size calculation with unconfigured inputs and then simply clamping the result. One thing which is slightly confusing though is the register name, R200_SE_TCL_POINT_SPRITE_CNTL seems to imply this only works when using hw tcl. Now I don't doubt the point attenuation calculation will only work when using hw tcl, but I can't see a reason why the selection bit would not work with sw tcl (and I'd hope the point sprite tex coord generation would work with sw tcl too, otherwise there'd be a big problem when for some other reason there's a tcl fallback - it's impossible to manually attach 4 sets of tex coords to a single vertex I guess). Works fine for me with tcl_mode=0, but I don't have hardware which doesn't have tcl hardware (only IGP 9100 family doesn't have tcl). If it doesn't work there we'd need to submit the point size as a vertex parameter (which has the nice side-effect of getting ARB_point_parameter for free for the sw tcl case). Roland Index: r200_cmdbuf.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_cmdbuf.c,v retrieving revision 1.17 diff -u -r1.17 r200_cmdbuf.c --- r200_cmdbuf.c 12 Sep 2005 21:20:10 - 1.17 +++ r200_cmdbuf.c 30 Sep 2005 22:55:49 - @@ -108,6 +108,7 @@ for (i = 0; i 6; ++i) insert_at_tail( rmesa-hw.atomlist, rmesa-hw.ucp[i] ); /* FIXME: is this a good place to insert that atom ? */ + insert_at_tail( rmesa-hw.atomlist, rmesa-hw.spr ); insert_at_tail( rmesa-hw.atomlist, rmesa-hw.prf ); } Index: r200_context.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.c,v retrieving revision 1.51 diff -u -r1.51 r200_context.c --- r200_context.c 12 Sep 2005 21:20:10 - 1.51 +++ r200_context.c 30 Sep 2005 22:55:49 - @@ -400,12 +400,19 @@ ctx-Const.MaxTextureMaxAnisotropy = 16.0; - /* No wide points. + /* No wide AA points. */ ctx-Const.MinPointSize = 1.0; ctx-Const.MinPointSizeAA = 1.0; - ctx-Const.MaxPointSize = 1.0; ctx-Const.MaxPointSizeAA = 1.0; + ctx-Const.PointSizeGranularity = 0.0625; + if (rmesa-r200Screen-drmSupportsPointSprites) + ctx-Const.MaxPointSize = 2047.0; + else + ctx-Const.MaxPointSize = 1.0; + + /* mesa initialization problem - _mesa_init_point was already called */ + ctx-Point.MaxSize = ctx-Const.MaxPointSize; ctx-Const.MinLineWidth = 1.0; ctx-Const.MinLineWidthAA = 1.0; Index: r200_context.h === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.h,v retrieving revision 1.33 diff -u -r1.33 r200_context.h --- r200_context.h 12 Sep 2005 21:20:10 - 1.33 +++ r200_context.h 30 Sep 2005 22:55:50 - @@ -397,6 +397,11 @@ #define VTX_STATE_CNTL 8 #define VTX_STATE_SIZE 9 +/* SPR - point sprite state + */ +#define SPR_CMD_0 0 +#define SPR_POINT_SPRITE_CNTL 1 +#define SPR_STATE_SIZE2 #define VTX_COLOR(v,n) (((v)(R200_VTX_COLOR_0_SHIFT+(n)*2))\ R200_VTX_COLOR_MASK) @@ -559,6 +564,7 @@ struct r200_state_atom prf; struct r200_state_atom afs[2]; struct r200_state_atom atf; + struct r200_state_atom spr; int max_state_size; /* Number of bytes necessary for a full state emit. */ GLboolean is_dirty, all_dirty; Index: r200_screen.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_screen.c,v retrieving revision 1.49 diff -u -r1.49 r200_screen.c --- r200_screen.c 12 Sep 2005 21:20:10 - 1.49 +++ r200_screen.c 30 Sep 2005 22:55:50 - @@
Roland's point size patch. Was: Re: [Bug 702] Radeon only supports a maximum point size of 1.0.
Roland found out how to do bigger aliased points on r200 hardware a long time ago. AFAIK the patch was never applied since people failed to see it's importance. 3D modellers use points to mark the currently selected vertices. A maximum point size of 1 means they are invisible with today's screen resolutions. This makes the r200 DRI driver useless for 3D modelling with those applications. Bigger point sizes are really necessary! Roland's patch supported only aliased points, but since the maximum point sizes for aliased and antialised points can be different that would never cause a software fallback. I know that the popular free wings3d modeller uses only aliased points and think that it's the same with other 3d modellers. Philipp --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Roland's point size patch. Was: Re: [Bug 702] Radeon only supports a maximum point size of 1.0.
Philipp Klaus Krause wrote: Roland found out how to do bigger aliased points on r200 hardware a long time ago. AFAIK the patch was never applied since people failed to see it's importance. 3D modellers use points to mark the currently selected vertices. A maximum point size of 1 means they are invisible with today's screen resolutions. This makes the r200 DRI driver useless for 3D modelling with those applications. Bigger point sizes are really necessary! Roland's patch supported only aliased points, but since the maximum point sizes for aliased and antialised points can be different that would never cause a software fallback. I know that the popular free wings3d modeller uses only aliased points and think that it's the same with other 3d modellers. I can apply a patch if you think it's useful. I just thought that antialiased is the norm for points rather than the exception, but if it's not it could indeed be useful. I think though for instance blender3d has now a workaround for cards which only support a point size of 1.0. The patch has also the obvious drawback that it won't work on r100 based cards, and people have been requesting large point sizes there too. btw there is still some chance I could get arb_point_parameters and arb_point_sprites working (on r200). Interestingly, arb_point_sprites is not announced by fglrx, nevertheless it actually works. Maybe it's not quite spec-conformant or has interactions with ATI_fragment_program, but at least the spriteblast demo worked fine - something I can't tell from my version which generates texcoords too, but they are apparently wrong. Same with point parameters, though I've gotten to a point which at least does some non-random attenuation calculation - the problem is there are still a dozen or so magic numbers in the vector state which I've just extracted with glxtest but fail to understand :-(. For anti-aliased point sizes, those must be kinda emulated. As far as I can tell, fglrx does this with textured point sprites and using the alpha blend stage to make the points round (fglrx fails to set it up correctly when alpha blending is not enabled, and I see no way to make this method work 100% depending on the user-supplied alpha test and alpha blend func), and xig does it by emitting a bunch of tri-fans (and gets it wrong too, when alpha blending is enabled you can see the individual half-transparent tris, though that's probably an easy to fix problem). Roland --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Roland's point size patch. Was: Re: [Bug 702] Radeon only supports a maximum point size of 1.0.
I can apply a patch if you think it's useful. I just thought that antialiased is the norm for points rather than the exception, but if it's not it could indeed be useful. Antialiased points probably are the norm for most applications (games, etc). 3d modellers seem to be an exception here. wings3d uses aliased points. Looking at some Maya plugin developer documentation indicates that Maya, too uses aliased points. Philipp --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
