Sorry, the lower FPS is related to the window being shown or not.
On Fri, Jun 15, 2018 at 9:48 PM Bráulio Bhavamitra
wrote:
> Hi all,
>
> Using raven ridge and latest amd-staging-drm-next available now.
>
> As you can see below, the performance after boot is about 7k FPS and 6k
> FPS after the
Hi all,
Using raven ridge and latest amd-staging-drm-next available now.
As you can see below, the performance after boot is about 7k FPS and 6k FPS
after the first resume.
The hungs also are more often after resuming.
Regards,
bráulio
7127 frames in 5.0 seconds = 7425.359 FPS
36318 frames in
From: Michel Dänzer
It can be quite big, and there's no need for it to be physically
contiguous. This is less likely to fail under memory pressure (has
actually happened while running piglit).
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
Am 15.06.2018 um 17:12 schrieb Michel Dänzer:
On 2018-06-15 05:05 PM, Christian König wrote:
Am 15.06.2018 um 16:27 schrieb Michel Dänzer:
From: Michel Dänzer
It can be quite big, and there's no need for it to be physically
contiguous. This is less likely to fail under memory pressure (has
Am 15.06.2018 um 17:14 schrieb Michel Dänzer:
On 2018-06-15 05:11 PM, Christian König wrote:
Am 15.06.2018 um 16:42 schrieb Michel Dänzer:
From: Michel Dänzer
Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least
partially in CPU visible VRAM, in particular when all VRAM is
On 2018-06-15 05:18 PM, Christian König wrote:
> Am 15.06.2018 um 17:14 schrieb Michel Dänzer:
>> On 2018-06-15 05:11 PM, Christian König wrote:
>>> Am 15.06.2018 um 16:42 schrieb Michel Dänzer:
>
+
+ if (mem->start >= adev->gmc.visible_vram_size >> PAGE_SHIFT)
return
From: Michel Dänzer
When enabling a secondary GPU output, Xorg can try resizing the screen
beyond the limit advertised by the driver, leading to drmModeAddFB
failing and primary GPU outputs turning off. Check for this and bail
instead.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c |
Am 15.06.2018 um 16:42 schrieb Michel Dänzer:
From: Michel Dänzer
Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least
partially in CPU visible VRAM, in particular when all VRAM is visible.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
From: Michel Dänzer
I came up with the fixes in patches 1 & 3 while looking into
https://bugs.freedesktop.org/106872 . It's not clear that these will be
enough to fix that, but they are moving in the right direction anyway.
Patch 2 is refactoring in preparation for patch 3.
Patch 4 is separate
From: Michel Dänzer
Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least
partially in CPU visible VRAM, in particular when all VRAM is visible.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 26 ++--
1
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 9b34df7017f0..9814e9aab317
From: Michel Dänzer
Preparation for the following fix, no functional change intended.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 +
From: Michel Dänzer
At least in theory, ttm_bo_validate may move the BO, in which case the
pin_size accounting would be inconsistent with when the BO was pinned.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 18 --
1
On 2018-06-15 05:11 PM, Christian König wrote:
> Am 15.06.2018 um 16:42 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least
>> partially in CPU visible VRAM, in particular when all VRAM is visible.
>>
>> Cc: sta...@vger.kernel.org
Currently, the maximum value that *counter* can reach is 255, and
code at line 150: while (counter < 1000) { implies a bigger value
could be expected.
Fix this by changing the type of variable *counter* from uint8_t
to uint16_t.
Addresses-Coverity-ID: 1470030 ("Operands don't affect result")
Am 15.06.2018 um 16:27 schrieb Michel Dänzer:
From: Michel Dänzer
It can be quite big, and there's no need for it to be physically
contiguous. This is less likely to fail under memory pressure (has
actually happened while running piglit).
Mhm, the last time I looked a drm_mm node had around
On 2018-06-15 05:05 PM, Christian König wrote:
> Am 15.06.2018 um 16:27 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> It can be quite big, and there's no need for it to be physically
>> contiguous. This is less likely to fail under memory pressure (has
>> actually happened while running
Acked-by: Marek Olšák
Marek
On Fri, Jun 15, 2018, 4:03 AM zhoucm1 wrote:
> Marek, Can I get your RB or Acked on this patches? Since these info are
> reported to UMD.
>
>
> Thanks,
>
> David Zhou
>
>
> On 2018年06月15日 15:22, zhoucm1 wrote:
> >
> >
> > On 2018年06月15日 15:16, Zhang, Jerry wrote:
>
On Fri, Jun 15, 2018 at 9:32 AM, Gustavo A. R. Silva
wrote:
> Currently, the maximum value that *counter* can reach is 255, and
> code at line 150: while (counter < 1000) { implies a bigger value
> could be expected.
>
> Fix this by changing the type of variable *counter* from uint8_t
> to
From: Ville Syrjälä
To pick the correct MST encoder i915 wants to know which crtc is going
to be feeding us. To that end let's pass the crtc to the .best_encoder()
hook. The atomic variant already knows the crtc via the connector state,
but the non-atomic hooks is still being used by the
From: "Leo (Sunpeng) Li"
DRM creates property types with unique IDs during kernel driver init.
Cache the color property IDs on DDX init for use later, when we need
to modify these properties. Also cache the (de)gamma LUT sizes, since
they are the same for all CRTCs on AMD hardware.
Since these
From: "Leo (Sunpeng) Li"
And destroy them on the CRTC destroy hook.
When initializing color management properties on the private
drmmode_crtc, we want to:
1. Default its color transform matrix (CTM) to identity
2. Program hardware with default color management values (SRGB for
de/regamma,
From: "Leo (Sunpeng) Li"
List color management properties on outputs if there is kernel support.
Otherwise, don't list them at all.
v2:
- Use switch statement in configure_and_change
- Also configure LUT sizes for outputs that don't have an attached CRTC.
We can do this since LUT sizes are
From: "Leo (Sunpeng) Li"
Setting a color property involves:
1. Staging the property onto the driver-private CRTC object
2. Pushing the staged property into kernel DRM, for HW programming
Add a function to do the staging, and execute the above steps in
output_property_set.
v2:
- Remove per-CRTC
From: "Leo (Sunpeng) Li"
Notify RandR of any updated color properties on the output's CRTC when
its get_property() hook is called.
v2: Remove per-CRTC check for color management support.
Signed-off-by: Leo (Sunpeng) Li
---
src/drmmode_display.c | 21 +
1 file changed, 21
From: "Leo (Sunpeng) Li"
We compose the two LUTs when pushing non-legacy gamma changes, and the
same needs to be done when setting legacy gamma.
To do so, we just call push_cm_prop() on the gamma LUT. It will compose
the LUTs for us, and fall back to using legacy LUT (upscaled to non-
legacy
From: "Leo (Sunpeng) Li"
Frequently, a user may have non-legacy gamma enabled for monitor
correction, while using legacy gamma for things like
redshift/nightlight.
To do so, we compose the two LUTs. Legacy gamma will be applied first,
then non-legacy. i.e. non-legacy_LUT(legacy_LUT(in_color)).
On 2018-06-14 09:49 PM, Leo Li wrote:
> On 2018-06-14 12:57 PM, Michel Dänzer wrote:
>> On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
>>> From: "Leo (Sunpeng) Li"
>>>
>>> This ended up being different enough from v2 to warrant a new
>>> patchset. Per
>>> Michel's suggestions, there have been
Am 15.06.2018 um 08:45 schrieb Chunming Zhou:
PAGE_SIZE for start_alignment is far much than hw requirement,
And now, update to expereince value from window side.
Change-Id: I08a7e72076386c32faf36ec4812b30e68dde23e5
Signed-off-by: Chunming Zhou
Acked-by: Christian König
---
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Christian K?nig
> Sent: Friday, June 15, 2018 15:09
> To: Zhou, David(ChunMing) ; amd-
> g...@lists.freedesktop.org
> Cc: Olsak, Marek ; Ryan, Sean
> Subject: Re: [PATCH] drm/amdgpu: update
On 2018年06月15日 15:16, Zhang, Jerry wrote:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Friday, June 15, 2018 15:09
To: Zhou, David(ChunMing) ; amd-
g...@lists.freedesktop.org
Cc: Olsak, Marek ; Ryan, Sean
Subject:
On 06/15/2018 03:22 PM, zhoucm1 wrote:
On 2018年06月15日 15:16, Zhang, Jerry wrote:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Friday, June 15, 2018 15:09
To: Zhou, David(ChunMing) ; amd-
g...@lists.freedesktop.org
PAGE_SIZE for start_alignment is far much than hw requirement,
And now, update to expereince value from window side.
Change-Id: I08a7e72076386c32faf36ec4812b30e68dde23e5
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 28 ++--
1 file changed,
Marek, Can I get your RB or Acked on this patches? Since these info are
reported to UMD.
Thanks,
David Zhou
On 2018年06月15日 15:22, zhoucm1 wrote:
On 2018年06月15日 15:16, Zhang, Jerry wrote:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
Behalf
34 matches
Mail list logo
