In previous gfx9 parts, S_BARRIER shader instructions are implicitly
S_WAITCNT 0 instructions as well. This setting turns off that
mechanism in Arcturus and beyond. With this, shaders must follow
the ISA guide insofar as putting in explicit S_WAITCNT operations
even after an S_BARRIER.
v2: Fix
In previous gfx9 parts, S_BARRIER shader instructions are implicitly
S_WAITCNT 0 instructions as well. This setting turns off that
mechanism in Arcturus and beyond. With this, shaders must follow
the ISA guide insofar as putting in explicit S_WAITCNT operations
even after an S_BARRIER.
Change-Id:
On Fri, 2020-01-24 at 16:46 -0500, Lyude Paul wrote:
> On Fri, 2020-01-24 at 14:20 -0500, Mikita Lipski wrote:
> > On 1/24/20 2:10 PM, Lyude Paul wrote:
> > > Disabling a display on MST can potentially happen after the entire MST
> > > topology has been removed, which means that we can't
On Fri, 2020-01-24 at 14:20 -0500, Mikita Lipski wrote:
> On 1/24/20 2:10 PM, Lyude Paul wrote:
> > Disabling a display on MST can potentially happen after the entire MST
> > topology has been removed, which means that we can't communicate with
> > the topology at all in this scenario. Likewise,
On 2020-01-16 3:20 p.m., Bhawanpreet Lakha wrote:
> [Why]
> When we disable a connector we don't explicitly remove it from the module so
> the
> display is still cached(SW) in the hdcp_module.
>
> SST: no issues because we can only have 1 display per link
>
> MST: We have x displays per link,
From: Roman Li
[Why]
Driver crash with psr feature enabled due to divide-by-zero error.
This is a regression after rework to calculate static screen frame
number entry time.
[How]
Correct order of operations to avoid divide-by-zero.
Cc: Colin Ian King
Fixes: 5b5abe952607 drm/amd/display: make
On 1/24/20 2:10 PM, Lyude Paul wrote:
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means that we
can't properly update payloads on the
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means that we
can't properly update payloads on the topology and as such, it's a good
idea to
On Fri, 2020-01-24 at 11:39 -0500, Mikita Lipski wrote:
>
> On 1/24/20 9:55 AM, Harry Wentland wrote:
> > On 2020-01-23 7:06 p.m., Lyude Paul wrote:
> > > Disabling a display on MST can potentially happen after the entire MST
> > > topology has been removed, which means that we can't
Sorry for the delay, change LGTM.
Reviewed-by: Leo Li
, and applied.
Thanks!
Leo
On 2020-01-24 5:18 a.m., Dor Askayo wrote:
> On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote:
>>
>> On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
>>>
>>> This allocation isn't required and can fail when
On 1/24/20 9:55 AM, Harry Wentland wrote:
On 2020-01-23 7:06 p.m., Lyude Paul wrote:
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
v2: allocate memory for entity and fences together
Signed-off-by: Nirmoy Das
Am 24.01.20 um 16:15 schrieb Nirmoy Das:
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
v2: allocate memory for entity and
On 1/24/20 1:56 PM, Christian König wrote:
+ entity->fences = kcalloc(amdgpu_sched_jobs,
+ sizeof(struct dma_fence*), GFP_KERNEL);
It would be rather nice to have to allocate the fences array together
with the entity.
Take a look at struct dma_resv_list and the
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
v2: allocate memory for entity and fences together
Signed-off-by: Nirmoy Das
On 2020-01-23 7:06 p.m., Lyude Paul wrote:
> Disabling a display on MST can potentially happen after the entire MST
> topology has been removed, which means that we can't communicate with
> the topology at all in this scenario. Likewise, this also means that we
> can't properly update payloads on
On 2020-01-23 8:07 p.m., Lyude Paul wrote:
> These are some very loud debug statements that get printed on every
> vblank when driver level debug printing is enabled in DRM, and doesn't
> really tell us anything that isn't related to vblanks. So let's move
> this over to the proper debug flag to
Only write the _HI register when necessary.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
This speeds up the access quite a bit from 2.2 MB/s to 2.9 MB/s on a Polaris.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 27 ++---
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
Am 24.01.20 um 13:43 schrieb Nirmoy:
On 1/24/20 1:09 PM, Christian König wrote:
+ return -ENOMEM;
That's complete overkill, just statically allocate the array in the
amdgpu_ctx structure.
The maximum instance should be 4 IIRC, so something like "struct
amdgpu_ctx_entity
Am 24.01.20 um 13:41 schrieb Nirmoy Das:
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
Signed-off-by: Nirmoy Das
---
On 1/24/20 1:09 PM, Christian König wrote:
+ return -ENOMEM;
That's complete overkill, just statically allocate the array in the
amdgpu_ctx structure.
The maximum instance should be 4 IIRC, so something like "struct
amdgpu_ctx_entity *entities[AMDGPU_HW_IP_NUM][4];" so a maximum of 288
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 232
Am 24.01.20 um 12:53 schrieb Nirmoy Das:
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
Signed-off-by: Nirmoy Das
---
Currently we pre-allocate entities and fences for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity/fences wastage by creating entity
only when needed.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 244
On 1/23/20 5:13 PM, Nirmoy Das wrote:
+ kfree(ctx->entities[i];
Forgot to add change that fix ^
Regards,
Nirmoy
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dear Thomas,
Thank you for your patch,
For this stm part,
Acked-by: Philippe Cornu
Philippe :-)
On 1/23/20 2:59 PM, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert stm over.
>
> Signed-off-by:
Dear Thomas,
Thank you for your patch,
For this stm part,
Acked-by: Philippe Cornu
Philippe :-)
On 1/23/20 2:59 PM, Thomas Zimmermann wrote:
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm
>
28 matches
Mail list logo
