From: Roland S. <rsc...@hi...> - 2004-04-06 17:55:08
|
Felix K=FChling wrote: > On Mon, 05 Apr 2004 14:50:45 -0700 > Ian Romanick <id...@us...> wrote: >=20 >=20 >>Paul Heldens wrote: >> >> >>>I found on the list that this has always been broken in dri because of= a >>>hardware issue.(?) >>> >>>Example of affected apps; gtkradiant, blender,maya(hearsay) >>> >>>Questions: >>> >>>Is there any other way for an enduser to get around the inability of >>>drawing gl points larger than 1x1 pixel? perhaps a Mesa setting of >>>somekind? >> >>The bug is in the application. There is a query for an application to=20 >>determine the maximum point size, and the R200 driver returns 1.0. The= =20 >>driver cannot be held accountable for apps that don't follow the rules. >=20 >=20 > I can't test it right now, but IIRC the radeon drivers even limit the > size of antialiased points to 1. This seems to be compliant with the > specs, but wouldn't it be nicer to draw antialiased points as software > fallbacks and not limit their size (beyond the mesa limits, if there ar= e > any), if the hardware doesn't support point antialiasing? Even nicer would be if it would just be implemented in the driver. I'm=20 not sure what the hardware actually can do or not, but apparently the=20 r200/rv250 even accept a vertex format which includes the vertex point=20 size as a parameter. And both ATI's and XIG's driver support larger=20 point sizes. It's possible they "emulate" it with point sprites (which=20 the hardware also supports natively), I've no idea. I've tried enabling=20 other point sizes (just as others) without success, since the point size=20 register doesn't seem to have any effect on normal GL_POINT primitives.=20 The gpu supports quite a few primitives which are not supported in the=20 driver, though without documentation it's hard to tell what exactly they=20 are good for... Roland |