[Mesa-dev] [PATCH 09/19] radeonsi: add basic memory object support

Andres Rodriguez andresx7 at gmail.com
Tue Jul 4 16:39:04 UTC 2017



On 2017-07-04 09:30 AM, Christian König wrote:
> Am 04.07.2017 um 15:13 schrieb Nicolai Hähnle:
>> On 01.07.2017 01:03, Andres Rodriguez wrote:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> Signed-off-by: Andres Rodriguez <andresx7 at gmail.com>
>>> ---
>>>   src/gallium/drivers/radeon/r600_pipe_common.h |  6 ++
>>>   src/gallium/drivers/radeon/r600_texture.c     | 82 
>>> +++++++++++++++++++++++++++
>>>   2 files changed, 88 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
>>> b/src/gallium/drivers/radeon/r600_pipe_common.h
>>> index b22a3a7..c5734b4 100644
>>> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
>>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
>>> @@ -377,6 +377,12 @@ union r600_mmio_counters {
>>>       unsigned array[0];
>>>   };
>>>   +struct r600_memory_object {
>>> +    struct pb_buffer        *buf;
>>> +    uint32_t            stride;
>>> +    uint32_t            offset;
>>> +};
>>> +
>>>   struct r600_common_screen {
>>>       struct pipe_screen        b;
>>>       struct radeon_winsys        *ws;
>>> diff --git a/src/gallium/drivers/radeon/r600_texture.c 
>>> b/src/gallium/drivers/radeon/r600_texture.c
>>> index d68587b..3bc8b0c 100644
>>> --- a/src/gallium/drivers/radeon/r600_texture.c
>>> +++ b/src/gallium/drivers/radeon/r600_texture.c
>>> @@ -2784,10 +2784,92 @@ void evergreen_do_fast_color_clear(struct 
>>> r600_common_context *rctx,
>>>       }
>>>   }
>>>   +static struct pipe_memory_object *
>>> +r600_memobj_from_handle(struct pipe_screen *screen,
>>> +            struct winsys_handle *whandle)
>>> +{
>>> +    struct r600_common_screen *rscreen = (struct 
>>> r600_common_screen*)screen;
>>> +    struct r600_memory_object *memobj = 
>>> CALLOC_STRUCT(r600_memory_object);
>>> +    struct pb_buffer *buf = NULL;
>>> +    uint32_t stride, offset;
>>> +
>>> +    if (!memobj)
>>> +        return NULL;
>>> +
>>> +    buf = rscreen->ws->buffer_from_handle(rscreen->ws, whandle,
>>> +                          &stride, &offset);
>>> +    if (!buf)
>>> +        return NULL;
>>> +
>>> +    memobj->buf = buf;
>>> +    memobj->stride = stride;
>>> +    memobj->offset = offset;
>>> +
>>> +    return (struct pipe_memory_object *)memobj;
>>> +}
>>> +
>>> +static void
>>> +r600_memobj_destroy(struct pipe_screen *screen,
>>> +            struct pipe_memory_object *memobj)
>>> +{
>>> +    free(memobj);
>>> +}
>>> +
>>> +static struct pipe_resource *
>>> +r600_texture_from_memobj(struct pipe_screen *screen,
>>> +             const struct pipe_resource *templ,
>>> +             struct pipe_memory_object *_memobj,
>>> +             uint64_t offset)
>>> +{
>>> +    int r;
>>> +    struct r600_common_screen *rscreen = (struct 
>>> r600_common_screen*)screen;
>>> +    struct r600_memory_object *memobj = (struct r600_memory_object 
>>> *)_memobj;
>>> +    struct r600_texture *rtex;
>>> +    struct radeon_surf surface;
>>> +    struct radeon_bo_metadata metadata = {};
>>> +    unsigned array_mode;
>>> +    rscreen->ws->buffer_get_metadata(memobj->buf, &metadata);
>>> +
>>> +    surface.u.legacy.pipe_config = metadata.u.legacy.pipe_config;
>>> +    surface.u.legacy.bankw = metadata.u.legacy.bankw;
>>> +    surface.u.legacy.bankh = metadata.u.legacy.bankh;
>>> +    surface.u.legacy.tile_split = metadata.u.legacy.tile_split;
>>> +    surface.u.legacy.mtilea = metadata.u.legacy.mtilea;
>>> +    surface.u.legacy.num_banks = metadata.u.legacy.num_banks;
>>
>> How can this possibly work when multiple textures are in the same 
>> memory object?

Good point. This is taking advantage of NV_dedicated_allocation on the 
vulkan side, so the correspondence is one image per memory object. This 
codepath should really be wrapped in an "if (memObj->Dedicated)" check.

I'll check with Marek on the multi-texture metadata that Christian 
mentioned below.

Regards,
Andres

>>
>> As far as I understand the extension, we basically have to keep 
>> radeonsi and radv in sync in how they compute those parameters. Since 
>> it's only Vulkan -> OpenGL, this means we need to mirror precisely how 
>> radv calls addrlib here.
>>
>> Hmm. Keeping in mind that there's another Vulkan driver as well, is 
>> there any chance we can get a future extension where the exporting API 
>> provides an opaque blob of metadata and the importing API receives 
>> that blob? We'd use the same format that is currently used for the 
>> buffer metadata, but it'd work with multiple textures in the same memob >
> Didn't Marek explicitly designed the metadata so that multiple textures 
> can be in the same memory object?
>  > I didn't take a too close look at that, but from the ten miles high
> perspective it looked like that should work.
> 
> Regards,
> Christian.
> 
>>
>> Cheers,
>> Nicolai
>>
>>
>>> +
>>> +    if (metadata.u.legacy.macrotile == RADEON_LAYOUT_TILED)
>>> +        array_mode = RADEON_SURF_MODE_2D;
>>> +    else if (metadata.u.legacy.microtile == RADEON_LAYOUT_TILED)
>>> +        array_mode = RADEON_SURF_MODE_1D;
>>> +    else
>>> +        array_mode = RADEON_SURF_MODE_LINEAR_ALIGNED;
>>> +
>>> +    r = r600_init_surface(rscreen, &surface, templ,
>>> +                  array_mode, memobj->stride,
>>> +                  offset, true, metadata.u.legacy.scanout,
>>> +                  false, false);
>>> +    if (r)
>>> +        return NULL;
>>> +
>>> +    rtex = r600_texture_create_object(screen, templ, memobj->buf, 
>>> &surface);
>>> +    if (!rtex)
>>> +        return NULL;
>>> +
>>> +    rtex->resource.b.is_shared = true;
>>> +
>>> +    if (rscreen->apply_opaque_metadata)
>>> +        rscreen->apply_opaque_metadata(rscreen, rtex, &metadata);
>>> +
>>> +    return &rtex->resource.b.b;
>>> +}
>>> +
>>>   void r600_init_screen_texture_functions(struct r600_common_screen 
>>> *rscreen)
>>>   {
>>>       rscreen->b.resource_from_handle = r600_texture_from_handle;
>>>       rscreen->b.resource_get_handle = r600_texture_get_handle;
>>> +    rscreen->b.resource_from_memobj = r600_texture_from_memobj;
>>> +    rscreen->b.memobj_create_from_handle = r600_memobj_from_handle;
>>> +    rscreen->b.memobj_destroy = r600_memobj_destroy;
>>>   }
>>>     void r600_init_context_texture_functions(struct 
>>> r600_common_context *rctx)
>>>
>>
>>
> 


More information about the mesa-dev mailing list