[Nouveau] [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses

Nirmoy nirmodas at amd.com
Wed Feb 19 12:47:15 UTC 2020 

On 2/18/20 8:06 PM, Daniel Vetter wrote:
> On Tue, Feb 18, 2020 at 07:37:44PM +0100, Christian König wrote:
>> Am 18.02.20 um 19:28 schrieb Thomas Zimmermann:
>>> Hi
>>>
>>> Am 18.02.20 um 19:23 schrieb Christian König:
>>>> Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
>>>>> Hi
>>>>>
>>>>> Am 18.02.20 um 18:13 schrieb Nirmoy:
>>>>>> On 2/18/20 1:44 PM, Christian König wrote:
>>>>>>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Am 17.02.20 um 16:04 schrieb Nirmoy Das:
>>>>>>>>> GPU address handling is device specific and should be handle by its
>>>>>>>>> device
>>>>>>>>> driver.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Nirmoy Das <nirmoy.das at amd.com>
>>>>>>>>> ---
>>>>>>>>>      drivers/gpu/drm/ttm/ttm_bo.c    | 7 -------
>>>>>>>>>      include/drm/ttm/ttm_bo_api.h    | 2 --
>>>>>>>>>      include/drm/ttm/ttm_bo_driver.h | 1 -
>>>>>>>>>      3 files changed, 10 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>>> index 151edfd8de77..d5885cd609a3 100644
>>>>>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>>>>>>>> @@ -85,7 +85,6 @@ static void ttm_mem_type_debug(struct
>>>>>>>>> ttm_bo_device *bdev, struct drm_printer *p
>>>>>>>>>          drm_printf(p, "    has_type: %d\n", man->has_type);
>>>>>>>>>          drm_printf(p, "    use_type: %d\n", man->use_type);
>>>>>>>>>          drm_printf(p, "    flags: 0x%08X\n", man->flags);
>>>>>>>>> -    drm_printf(p, "    gpu_offset: 0x%08llX\n", man->gpu_offset);
>>>>>>>>>          drm_printf(p, "    size: %llu\n", man->size);
>>>>>>>>>          drm_printf(p, "    available_caching: 0x%08X\n",
>>>>>>>>> man->available_caching);
>>>>>>>>>          drm_printf(p, "    default_caching: 0x%08X\n",
>>>>>>>>> man->default_caching);
>>>>>>>>> @@ -345,12 +344,6 @@ static int ttm_bo_handle_move_mem(struct
>>>>>>>>> ttm_buffer_object *bo,
>>>>>>>>>      moved:
>>>>>>>>>          bo->evicted = false;
>>>>>>>>>      -    if (bo->mem.mm_node)
>>>>>>>>> -        bo->offset = (bo->mem.start << PAGE_SHIFT) +
>>>>>>>>> -            bdev->man[bo->mem.mem_type].gpu_offset;
>>>>>>>>> -    else
>>>>>>>>> -        bo->offset = 0;
>>>>>>>>> -
>>>>>>>> After moving this into users, the else branch has been lost. Is
>>>>>>>> 'bo->mem.mm_node' always true?
>>>>>>> At least for the amdgpu and radeon use cases, yes.
>>>>>>>
>>>>>>> But that is a rather good question I mean for it is illegal to get the
>>>>>>> GPU BO address if it is inaccessible (e.g. in the system domain).
>>>>>>>
>>>>>>> Could be that some driver relied on the behavior to get 0 for the
>>>>>>> system domain here.
>>>>>> I wonder how to verify that ?
>>>>>>
>>>>>> If I understand correctly:
>>>>>>
>>>>>> 1 qxl uses bo->offset only in qxl_bo_physical_address() which is not in
>>>>>> system domain.
>>>>>>
>>>>>> 2 unfortunately I can't say the same for bochs but it works with this
>>>>>> patch series so I think bochs is fine as well.
>>>>>>
>>>>>> 3 vmwgfx uses bo->offset only when bo->mem.mem_type == TTM_PL_VRAM so
>>>>>> vmwgfx should be fine.
>>>>>>
>>>>>> 4 amdgpu and radeon runs with 'bo->mem.mm_node' always true
>>>>>>
>>>>>> I am not sure about  nouveau as bo->offset is being used in many places.
>>>>>>
>>>>>> I could probably mirror the removed logic to nouveau as
>>>>> I suggest to introduce a ttm helper that contains the original branching
>>>>> and use it everywhere. Something like
>>>>>
>>>>>      s64 ttm_bo_offset(struct ttm_buffer_object *bo)
>>>>>      {
>>>>>         if (WARN_ON_ONCE(!bo->mem.mm_node))
>>>>>             return 0;
>>>>>         return bo->mem.start << PAGE_SHIFT;
>>>>>      }
>>>>>
>>>>> Could be static inline. The warning should point to broken drivers. This
>>>>> also gets rid of the ugly shift in the drivers.
>>>> Big NAK on this. That is exactly what we should NOT do.
>>>>
>>>> See the shift belongs into the driver, because it is driver dependent if
>>>> we work with page or byte offsets.
>>>>
>>>> For amdgpu we for example want to work with byte offsets and TTM should
>>>> not make any assumption about what bo->mem.start actually contains.
>>> OK. What about something like ttm_bo_pg_offset()? Same code without the
>>> shift. Would also make it clear that it's a page offset.
>> That is a rather good idea. We could name that ttm_bo_man_offset() and put
>> it into ttm_bo_manager.c next to the manager which allocates them.
>>
>> It's just that this manager is not used by everybody, so amdgpu, radeon and
>> nouveau would still need a separate function.
> Let me pile on with my bikeshed color choice :-)
>
> I'd do this a wrapper, but for drivers individually. And only for those we
> haven't audited yet, or where we think the WARN_ON actually provides
> value. So maybe in vram helpers, since that might be used by some drivers
> that get stuff wrong. Or maybe noveau isn't audited yet.

I like this idea more. I will modify and resend patches with above 
suggestions.

> That also sidesteps the "what should we call this, drivers are different?"
> problem.
>
> Anyway feel free to ignore me, really just a bikeshed at this point.
>
> Cheers, Daniel
>
>> Christian.
>>
>>> Best regards
>>> Thomas
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Best regards
>>>>> Thomas
>>>>>
>>>>>
>>>>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>>>>>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>>>>>> index f8015e0318d7..5a6a2af91318 100644
>>>>>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>>>>>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>>>>>> @@ -1317,6 +1317,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object
>>>>>> *bo, bool evict,
>>>>>>                    list_for_each_entry(vma, &nvbo->vma_list, head) {
>>>>>>                            nouveau_vma_map(vma, mem);
>>>>>>                    }
>>>>>> +               if (bo->mem.mm_node)
>>>>>> +                       nvbo->offset = (new_reg->start << PAGE_SHIFT);
>>>>>> +               else
>>>>>> +                       nvbo->offset = 0;
>>>>>>            } else {
>>>>>>                    list_for_each_entry(vma, &nvbo->vma_list, head) {
>>>>>>                            WARN_ON(ttm_bo_wait(bo, false, false));
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Nirmoy
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Christian.
>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>>          ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
>>>>>>>>>          return 0;
>>>>>>>>>      diff --git a/include/drm/ttm/ttm_bo_api.h
>>>>>>>>> b/include/drm/ttm/ttm_bo_api.h
>>>>>>>>> index b9bc1b00142e..d6f39ee5bf5d 100644
>>>>>>>>> --- a/include/drm/ttm/ttm_bo_api.h
>>>>>>>>> +++ b/include/drm/ttm/ttm_bo_api.h
>>>>>>>>> @@ -213,8 +213,6 @@ struct ttm_buffer_object {
>>>>>>>>>           * either of these locks held.
>>>>>>>>>           */
>>>>>>>>>      -    uint64_t offset; /* GPU address space is independent of CPU
>>>>>>>>> word size */
>>>>>>>>> -
>>>>>>>>>          struct sg_table *sg;
>>>>>>>>>      };
>>>>>>>>>      diff --git a/include/drm/ttm/ttm_bo_driver.h
>>>>>>>>> b/include/drm/ttm/ttm_bo_driver.h
>>>>>>>>> index c9e0fd09f4b2..c8ce6c181abe 100644
>>>>>>>>> --- a/include/drm/ttm/ttm_bo_driver.h
>>>>>>>>> +++ b/include/drm/ttm/ttm_bo_driver.h
>>>>>>>>> @@ -177,7 +177,6 @@ struct ttm_mem_type_manager {
>>>>>>>>>          bool has_type;
>>>>>>>>>          bool use_type;
>>>>>>>>>          uint32_t flags;
>>>>>>>>> -    uint64_t gpu_offset; /* GPU address space is independent of CPU
>>>>>>>>> word size */
>>>>>>>>>          uint64_t size;
>>>>>>>>>          uint32_t available_caching;
>>>>>>>>>          uint32_t default_caching;
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> dri-devel mailing list
>>>>>> dri-devel at lists.freedesktop.org
>>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7CNirmoy.Das%40amd.com%7Cb0279de1528f44e16aa508d7b4a5b192%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637176496067660861&sdata=oDEilLoCymlcMxXJ2mnVWwTxqloQlW0SP3HDPmQRSVc%3D&reserved=0
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7CNirmoy.Das%40amd.com%7Cb0279de1528f44e16aa508d7b4a5b192%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637176496067660861&sdata=oDEilLoCymlcMxXJ2mnVWwTxqloQlW0SP3HDPmQRSVc%3D&reserved=0
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx at lists.freedesktop.org
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CNirmoy.Das%40amd.com%7Cb0279de1528f44e16aa508d7b4a5b192%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637176496067660861&sdata=XNDpZIj%2FwDbHOHBL25G%2FHpS9JETN%2F37H35E6t4q4joU%3D&reserved=0
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau at lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fnouveau&data=02%7C01%7CNirmoy.Das%40amd.com%7Cb0279de1528f44e16aa508d7b4a5b192%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637176496067660861&sdata=6ln5B81rbRdVEN6tRk8KMmIx04VPJw10dwZdqIYMkSo%3D&reserved=0
>

More information about the amd-gfx mailing list