[Mesa-dev] [PATCH v4] gallium: add API for setting window rectangles

Ilia Mirkin imirkin at alum.mit.edu
Fri Jun 17 16:11:36 UTC 2016


On Fri, Jun 17, 2016 at 12:02 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> FYI, in case you haven't heard: the corresponding hardware feature on Radeon
> allows four rectangles, and specifying an arbitrary logic function over
> them. That is, there are 2^4 = 16 bits specifying when fragments are
> discarded.
>
> If we wanted to expose that at some point, we'd have to uglify the interface
> somehow, but that's not really relevant at this point.

I think we would just modify the include boolean to be a bitmask? (Or
a bitset of sorts.)

Like you suggest, I think we can hold off on that until an extension
to expose it becomes available.

The current minimum for the ext is, unfortunately, 8 rectangles, but I
believe wheels are in motion to get that reduced to 4 so that AMD hw
may expose it as well.

>
> Reviewed-by: Nicolai Hähnle <nicolai.haehnle at amd.com>

Thanks!

>
>
> On 16.06.2016 02:24, Ilia Mirkin wrote:
>>
>> Window rectangles apply to all framebuffer operations, either in
>> inclusive or exclusive mode. They may also be specified as part of a
>> blit operation.
>>
>> In exclusive mode, any fragment inside any of the specified rectangles
>> will be discarded.
>>
>> In inclusive mode, any fragment outside every rectangle will be
>> discarded.
>>
>> The no-op state is to have 0 rectangles in exclusive mode.
>>
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>>
>> v3 -> v4:
>>    - make it clearer that clears aren't affected by window rectangles.
>>    - rename context call to ->set_window_rectangles
>>
>>   src/gallium/docs/source/context.rst  | 17 ++++++++++++++---
>>   src/gallium/include/pipe/p_context.h |  5 +++++
>>   src/gallium/include/pipe/p_state.h   |  6 ++++++
>>   3 files changed, 25 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/docs/source/context.rst
>> b/src/gallium/docs/source/context.rst
>> index 3a45f40..6f09c55 100644
>> --- a/src/gallium/docs/source/context.rst
>> +++ b/src/gallium/docs/source/context.rst
>> @@ -79,6 +79,17 @@ objects. They all follow simple, one-method binding
>> calls, e.g.
>>     should be the same as the number of set viewports and can be up to
>>     PIPE_MAX_VIEWPORTS.
>>   * ``set_viewport_states``
>> +* ``set_window_rectangles`` sets the window rectangles to be used for
>> +  rendering, as defined by GL_EXT_window_rectangles. There are two
>> +  modes - include and exclude, which define whether the supplied
>> +  rectangles are to be used for including fragments or excluding
>> +  them. All of the rectangles are ORed together, so in exclude mode,
>> +  any fragment inside any rectangle would be culled, while in include
>> +  mode, any fragment outside all rectangles would be culled. xmin/ymin
>> +  are inclusive, while xmax/ymax are exclusive (same as scissor states
>> +  above). Note that this only applies to draws, not clears or
>> +  blits. (Blits have their own way to pass the requisite rectangles
>> +  in.)
>>   * ``set_tess_state`` configures the default tessellation parameters:
>>     * ``default_outer_level`` is the default value for the outer
>> tessellation
>>       levels. This corresponds to GL's ``PATCH_DEFAULT_OUTER_LEVEL``.
>> @@ -492,9 +503,9 @@ This can be considered the equivalent of a CPU memcpy.
>>
>>   ``blit`` blits a region of a resource to a region of another resource,
>> including
>>   scaling, format conversion, and up-/downsampling, as well as a
>> destination clip
>> -rectangle (scissors). It can also optionally honor the current render
>> condition
>> -(but either way the blit itself never contributes anything to queries
>> currently
>> -gathering data).
>> +rectangle (scissors) and window rectangles. It can also optionally honor
>> the
>> +current render condition (but either way the blit itself never
>> contributes
>> +anything to queries currently gathering data).
>>   As opposed to manually drawing a textured quad, this lets the pipe
>> driver choose
>>   the optimal method for blitting (like using a special 2D engine), and
>> usually
>>   offers, for example, accelerated stencil-only copies even where
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index 9d7a8eb..6fde875 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -274,6 +274,11 @@ struct pipe_context {
>>                                  unsigned num_scissors,
>>                                  const struct pipe_scissor_state * );
>>
>> +   void (*set_window_rectangles)( struct pipe_context *,
>> +                                  boolean include,
>> +                                  unsigned num_rectangles,
>> +                                  const struct pipe_scissor_state * );
>> +
>>      void (*set_viewport_states)( struct pipe_context *,
>>                                   unsigned start_slot,
>>                                   unsigned num_viewports,
>> diff --git a/src/gallium/include/pipe/p_state.h
>> b/src/gallium/include/pipe/p_state.h
>> index 396f563..9c69355 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -69,6 +69,7 @@ extern "C" {
>>   #define PIPE_MAX_VIEWPORTS        16
>>   #define PIPE_MAX_CLIP_OR_CULL_DISTANCE_COUNT 8
>>   #define PIPE_MAX_CLIP_OR_CULL_DISTANCE_ELEMENT_COUNT 2
>> +#define PIPE_MAX_WINDOW_RECTANGLES 8
>>
>>
>>   struct pipe_reference
>> @@ -710,6 +711,11 @@ struct pipe_blit_info
>>      boolean scissor_enable;
>>      struct pipe_scissor_state scissor;
>>
>> +   /* Window rectangles can either be inclusive or exclusive. */
>> +   boolean window_rectangle_include;
>> +   unsigned num_window_rectangles;
>> +   struct pipe_scissor_state
>> window_rectangles[PIPE_MAX_WINDOW_RECTANGLES];
>> +
>>      boolean render_condition_enable; /**< whether the blit should honor
>> the
>>                                       current render condition */
>>      boolean alpha_blend; /* dst.rgb = src.rgb * src.a + dst.rgb * (1 -
>> src.a) */
>>
>


More information about the mesa-dev mailing list