[Mesa-dev] [RFC] gallium: add support for rectangle primitives

Marek Olšák maraeo at gmail.com
Thu Aug 21 10:33:30 PDT 2014


On Thu, Aug 21, 2014 at 7:14 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 21/08/14 17:59, Roland Scheidegger wrote:
>>
>> Am 21.08.2014 18:44, schrieb Marek Olšák:
>>>
>>> From: Marek Olšák <marek.olsak at 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?

The restrictions I described in screen.rst are based on r600/radeonsi
restrictions.

I'm not sure if rectangles need to be planar, but let's assume they do.

Marek


More information about the mesa-dev mailing list