summaryrefslogtreecommitdiffstats
path: root/src/gallium/docs/source/cso
diff options
context:
space:
mode:
authorRoland Scheidegger <[email protected]>2014-01-09 16:55:22 +0100
committerRoland Scheidegger <[email protected]>2014-01-17 17:01:01 +0100
commit4b9bcf31f47c4530f22cbbaca73491d01e44a9d4 (patch)
treea2dc2322aeda46a7bfe58e863f3dbe540e524b63 /src/gallium/docs/source/cso
parent739dc95e676b31349525b7daf99453b987748248 (diff)
gallium: add bits for clipping points as tris (d3d-style)
OpenGL does whole-point clipping, that is a large point is either fully clipped or fully unclipped (the latter means it may extend beyond the viewport as long as the center is inside the viewport). d3d9 (d3d10 has no large points) however requires points to be clipped after they are expanded to a rectangle. (Note some IHVs are known to ignore GL rules at least with some hw/drivers.) Hence add a rasterizer bit indicating which way points should be clipped (some drivers probably will always ignore this), and add the draw interaction this requires. Drivers wanting to support this and using draw must support large points on their own as draw doesn't implement vp clipping on the expanded points (it potentially could but the complexity doesn't seem warranted), and the driver needs to do viewport scissoring on such points. Conflicts: src/gallium/drivers/llvmpipe/lp_context.c src/gallium/drivers/llvmpipe/lp_state_derived.c Reviewed-by: Jose Fonseca <[email protected]>
Diffstat (limited to 'src/gallium/docs/source/cso')
-rw-r--r--src/gallium/docs/source/cso/rasterizer.rst15
1 files changed, 11 insertions, 4 deletions
diff --git a/src/gallium/docs/source/cso/rasterizer.rst b/src/gallium/docs/source/cso/rasterizer.rst
index 44e5544cdaa..8d473b8446e 100644
--- a/src/gallium/docs/source/cso/rasterizer.rst
+++ b/src/gallium/docs/source/cso/rasterizer.rst
@@ -200,10 +200,11 @@ point_quad_rasterization
Determines if points should be rasterized according to quad or point
rasterization rules.
-OpenGL actually has quite different rasterization rules for points and
-point sprites - hence this indicates if points should be rasterized as
-points or according to point sprite (which decomposes them into quads,
-basically) rules.
+(Legacy-only) OpenGL actually has quite different rasterization rules
+for points and point sprites - hence this indicates if points should be
+rasterized as points or according to point sprite (which decomposes them
+into quads, basically) rules. Newer GL versions no longer support the old
+point rules at all.
Additionally Direct3D will always use quad rasterization rules for
points, regardless of whether point sprites are enabled or not.
@@ -217,6 +218,12 @@ generated.
Some renderers always internally translate points into quads; this state
still affects those renderers by overriding other rasterization state.
+point_tri_clip
+ Determines if clipping of points should happen after they are converted
+ to "rectangles" (required by d3d) or before (required by OpenGL, though
+ this rule is ignored by some IHVs).
+ It is not valid to set this to enabled but have point_quad_rasterization
+ disabled.
point_smooth
Whether points should be smoothed. Point smoothing turns rectangular
points into circles or ovals.