From: Thomas Zimmermann <tzimmermann-l3A5Bk7waGM@public.gmane.org>
To: Nirmoy <nirmodas-5C7GfCeVMHo@public.gmane.org>,
"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
"Nirmoy Das"
<nirmoy.aiemd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: thellstrom-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org,
airlied-cv59FeDIM0c@public.gmane.org,
kenny.ho-5C7GfCeVMHo@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
nirmoy.das-5C7GfCeVMHo@public.gmane.org,
linux-graphics-maintainer-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org,
bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
alexander.deucher-5C7GfCeVMHo@public.gmane.org,
sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org,
kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses
Date: Tue, 18 Feb 2020 19:16:08 +0100 [thread overview]
Message-ID: <5b8db944-5a55-8161-6ab6-98490cfb0562@suse.de> (raw)
In-Reply-To: <edc985f1-8856-4d1a-8960-efe4d21b960d-5C7GfCeVMHo@public.gmane.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 6014 bytes --]
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-5C7GfCeVMHo@public.gmane.org>
>>>> ---
>>>> 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.
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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 182 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Nirmoy <nirmodas@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Nirmoy Das" <nirmoy.aiemd@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: thellstrom@vmware.com, airlied@linux.ie, kenny.ho@amd.com,
amd-gfx@lists.freedesktop.org, nirmoy.das@amd.com,
linux-graphics-maintainer@vmware.com, bskeggs@redhat.com,
nouveau@lists.freedesktop.org, alexander.deucher@amd.com,
sean@poorly.run, kraxel@redhat.com
Subject: Re: [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses
Date: Tue, 18 Feb 2020 19:16:08 +0100 [thread overview]
Message-ID: <5b8db944-5a55-8161-6ab6-98490cfb0562@suse.de> (raw)
In-Reply-To: <edc985f1-8856-4d1a-8960-efe4d21b960d@amd.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5965 bytes --]
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@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.
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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Nirmoy <nirmodas@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Nirmoy Das" <nirmoy.aiemd@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: thellstrom@vmware.com, airlied@linux.ie, kenny.ho@amd.com,
amd-gfx@lists.freedesktop.org, nirmoy.das@amd.com,
linux-graphics-maintainer@vmware.com, bskeggs@redhat.com,
nouveau@lists.freedesktop.org, alexander.deucher@amd.com,
sean@poorly.run, kraxel@redhat.com
Subject: Re: [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses
Date: Tue, 18 Feb 2020 19:16:08 +0100 [thread overview]
Message-ID: <5b8db944-5a55-8161-6ab6-98490cfb0562@suse.de> (raw)
In-Reply-To: <edc985f1-8856-4d1a-8960-efe4d21b960d@amd.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5965 bytes --]
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@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.
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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2020-02-18 18:16 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 15:04 [PATCH 0/8] do not store GPU address in TTM Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-17 15:04 ` [PATCH 1/8] drm/amdgpu: move ttm bo->offset to amdgpu_bo Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-17 15:04 ` [PATCH 2/8] drm/radeon: don't use ttm bo->offset Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-17 15:04 ` [PATCH 3/8] drm/vmwgfx: " Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-17 15:04 ` [PATCH 4/8] drm/nouveau: " Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-17 15:57 ` Alex Deucher
2020-02-17 15:57 ` Alex Deucher
2020-02-17 16:04 ` Nirmoy
2020-02-17 16:04 ` Nirmoy
2020-02-17 15:04 ` [PATCH 5/8] drm/qxl: " Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-17 15:04 ` [PATCH 6/8] drm/vram-helper: " Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-24 8:01 ` Gerd Hoffmann
2020-02-24 8:01 ` Gerd Hoffmann
2020-02-24 9:52 ` Nirmoy
2020-02-17 15:04 ` [PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-17 15:06 ` Christian König
2020-02-17 15:06 ` Christian König
2020-02-24 8:01 ` Gerd Hoffmann
2020-02-24 8:01 ` Gerd Hoffmann
2020-02-17 15:04 ` [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses Nirmoy Das
2020-02-17 15:04 ` Nirmoy Das
2020-02-18 12:40 ` Thomas Zimmermann
2020-02-18 12:40 ` Thomas Zimmermann
2020-02-18 12:44 ` Christian König
2020-02-18 12:44 ` Christian König
[not found] ` <9db59846-90b4-2b9a-8200-69297112693a-5C7GfCeVMHo@public.gmane.org>
2020-02-18 17:13 ` Nirmoy
2020-02-18 17:13 ` Nirmoy
2020-02-18 17:13 ` Nirmoy
[not found] ` <edc985f1-8856-4d1a-8960-efe4d21b960d-5C7GfCeVMHo@public.gmane.org>
2020-02-18 17:23 ` Christian König
2020-02-18 17:23 ` Christian König
2020-02-18 17:23 ` Christian König
2020-02-18 18:16 ` Thomas Zimmermann [this message]
2020-02-18 18:16 ` Thomas Zimmermann
2020-02-18 18:16 ` Thomas Zimmermann
[not found] ` <5b8db944-5a55-8161-6ab6-98490cfb0562-l3A5Bk7waGM@public.gmane.org>
2020-02-18 18:23 ` Christian König
2020-02-18 18:23 ` Christian König
2020-02-18 18:23 ` Christian König
[not found] ` <f8534965-ea14-bbac-bd34-06b951766a7c-5C7GfCeVMHo@public.gmane.org>
2020-02-18 18:28 ` Thomas Zimmermann
2020-02-18 18:28 ` Thomas Zimmermann
2020-02-18 18:28 ` Thomas Zimmermann
[not found] ` <48a5e3e2-cb9d-8328-1529-3558601ba860-l3A5Bk7waGM@public.gmane.org>
2020-02-18 18:37 ` Christian König
2020-02-18 18:37 ` Christian König
2020-02-18 18:37 ` Christian König
[not found] ` <31b0cac7-82c7-60ad-830b-66f7838a1047-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-02-18 19:06 ` Daniel Vetter
2020-02-18 19:06 ` [Nouveau] " Daniel Vetter
2020-02-18 19:06 ` Daniel Vetter
[not found] ` <20200218190639.GM2363188-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2020-02-19 12:47 ` Nirmoy
2020-02-19 12:47 ` Nirmoy
2020-02-19 12:47 ` Nirmoy
2020-02-18 18:30 ` Nirmoy
2020-02-18 18:30 ` Nirmoy
2020-02-18 18:30 ` Nirmoy
2020-02-24 8:04 ` Gerd Hoffmann
2020-02-24 8:04 ` Gerd Hoffmann
2020-02-24 8:04 ` Gerd Hoffmann
2020-02-24 9:59 ` Nirmoy
2020-02-18 12:42 ` [PATCH 0/8] do not store GPU address in TTM Thomas Zimmermann
2020-02-18 12:42 ` Thomas Zimmermann
2020-02-18 15:57 ` Nirmoy
2020-02-18 15:57 ` Nirmoy
2020-02-19 13:53 [PATCH v3 " Nirmoy Das
2020-02-19 13:53 ` [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses Nirmoy Das
2020-02-19 13:53 ` Nirmoy Das
2020-03-05 13:29 [PATCH v4 0/8] do not store GPU address in TTM Nirmoy Das
2020-03-05 13:29 ` [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses Nirmoy Das
2020-03-05 13:29 ` Nirmoy Das
2020-03-05 13:34 ` Christian König
2020-03-05 13:34 ` Christian König
2020-04-01 18:42 [PATCH v5 0/8] do not store GPU address in TTM Nirmoy Das
2020-04-01 18:42 ` [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses Nirmoy Das
2020-06-24 18:26 [RESEND] [PATCH v6 0/8] do not store GPU address in TTM Nirmoy Das
2020-06-24 18:26 ` [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses Nirmoy Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b8db944-5a55-8161-6ab6-98490cfb0562@suse.de \
--to=tzimmermann-l3a5bk7wagm@public.gmane.org \
--cc=airlied-cv59FeDIM0c@public.gmane.org \
--cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=kenny.ho-5C7GfCeVMHo@public.gmane.org \
--cc=kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-graphics-maintainer-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org \
--cc=nirmodas-5C7GfCeVMHo@public.gmane.org \
--cc=nirmoy.aiemd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=nirmoy.das-5C7GfCeVMHo@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org \
--cc=thellstrom-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.