[Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

Christian König deathsimple at vodafone.de
Mon Sep 12 13:30:31 UTC 2016


Am 12.09.2016 um 15:01 schrieb Marek Olšák:
> On Thu, Sep 8, 2016 at 10:30 PM, Rob Clark <robdclark at gmail.com> wrote:
>> Support multi-planar YUV for external EGLImage's (currently just in the
>> dma-buf import path) by lowering to multiple texture fetch's for each
>> plane and CSC in shader.
>>
>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>> ---
>>   src/gallium/auxiliary/util/u_inlines.h      |   4 +-
>>   src/gallium/include/pipe/p_state.h          |   9 +++
>>   src/gallium/include/state_tracker/st_api.h  |   3 +
>>   src/gallium/state_trackers/dri/dri2.c       | 119 +++++++++++++++++++++++-----
>>   src/gallium/state_trackers/dri/dri_screen.c |  11 +++
>>   src/mesa/main/mtypes.h                      |  16 ++++
>>   src/mesa/program/ir_to_mesa.cpp             |   1 +
>>   src/mesa/state_tracker/st_atom_sampler.c    |  41 +++++++++-
>>   src/mesa/state_tracker/st_atom_shader.c     |   3 +
>>   src/mesa/state_tracker/st_atom_texture.c    |  58 ++++++++++++++
>>   src/mesa/state_tracker/st_cb_eglimage.c     |  18 +++++
>>   src/mesa/state_tracker/st_context.c         |   7 +-
>>   src/mesa/state_tracker/st_glsl_to_nir.cpp   |   1 +
>>   src/mesa/state_tracker/st_glsl_to_tgsi.cpp  |   4 +
>>   src/mesa/state_tracker/st_manager.c         |   1 +
>>   src/mesa/state_tracker/st_program.c         |  35 ++++++++
>>   src/mesa/state_tracker/st_program.h         |  37 +++++++++
>>   src/mesa/state_tracker/st_texture.h         |  21 +++++
>>   18 files changed, 362 insertions(+), 27 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_inlines.h b/src/gallium/auxiliary/util/u_inlines.h
>> index c2a0b08..b7b8313 100644
>> --- a/src/gallium/auxiliary/util/u_inlines.h
>> +++ b/src/gallium/auxiliary/util/u_inlines.h
>> @@ -136,8 +136,10 @@ pipe_resource_reference(struct pipe_resource **ptr, struct pipe_resource *tex)
>>      struct pipe_resource *old_tex = *ptr;
>>
>>      if (pipe_reference_described(&(*ptr)->reference, &tex->reference,
>> -                                (debug_reference_descriptor)debug_describe_resource))
>> +                                (debug_reference_descriptor)debug_describe_resource)) {
>> +      pipe_resource_reference(&old_tex->next, NULL);
>>         old_tex->screen->resource_destroy(old_tex->screen, old_tex);
>> +   }
>>      *ptr = tex;
>>   }
>>
>> diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h
>> index ebd0337..4a88da6 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -498,6 +498,15 @@ struct pipe_resource
>>
>>      unsigned bind;            /**< bitmask of PIPE_BIND_x */
>>      unsigned flags;           /**< bitmask of PIPE_RESOURCE_FLAG_x */
>> +
>> +   /**
>> +    * For planar images, ie. YUV EGLImage external, etc, pointer to the
>> +    * next plane.
>> +    *
>> +    * TODO might be useful for dealing w/ z32s8 too, since at least a
>> +    * couple drivers split these out into separate buffers internally.
>> +    */
> Please remove this TODO. Radeon can't do separate depth & stencil.
> Yes, radeon allocates them separately, but they share the tiling mode
> and HyperZ metadata, which is interleaved.
>
>> +   struct pipe_resource *next;
> How about this:
> - pipe_resource::next will be removed.
> - all planes will be backed by the same pipe_resource
> - resource_from_handle will receive information about all planes.
> (whatever you need)
> - PIPE_FORMAT_XX_XX_XX_PLANAR will be added; replace XX with formats
> of planes (define as many formats as you need)
> - pipe_sampler_view::u::tex::first_layer will be used to select the plane.
> - the driver will look at first_layer and the format and will set up
> texture sampling from that plane
>
> What do you think?

That would finally also remove the need for separate video buffers.

I've didn't gone this way with the video stuff initially because it is 
(was?) a hell lot of work to get right in all drivers. But essentially 
it is the right thing to do.

Regards,
Christian.

>
> Marek
> _______________________________________________
> 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