[Mesa-dev] [PATCH 25/27] i965: Use partial resolves for CCS buffers being scanned out

[Ben Widawsky]

On 16-12-10 16:24:46, Pohjolainen, Topi wrote:
>On Thu, Dec 01, 2016 at 02:10:06PM -0800, Ben Widawsky wrote:
>> From: Ben Widawsky <ben at bwidawsk.net>
>>
>> On Gen9 hardware, the display engine is able to scanout a compressed
>> framebuffer by providing an offset to auxiliary compression information.
>> Unfortunately, the hardware is incapable of doing the same thing for the
>> fast clear color.
>>
>> To mitigate this, the hardware introduced a new resolve type called a
>> partial resolve. The partial resolve will only do a resolve of the fast
>> clear color and leave the rest of the compressed data alone.
>>
>> This patch enables using this resolve type for cases where the
>> framebuffer will be passed along to the kernel for display.
>>
>> Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
>> ---
>>  src/mesa/drivers/dri/i965/brw_context.c       | 3 ++-
>>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c
>> index cfd7a54..2bc2e94 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.c
>> +++ b/src/mesa/drivers/dri/i965/brw_context.c
>> @@ -1359,7 +1359,8 @@ intel_resolve_for_dri2_flush(struct brw_context *brw,
>>        if (rb->mt->num_samples <= 1) {
>>           assert(rb->mt_layer == 0 && rb->mt_level == 0 &&
>>                  rb->layer_count == 1);
>> -         intel_miptree_resolve_color(brw, rb->mt, 0, 0, 1, 0);
>
>I'm now in a territory that I don't know that well and just need to ask
>random questions. How do we know this is destined for display directly and not
>for non-gpu compositing?
>

I think that's always the case with intel_resolve_for_dri2_flush(). The current
callers are:
intel_flush_front() - from glFlush
and
intel_dri2_flush_with_flags - which is only called for drawables.

I wasn't entirely sure myself, but I assumed it was correct because it passed
all the CTS and piglit tests.

>> +         intel_miptree_resolve_color(brw, rb->mt, 0, 0, 1,
>> +                                     INTEL_RESOLVE_HINT_CLEAR_COLOR);
>>        } else {
>>           intel_renderbuffer_downsample(brw, rb);
>>        }
>> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> index dd71a06..b79de08 100644
>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> @@ -2399,8 +2399,8 @@ intel_miptree_make_shareable(struct brw_context *brw,
>>     assert(mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE || mt->num_samples <= 1);
>>
>>     if (mt->mcs_buf) {
>
>Shouldn't we here at least check for scanout?
>

Hmm. This probably makes sense.

How about:
-      intel_miptree_all_slices_resolve_color(brw, mt,
-                                             INTEL_RESOLVE_HINT_CLEAR_COLOR);
+      intel_miptree_all_slices_resolve_color(brw, mt, mt->is_scanout ?
+                                             INTEL_RESOLVE_HINT_CLEAR_COLOR :
+                                             INTEL_RESOLVE_HINT_FULL);

>> -      intel_miptree_all_slices_resolve_color(brw, mt, 0);
>> -      mt->no_ccs = true;
>> +      intel_miptree_all_slices_resolve_color(brw, mt,
>> +                                             INTEL_RESOLVE_HINT_CLEAR_COLOR);
>>     }
>>  }
>>
>> --
>> 2.10.2
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev