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

Ben Widawsky ben at bwidawsk.net
Thu Jan 5 02:27:13 UTC 2017


On 17-01-04 10:29:45, Topi Pohjolainen Topi Pohjolainen wrote:
>On Mon, Jan 02, 2017 at 06:37:21PM -0800, Ben Widawsky wrote:
>> 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>
>> Acked-by: Daniel Stone <daniels at collabora.com>
>> ---
>>  src/mesa/drivers/dri/i965/brw_context.c       | 3 ++-
>>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 +++-
>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c
>> index ffcefe799d..538d7f4e43 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.c
>> +++ b/src/mesa/drivers/dri/i965/brw_context.c
>> @@ -1366,7 +1366,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);
>> +         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 7c2f623675..749d346386 100644
>> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> @@ -2416,7 +2416,9 @@ intel_miptree_make_shareable(struct brw_context *brw,
>>     assert(mt->msaa_layout == INTEL_MSAA_LAYOUT_NONE || mt->num_samples <= 1);
>>
>>     if (mt->mcs_buf) {
>> -      intel_miptree_all_slices_resolve_color(brw, mt, 0);
>> +      intel_miptree_all_slices_resolve_color(brw, mt, mt->is_scanout ?
>> +                                             INTEL_RESOLVE_HINT_CLEAR_COLOR :
>> +                                             INTEL_RESOLVE_HINT_FULL);
>
>In patch 24 I have discussion about the semantics of "is_scanout"? If it
>unconditionally means "compression-aware-client", then this patch is:
>
>Reviewed-by: Topi Pohjolainen <topi.pohjolainen at intel.com>
>

Well, this is a bit tricky. If there is an mcs_buf, and it's scanout, then it
was allocated with CCS AUX data in the BO. It should be safe to also add

if (mt->is_scanout)
    assert(mt->aux_offset).

I'll add your r-b for now.

>>        mt->aux_disable |= (INTEL_AUX_DISABLE_CCS | INTEL_AUX_DISABLE_MCS);
>>        drm_intel_bo_unreference(mt->mcs_buf->bo);
>>        free(mt->mcs_buf);
>> --
>> 2.11.0
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list