[Mesa-dev] [PATCH 5/6] mesa: Implement a new GL_MESA_tile_raster_order extension.

[Eric Anholt]

Jason Ekstrand <jason at jlekstrand.net> writes:

> On Thu, Jul 27, 2017 at 7:30 PM, Eric Anholt <eric at anholt.net> wrote:
>
>> The intent is to use this extension on vc4 to allow X11 to do overlapping
>> CopyArea() within a pixmap without first blitting the pixmap to a
>> temporary.  With associated glamor patches, improves x11perf
>> -copywinwin100 performance on a Raspberry Pi 3 from ~4700/sec to
>> ~5130/sec, and is an even larger boost to uncomposited window movement
>> performance (most copywinwin100 copies don't overlap).
>> ---
>>  docs/specs/MESA_tile_raster_order.spec        | 101
>> ++++++++++++++++++++++++++
>>  docs/specs/enums.txt                          |   5 ++
>>  include/GL/glext.h                            |   6 ++
>>  src/mapi/glapi/gen/MESA_tile_raster_order.xml |  13 ++++
>>  src/mapi/glapi/gen/Makefile.am                |   1 +
>>  src/mesa/main/context.c                       |   2 +
>>  src/mesa/main/enable.c                        |  27 +++++++
>>  src/mesa/main/extensions_table.h              |   1 +
>>  src/mesa/main/mtypes.h                        |  13 ++++
>>  src/mesa/state_tracker/st_atom_rasterizer.c   |   5 ++
>>  src/mesa/state_tracker/st_context.c           |   1 +
>>  src/mesa/state_tracker/st_extensions.c        |   1 +
>>  12 files changed, 176 insertions(+)
>>  create mode 100644 docs/specs/MESA_tile_raster_order.spec
>>  create mode 100644 src/mapi/glapi/gen/MESA_tile_raster_order.xml
>>
>> diff --git a/docs/specs/MESA_tile_raster_order.spec
>> b/docs/specs/MESA_tile_raster_order.spec
>> new file mode 100644
>> index 000000000000..b6362fc7e5a6
>> --- /dev/null
>> +++ b/docs/specs/MESA_tile_raster_order.spec
>> @@ -0,0 +1,101 @@
>> +Name
>> +
>> +    MESA_tile_raster_order
>> +
>> +Name Strings
>> +
>> +    GL_MESA_tile_raster_order
>> +
>> +Contact
>> +
>> +    Eric Anholt, Broadcom (eric at anholt.net)
>> +
>> +Status
>> +
>> +    Proposal
>> +
>> +Version
>> +
>> +    Last modified date: 26 July 2017
>> +
>> +Number
>> +
>> +    TBD
>> +
>> +Dependencies
>> +
>> +    GL_ARB_texture_barrier is required
>> +
>> +Overview
>> +
>> +    This extension extends the sampling-from-the-framebuffer behavior
>> provided
>> +    by GL_ARB_texture_barrier to allow setting the rasterization order of
>> the
>> +    scene, so that overlapping blits can be implemented.  This can be
>> used for
>> +    scrolling or window movement within in 2D scenes, without first
>> copying to
>> +    a temporary.
>> +
>> +IP Status
>> +
>> +    None
>> +
>> +Issues
>> +
>> +    1.  Should this extension also affect BlitFramebuffer?
>> +
>> +        NOT RESOLVED: BlitFramebuffer could use the same underlying
>> +        functionality to provide defined results for 1:1 overlapping
>> blits,
>> +        but one could use the coordinates being copied to just produce the
>> +        right result automatically, rather than requiring the state flags
>> to
>> +        be adjusted.
>>
>
> I've been kicking this around in my brain a bit since you sent the
> extension, and I think we (Intel) may be able to implement a
> glBlitFramebuffer version.  The blitter hardware can do overlapping blits
> in a well-defined way and I think we could probably do something reasonably
> intelligent with blorp.  At the very least, blorp can probably do better
> than doing a dumb copy to a temporary.  You could do something like this:
>
> while (not_empty(dst_region)) {
>    blit(dst_region - src_region)
>    dst_region -= dst_region - src_region;
> }
>
> which might end you up doing one draw call per line in the worst case.
> However, with a little knowledge of caching, we may be able to do better
> than that even in the one pixel move case.  If we decided that was terrible
> performance, we could blit through a temporary but make sure it's small
> enough to always fit in cache.  Point being, that there's a number of
> different ways we can do things better than a dumb copy to temp.
>
> All that being said, we aren't nearly as memory constrained as you are so
> this isn't liable to be particularly high up on anyone's priority list so
> don't redesign the extension around us.

I've kept the BlitFramebuffer spec and implementation I wrote up around
in case it ends up being interesting.  It's not the best solution for
VC4, though it was really tempting, what with not having to add state to
the pipeline or tricky spec text :)

Actually, doing your incremental move using GL_ARB_texture_barrier might
be an interesting exercise for glamor for copyarea performance on Intel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170731/14590251/attachment-0001.sig>