On 21/08/14 17:59, Roland Scheidegger wrote:
Am 21.08.2014 18:44, schrieb Marek Olšák:
From: Marek Olšák <marek.ol...@amd.com>
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst | 6 ++++++
src/gallium/drivers/r600/r600_pipe.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c | 1 +
src/gallium/include/pipe/p_defines.h | 4 +++-
7 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
b/src/gallium/auxiliary/tgsi/tgsi_strings.c
index 3c108a8..ddc23c1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
@@ -164,7 +164,8 @@ const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
"LINES_ADJACENCY",
"LINE_STRIP_ADJACENCY",
"TRIANGLES_ADJACENCY",
- "TRIANGLE_STRIP_ADJACENCY"
+ "TRIANGLE_STRIP_ADJACENCY",
+ "RECTANGLES"
};
const char *tgsi_fs_coord_origin_names[2] =
diff --git a/src/gallium/auxiliary/util/u_prim.h
b/src/gallium/auxiliary/util/u_prim.h
index cf1a18f..d631dc1 100644
--- a/src/gallium/auxiliary/util/u_prim.h
+++ b/src/gallium/auxiliary/util/u_prim.h
@@ -131,6 +131,7 @@ u_prim_vertex_count(unsigned prim)
{ 4, 1 }, /* PIPE_PRIM_LINE_STRIP_ADJACENCY */
{ 6, 6 }, /* PIPE_PRIM_TRIANGLES_ADJACENCY */
{ 6, 2 }, /* PIPE_PRIM_TRIANGLE_STRIP_ADJACENCY */
+ { 3, 3 } /* PIPE_PRIM_RECTANGLES */
};
return (likely(prim < PIPE_PRIM_MAX)) ? &prim_table[prim] : NULL;
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index eee254e..f162ec0 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -26,6 +26,12 @@ The integer capabilities:
normalized coordinates, and mipmaps.
* ``PIPE_CAP_TWO_SIDED_STENCIL``: Whether the stencil test can also affect
back-facing
polygons.
+* ``PIPE_CAP_PRIM_TYPE_RECTANGLES``: Whether rectangle primitives are
supported.
+ Rectangles are like quads, but they are only specified by the first 3
vertices.
+ The 4th vertex is computed from the first three by hardware. Rectangles must
+ be parallel with screen borders, which means they can only be rotated with
+ 90-degree increments. Rectangles bypass clipping and therefore can be
specified
+ in screen coordinates.
Do they also need to be planar (same z for each vertex)?
Also, the implicit bypass clip / screen coordinate specification makes
them quite an outlier among all the primitives. Hmm...
Yes, these restrictions would impose a lot of special casing if e.g.,
softpipe/llvmpipe wanted to support these. And rects are particularly
interesting for software rasterizers, as they can be rasterized much
more efficiently.
Does r600g/radeonsi's hardware support for rect impose these
restrictions? Or could rect be made work more like other primitives?
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
