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

Andres Rodriguez andresx7 at gmail.com
Thu Jul 6 21:51:36 UTC 2017



On 2017-07-04 12:39 PM, Andres Rodriguez wrote:
> 
> 
> 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 >

Hey Nicolai,

Didn't see you online on IRC and wanted to let you about a section of 
the VK_KHX_external_memory that rules out usage of external blobs.

See the answer to question 5 here (warning, giant spec website, not for 
browsers faint of heart):
https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_KHX_external_memory

Regards,
Andres

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