* [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers
@ 2019-03-08 15:38 Nicholas Kazlauskas
[not found] ` <20190308153816.7978-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Nicholas Kazlauskas @ 2019-03-08 15:38 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Nicholas Kazlauskas
The dumb_create API isn't intended for high performance rendering
and it's more useful for userspace (ie. IGT) to have them precleared.
The bonus here is that we also won't needlessly leak whatever was
previously in VRAM, but it also probably wasn't sensitive if it was
going through this API.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fcaaac30e84b..a58072bbc9b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -743,7 +743,8 @@ int amdgpu_mode_dumb_create(struct drm_file *file_priv,
domain = amdgpu_bo_get_preferred_pin_domain(adev,
amdgpu_display_supported_domains(adev));
r = amdgpu_gem_object_create(adev, args->size, 0, domain,
- AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED,
+ AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED |
+ AMDGPU_GEM_CREATE_VRAM_CLEARED,
ttm_bo_type_device, NULL, &gobj);
if (r)
return -ENOMEM;
--
2.17.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related [flat|nested] 7+ messages in thread[parent not found: <20190308153816.7978-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>]
* Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers [not found] ` <20190308153816.7978-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org> @ 2019-03-08 16:47 ` Alex Deucher [not found] ` <CADnq5_PxyfDKVLgQ9iBqEsSGX-jYMbr-RsxrvM5j=0N7AF-w5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Alex Deucher @ 2019-03-08 16:47 UTC (permalink / raw) To: Nicholas Kazlauskas; +Cc: amd-gfx list On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> wrote: > > The dumb_create API isn't intended for high performance rendering > and it's more useful for userspace (ie. IGT) to have them precleared. > > The bonus here is that we also won't needlessly leak whatever was > previously in VRAM, but it also probably wasn't sensitive if it was > going through this API. > > Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > index fcaaac30e84b..a58072bbc9b8 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c > @@ -743,7 +743,8 @@ int amdgpu_mode_dumb_create(struct drm_file *file_priv, > domain = amdgpu_bo_get_preferred_pin_domain(adev, > amdgpu_display_supported_domains(adev)); > r = amdgpu_gem_object_create(adev, args->size, 0, domain, > - AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED, > + AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED | > + AMDGPU_GEM_CREATE_VRAM_CLEARED, > ttm_bo_type_device, NULL, &gobj); > if (r) > return -ENOMEM; > -- > 2.17.1 > > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CADnq5_PxyfDKVLgQ9iBqEsSGX-jYMbr-RsxrvM5j=0N7AF-w5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers [not found] ` <CADnq5_PxyfDKVLgQ9iBqEsSGX-jYMbr-RsxrvM5j=0N7AF-w5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2019-03-11 16:58 ` Christian König [not found] ` <73f25762-0277-7e12-dfff-a016d245478c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Christian König @ 2019-03-11 16:58 UTC (permalink / raw) To: Alex Deucher, Nicholas Kazlauskas; +Cc: amd-gfx list Am 08.03.19 um 17:47 schrieb Alex Deucher: > On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas > <nicholas.kazlauskas@amd.com> wrote: >> The dumb_create API isn't intended for high performance rendering >> and it's more useful for userspace (ie. IGT) to have them precleared. >> >> The bonus here is that we also won't needlessly leak whatever was >> previously in VRAM, but it also probably wasn't sensitive if it was >> going through this API. >> >> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> > Reviewed-by: Alex Deucher <alexander.deucher@amd.com> NAK, IIRC we used to have this bit here before. In general I agree that this would be a good idea, but the problem is the that first dump buffer is sometimes created before the engine (usually SDMA) to clear VRAM is initialized. So you can run into a nice crash on suspend/resume. Christian. > >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >> index fcaaac30e84b..a58072bbc9b8 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >> @@ -743,7 +743,8 @@ int amdgpu_mode_dumb_create(struct drm_file *file_priv, >> domain = amdgpu_bo_get_preferred_pin_domain(adev, >> amdgpu_display_supported_domains(adev)); >> r = amdgpu_gem_object_create(adev, args->size, 0, domain, >> - AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED, >> + AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED | >> + AMDGPU_GEM_CREATE_VRAM_CLEARED, >> ttm_bo_type_device, NULL, &gobj); >> if (r) >> return -ENOMEM; >> -- >> 2.17.1 >> >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <73f25762-0277-7e12-dfff-a016d245478c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers [not found] ` <73f25762-0277-7e12-dfff-a016d245478c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2019-03-11 17:04 ` Kazlauskas, Nicholas [not found] ` <a5aa3caf-253e-8832-c63e-77269d4e865f-5C7GfCeVMHo@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Kazlauskas, Nicholas @ 2019-03-11 17:04 UTC (permalink / raw) To: Koenig, Christian, Alex Deucher; +Cc: amd-gfx list On 3/11/19 12:58 PM, Christian König wrote: > Am 08.03.19 um 17:47 schrieb Alex Deucher: >> On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas >> <nicholas.kazlauskas@amd.com> wrote: >>> The dumb_create API isn't intended for high performance rendering >>> and it's more useful for userspace (ie. IGT) to have them precleared. >>> >>> The bonus here is that we also won't needlessly leak whatever was >>> previously in VRAM, but it also probably wasn't sensitive if it was >>> going through this API. >>> >>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> > > NAK, IIRC we used to have this bit here before. > > In general I agree that this would be a good idea, but the problem is > the that first dump buffer is sometimes created before the engine > (usually SDMA) to clear VRAM is initialized. > > So you can run into a nice crash on suspend/resume. > > Christian. FWIW I never hit it myself during any suspend/resume tests I did but I'll take your word for it. How about doing a map/memset/unmap immediately after buffer creation here? It'd be much slower, but it's also what we'd be doing in userspace anyway. Nicholas Kazlauskas > >> >>> --- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>> index fcaaac30e84b..a58072bbc9b8 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>> @@ -743,7 +743,8 @@ int amdgpu_mode_dumb_create(struct drm_file >>> *file_priv, >>> domain = amdgpu_bo_get_preferred_pin_domain(adev, >>> >>> amdgpu_display_supported_domains(adev)); >>> r = amdgpu_gem_object_create(adev, args->size, 0, domain, >>> - >>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED, >>> + >>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED | >>> + AMDGPU_GEM_CREATE_VRAM_CLEARED, >>> ttm_bo_type_device, NULL, &gobj); >>> if (r) >>> return -ENOMEM; >>> -- >>> 2.17.1 >>> >>> _______________________________________________ >>> amd-gfx mailing list >>> amd-gfx@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <a5aa3caf-253e-8832-c63e-77269d4e865f-5C7GfCeVMHo@public.gmane.org>]
* Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers [not found] ` <a5aa3caf-253e-8832-c63e-77269d4e865f-5C7GfCeVMHo@public.gmane.org> @ 2019-03-11 17:31 ` Koenig, Christian [not found] ` <e021eacf-8200-fe28-6aad-0bfbcb27798c-5C7GfCeVMHo@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Koenig, Christian @ 2019-03-11 17:31 UTC (permalink / raw) To: Kazlauskas, Nicholas, Alex Deucher; +Cc: amd-gfx list Am 11.03.19 um 18:04 schrieb Kazlauskas, Nicholas: > On 3/11/19 12:58 PM, Christian König wrote: >> Am 08.03.19 um 17:47 schrieb Alex Deucher: >>> On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas >>> <nicholas.kazlauskas@amd.com> wrote: >>>> The dumb_create API isn't intended for high performance rendering >>>> and it's more useful for userspace (ie. IGT) to have them precleared. >>>> >>>> The bonus here is that we also won't needlessly leak whatever was >>>> previously in VRAM, but it also probably wasn't sensitive if it was >>>> going through this API. >>>> >>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> >> NAK, IIRC we used to have this bit here before. >> >> In general I agree that this would be a good idea, but the problem is >> the that first dump buffer is sometimes created before the engine >> (usually SDMA) to clear VRAM is initialized. >> >> So you can run into a nice crash on suspend/resume. >> >> Christian. > FWIW I never hit it myself during any suspend/resume tests I did but > I'll take your word for it. > > How about doing a map/memset/unmap immediately after buffer creation > here? It'd be much slower, but it's also what we'd be doing in userspace > anyway. And history repeat itself :) Yeah, that was also suggested before and didn't worked either for some reason. But that was ~2 years ago and I really don't remember the details. What could work is maybe to add a check if the engine is available if the flag is given and ignore it when it isn't. Christian. > > Nicholas Kazlauskas > > >>>> --- >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>> index fcaaac30e84b..a58072bbc9b8 100644 >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>> @@ -743,7 +743,8 @@ int amdgpu_mode_dumb_create(struct drm_file >>>> *file_priv, >>>> domain = amdgpu_bo_get_preferred_pin_domain(adev, >>>> >>>> amdgpu_display_supported_domains(adev)); >>>> r = amdgpu_gem_object_create(adev, args->size, 0, domain, >>>> - >>>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED, >>>> + >>>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED | >>>> + AMDGPU_GEM_CREATE_VRAM_CLEARED, >>>> ttm_bo_type_device, NULL, &gobj); >>>> if (r) >>>> return -ENOMEM; >>>> -- >>>> 2.17.1 >>>> >>>> _______________________________________________ >>>> amd-gfx mailing list >>>> amd-gfx@lists.freedesktop.org >>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >>> _______________________________________________ >>> amd-gfx mailing list >>> amd-gfx@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <e021eacf-8200-fe28-6aad-0bfbcb27798c-5C7GfCeVMHo@public.gmane.org>]
* Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers [not found] ` <e021eacf-8200-fe28-6aad-0bfbcb27798c-5C7GfCeVMHo@public.gmane.org> @ 2019-03-11 17:53 ` Kazlauskas, Nicholas [not found] ` <7e271708-34ad-db55-54ca-eaccd954eff6-5C7GfCeVMHo@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Kazlauskas, Nicholas @ 2019-03-11 17:53 UTC (permalink / raw) To: Koenig, Christian, Alex Deucher; +Cc: amd-gfx list On 3/11/19 1:31 PM, Koenig, Christian wrote: > Am 11.03.19 um 18:04 schrieb Kazlauskas, Nicholas: >> On 3/11/19 12:58 PM, Christian König wrote: >>> Am 08.03.19 um 17:47 schrieb Alex Deucher: >>>> On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas >>>> <nicholas.kazlauskas@amd.com> wrote: >>>>> The dumb_create API isn't intended for high performance rendering >>>>> and it's more useful for userspace (ie. IGT) to have them precleared. >>>>> >>>>> The bonus here is that we also won't needlessly leak whatever was >>>>> previously in VRAM, but it also probably wasn't sensitive if it was >>>>> going through this API. >>>>> >>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> >>> NAK, IIRC we used to have this bit here before. >>> >>> In general I agree that this would be a good idea, but the problem is >>> the that first dump buffer is sometimes created before the engine >>> (usually SDMA) to clear VRAM is initialized. >>> >>> So you can run into a nice crash on suspend/resume. >>> >>> Christian. >> FWIW I never hit it myself during any suspend/resume tests I did but >> I'll take your word for it. >> >> How about doing a map/memset/unmap immediately after buffer creation >> here? It'd be much slower, but it's also what we'd be doing in userspace >> anyway. > > And history repeat itself :) Yeah, that was also suggested before and > didn't worked either for some reason. > > But that was ~2 years ago and I really don't remember the details. > > What could work is maybe to add a check if the engine is available if > the flag is given and ignore it when it isn't. > > Christian. The function amdgpu_fill_buffer is used to clear memory, and it checks if (!adev->mman.buffer_funcs_enabled) at the start. And buffer_funcs_enabled is only set after SDMA has been initialized following resume. In the case where the SDMA engine is off it'll just throw that DRM_ERROR and return -EINVAL. So if we still want to continue with buffer creation in the case where the engine is off then this flag could also be checked in dumb_buffer_create and cleared in the case where buffer_funcs_enabled = false. How does that sound to you? Nicholas Kazlauskas > >> >> Nicholas Kazlauskas >> >> >>>>> --- >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- >>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>> index fcaaac30e84b..a58072bbc9b8 100644 >>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>> @@ -743,7 +743,8 @@ int amdgpu_mode_dumb_create(struct drm_file >>>>> *file_priv, >>>>> domain = amdgpu_bo_get_preferred_pin_domain(adev, >>>>> >>>>> amdgpu_display_supported_domains(adev)); >>>>> r = amdgpu_gem_object_create(adev, args->size, 0, domain, >>>>> - >>>>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED, >>>>> + >>>>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED | >>>>> + AMDGPU_GEM_CREATE_VRAM_CLEARED, >>>>> ttm_bo_type_device, NULL, &gobj); >>>>> if (r) >>>>> return -ENOMEM; >>>>> -- >>>>> 2.17.1 >>>>> >>>>> _______________________________________________ >>>>> amd-gfx mailing list >>>>> amd-gfx@lists.freedesktop.org >>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >>>> _______________________________________________ >>>> amd-gfx mailing list >>>> amd-gfx@lists.freedesktop.org >>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <7e271708-34ad-db55-54ca-eaccd954eff6-5C7GfCeVMHo@public.gmane.org>]
* Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers [not found] ` <7e271708-34ad-db55-54ca-eaccd954eff6-5C7GfCeVMHo@public.gmane.org> @ 2019-03-11 18:04 ` Christian König 0 siblings, 0 replies; 7+ messages in thread From: Christian König @ 2019-03-11 18:04 UTC (permalink / raw) To: Kazlauskas, Nicholas, Koenig, Christian, Alex Deucher; +Cc: amd-gfx list Am 11.03.19 um 18:53 schrieb Kazlauskas, Nicholas: > On 3/11/19 1:31 PM, Koenig, Christian wrote: >> Am 11.03.19 um 18:04 schrieb Kazlauskas, Nicholas: >>> On 3/11/19 12:58 PM, Christian König wrote: >>>> Am 08.03.19 um 17:47 schrieb Alex Deucher: >>>>> On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas >>>>> <nicholas.kazlauskas@amd.com> wrote: >>>>>> The dumb_create API isn't intended for high performance rendering >>>>>> and it's more useful for userspace (ie. IGT) to have them precleared. >>>>>> >>>>>> The bonus here is that we also won't needlessly leak whatever was >>>>>> previously in VRAM, but it also probably wasn't sensitive if it was >>>>>> going through this API. >>>>>> >>>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> >>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> >>>> NAK, IIRC we used to have this bit here before. >>>> >>>> In general I agree that this would be a good idea, but the problem is >>>> the that first dump buffer is sometimes created before the engine >>>> (usually SDMA) to clear VRAM is initialized. >>>> >>>> So you can run into a nice crash on suspend/resume. >>>> >>>> Christian. >>> FWIW I never hit it myself during any suspend/resume tests I did but >>> I'll take your word for it. >>> >>> How about doing a map/memset/unmap immediately after buffer creation >>> here? It'd be much slower, but it's also what we'd be doing in userspace >>> anyway. >> And history repeat itself :) Yeah, that was also suggested before and >> didn't worked either for some reason. >> >> But that was ~2 years ago and I really don't remember the details. >> >> What could work is maybe to add a check if the engine is available if >> the flag is given and ignore it when it isn't. >> >> Christian. > The function amdgpu_fill_buffer is used to clear memory, and it checks > > if (!adev->mman.buffer_funcs_enabled) > > at the start. And buffer_funcs_enabled is only set after SDMA has been > initialized following resume. In the case where the SDMA engine is off > it'll just throw that DRM_ERROR and return -EINVAL. > > So if we still want to continue with buffer creation in the case where > the engine is off then this flag could also be checked in > dumb_buffer_create and cleared in the case where buffer_funcs_enabled = > false. > > How does that sound to you? Yeah, that sounds like a plan to me. Christian. > > Nicholas Kazlauskas > >>> Nicholas Kazlauskas >>> >>> >>>>>> --- >>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>>> index fcaaac30e84b..a58072bbc9b8 100644 >>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c >>>>>> @@ -743,7 +743,8 @@ int amdgpu_mode_dumb_create(struct drm_file >>>>>> *file_priv, >>>>>> domain = amdgpu_bo_get_preferred_pin_domain(adev, >>>>>> >>>>>> amdgpu_display_supported_domains(adev)); >>>>>> r = amdgpu_gem_object_create(adev, args->size, 0, domain, >>>>>> - >>>>>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED, >>>>>> + >>>>>> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED | >>>>>> + AMDGPU_GEM_CREATE_VRAM_CLEARED, >>>>>> ttm_bo_type_device, NULL, &gobj); >>>>>> if (r) >>>>>> return -ENOMEM; >>>>>> -- >>>>>> 2.17.1 >>>>>> >>>>>> _______________________________________________ >>>>>> amd-gfx mailing list >>>>>> amd-gfx@lists.freedesktop.org >>>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >>>>> _______________________________________________ >>>>> amd-gfx mailing list >>>>> amd-gfx@lists.freedesktop.org >>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-03-11 18:04 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-08 15:38 [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers Nicholas Kazlauskas
[not found] ` <20190308153816.7978-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2019-03-08 16:47 ` Alex Deucher
[not found] ` <CADnq5_PxyfDKVLgQ9iBqEsSGX-jYMbr-RsxrvM5j=0N7AF-w5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-11 16:58 ` Christian König
[not found] ` <73f25762-0277-7e12-dfff-a016d245478c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-03-11 17:04 ` Kazlauskas, Nicholas
[not found] ` <a5aa3caf-253e-8832-c63e-77269d4e865f-5C7GfCeVMHo@public.gmane.org>
2019-03-11 17:31 ` Koenig, Christian
[not found] ` <e021eacf-8200-fe28-6aad-0bfbcb27798c-5C7GfCeVMHo@public.gmane.org>
2019-03-11 17:53 ` Kazlauskas, Nicholas
[not found] ` <7e271708-34ad-db55-54ca-eaccd954eff6-5C7GfCeVMHo@public.gmane.org>
2019-03-11 18:04 ` Christian König
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.