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 f
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: "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)).
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 siz
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 i
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"
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, id
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 now
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 v
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 fb_helpe
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 uint16_
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:
>
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")
Fixe
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
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 visibl
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
ac
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
>
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 pigl
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
---
drivers/gpu/drm/amd/amdgpu/a
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 1
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 | 8
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 fil
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 100
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 fi
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 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vra
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mg
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
Cc
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 Of
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: Re
> -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 i
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
---
drivers/gpu/d
32 matches
Mail list logo