-...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=No
uveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mario.
kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170311Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq
quot;famous last words") depth 30 should hopefully fix all known problems
without introducing new ones.
Successfully retested on DCE-11.2 Polaris and DCN-1.0 Raven Ridge on
top of Linux 5.19.0-rc2 + drm-next.
Fixes: 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display on CIK GPUs"
h
high resolutions? Maybe somewhere else in the code something would
need to be adapted? Lacking actual hw docs, my coding here is by
pattern matching against existing DC code, guessing and testing on my
limited hw samples.
Acked-by: Mario Kleiner
-mario
> > ---
> > drivers/gpu
On Thu, Jun 10, 2021 at 9:55 AM Pekka Paalanen wrote:
>
> On Tue, 8 Jun 2021 19:43:15 +0200
> Werner Sembach wrote:
>
> > Add a new general drm property "active bpc" which can be used by graphic
> > drivers
> > to report the applied bit depth per pixel back to userspace.
> >
Maybe "bit depth p
On Tue, Jun 1, 2021 at 6:50 PM StDenis, Tom wrote:
>
> [AMD Official Use Only]
>
> Hi Mario,
>
> Yes, this diff fixes the display on my Carrizo:
>
> [root@carrizo linux]# git diff
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.
0 bpp linebuffer depth on asics with DCE-11.0 display engine.
Reported-by: Tom StDenis
Signed-off-by: Mario Kleiner
Cc: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc
On Tue, Jun 1, 2021 at 4:00 PM Alex Deucher wrote:
>
> For 16bpc display support.
>
> Signed-off-by: Alex Deucher
> Cc: Mario Kleiner
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --gi
imilar happens here?
-mario
> commit b1114ddd63be03825182d6162ff25fa3492cd6f5
> Author: Mario Kleiner
> Date: Fri Mar 19 22:03:15 2021 +0100
>
> drm/amd/display: Increase linebuffer pixel depth to 36bpp.
>
> Testing with the photometer shows that at least Raven Ridge DCN-1.0
> does
On Thu, May 6, 2021 at 8:37 AM Ville Syrjälä
wrote:
>
> On Sat, Mar 20, 2021 at 04:09:47AM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 10:45:10PM +0100, Mario Kleiner wrote:
> > > On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
> > > wrote:
> > &g
On Wed, Apr 28, 2021 at 11:22 PM Alex Deucher wrote:
>
> On Tue, Apr 20, 2021 at 5:25 PM Alex Deucher wrote:
> >
> > On Fri, Apr 16, 2021 at 12:29 PM Mario Kleiner
> > wrote:
> > >
> > > Friendly ping to the AMD people. Nicholas, Harry, Alex, any fee
On Tue, May 4, 2021 at 9:22 PM Alex Deucher wrote:
>
> On Wed, Apr 28, 2021 at 5:21 PM Alex Deucher wrote:
> >
> > On Tue, Apr 20, 2021 at 5:25 PM Alex Deucher wrote:
> > >
> > > On Fri, Apr 16, 2021 at 12:29 PM Mario Kleiner
> > > wrote:
&g
Friendly ping to the AMD people. Nicholas, Harry, Alex, any feedback?
Would be great to get this in sooner than later.
Thanks and have a nice weekend,
-mario
On Fri, Mar 19, 2021 at 10:03 PM Mario Kleiner
wrote:
>
> Hi,
>
> this patch series adds the fourcc's for 16 bit
On Mon, Mar 22, 2021 at 4:52 PM Ville Syrjälä
wrote:
>
> On Fri, Mar 19, 2021 at 10:03:12PM +0100, Mario Kleiner wrote:
> > Hi,
> >
> > this patch series adds the fourcc's for 16 bit fixed point unorm
> > framebuffers to the core, and then an implementation
On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
wrote:
>
> On Fri, Mar 19, 2021 at 10:03:13PM +0100, Mario Kleiner wrote:
> > These are 16 bits per color channel unsigned normalized formats.
> > They are supported by at least AMD display hw, and suitable for
> > direct sca
.
Successfully tested on AMD Polaris11 DCE-11.2 an RavenRidge DCN-1.0
with a HDR-10 monitor over 10 bpc DP output with spatial dithering
enabled by the driver. Picture looks good, and my photometer
measurement procedure confirms an effective 12 bpc color
reproduction.
Signed-off-by: Mario Kleiner
This is needed to avoid warnings with linebuffer depth 36 bpp.
Testing on a Polaris11, DCE-11.2 on a 10 bit HDR-10 monitor
showed no obvious problems, and this 12 bpc limit is consistent
with what other function in the DCE bit depth reduction path use.
Signed-off-by: Mario Kleiner
---
drivers
. Otherwise precision gets truncated somewhere
to 10 bpc effective depth.
Strangely this increase was not needed on Polaris11 DCE-11.2 during
testing to get 12 bpc effective precision. It also is not needed for
fp16 framebuffers.
Tested on DCN-1.0 and DCE-11.2.
Signed-off-by: Mario Kleiner
---
drivers
_UNORM onto
DRM_FORMAT_XBGR16161616.
The old id 22 would cause colorful pixeltrash to be displayed instead.
Tested under DCN-1.0 and DCE-11.2.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c| 2 ++
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c
These are 16 bits per color channel unsigned normalized formats.
They are supported by at least AMD display hw, and suitable for
direct scanout of Vulkan swapchain images in the format
VK_FORMAT_R16G16B16A16_UNORM.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_fourcc.c | 4
include
Hi,
this patch series adds the fourcc's for 16 bit fixed point unorm
framebuffers to the core, and then an implementation for AMD gpu's
with DisplayCore.
This is intended to allow for pageflipping to, and direct scanout of,
Vulkan swapchain images in the format VK_FORMAT_R16G16B16A16_UNORM.
I hav
Your v2 has my
Reviewed-by: Mario Kleiner
thanks,
-mario
On Wed, Feb 17, 2021 at 11:51 PM Alex Deucher wrote:
> From: Mario Kleiner
>
> Spatial dithering to 10 bpc depth was disabled for all DCE's.
>
> Testing on DCE-8.3 and DCE-11.2 did not show any obvious ill
> eff
On Mon, Feb 15, 2021 at 8:09 PM Alex Deucher wrote:
> On Fri, Feb 12, 2021 at 5:30 PM Mario Kleiner
> wrote:
> >
> > Spatial dithering to 10 bpc depth was disabled for all DCE's.
> > Restrict this to DCE-11.0, but allow it on other DCE's.
> >
> > Te
On Fri, Feb 12, 2021 at 6:32 AM Alex Deucher wrote:
> On Thu, Feb 11, 2021 at 4:12 PM Mario Kleiner
> wrote:
> >
> > On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher
> wrote:
> >>
> >> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
> >> wrote:
>
10 bpc DP or HDMI connected
HDR-10 monitor.
Alex suggests this may have been a workaround for some DCE-11.0
Carrizo and Stoney Asics, so lets try to restrict this to DCE 11.0.
Signed-off-by: Mario Kleiner
Cc: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 9 ++---
1 file
On Wed, Feb 10, 2021 at 10:36 PM Alex Deucher wrote:
> On Wed, Feb 10, 2021 at 4:08 PM Mario Kleiner
> wrote:
> >
> > Resending this one as well, in the hope of some clarification or
> background information.
> >
>
>
Thanks Alex.
I suspect this may have be
Resending this one as well, in the hope of some clarification or background
information.
Thanks,
-mario
On Mon, Jan 25, 2021 at 3:56 AM Mario Kleiner
wrote:
> Hi Harry and Nicholas,
>
> I'm still on an extended quest to squeeze as much HDR out of Linux + your
> hw as possi
Ping. Any bit of info appreciated wrt. the DCE-11.2+ situation.
-mario
On Mon, Jan 25, 2021 at 8:24 PM Mario Kleiner
wrote:
> Thanks Alex and Nicholas! Brings quite a bit of extra shiny to those older
> asics :)
>
> Nicholas, any thoughts on my cover-letter wrt. why a similar p
ere a
certain DCE version at which your team starts validating output precision /
HDR etc. on hw?
Thanks,
-mario
On Mon, Jan 25, 2021 at 8:16 PM Kazlauskas, Nicholas <
nicholas.kazlaus...@amd.com> wrote:
> On 2021-01-25 12:57 p.m., Alex Deucher wrote:
> > On Thu, Jan 21, 2021 at 1
On Mon, Jan 4, 2021 at 6:16 PM Alex Deucher wrote:
>
> On Mon, Dec 28, 2020 at 1:51 PM Mario Kleiner
> wrote:
> >
> > Hi and happy post-christmas!
> >
> > I wrote a patch 1/1 that now checks plane scaling factors against
> > the pixel-format specific l
y tested
on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI
deep color output with 10 bpc or 12 bpc.
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
---
.../drm/amd/display/dc/bios/command_table.c | 61 +++
drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
b/drivers/gpu/dr
Hi,
these two patches fix non-working HDMI deep color output on DCE-8.3,
AMD Mullins when amdgpu-kms is used with Displaycore force-enabled,
ie. for radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dc=1:
I suspect they might fix similar problems on other older asics of
DCE-11.0 and earlier.
Patch
On Thu, Jan 7, 2021 at 7:04 PM Daniel Vetter wrote:
> On Thu, Jan 7, 2021 at 7:00 PM Mario Kleiner
> wrote:
> >
> > On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
> >>
> >> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
>
On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
> > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > With modifiers one can actually have different format_info structs
On Thu, Jan 7, 2021 at 6:21 PM Liu, Zhan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> > -Original Message-
> > From: Liu, Zhan
> > Sent: 2021/January/06, Wednesday 10:04 AM
> > To: Bas Nieuwenhuizen ; Mario Kleiner
> >
On Sat, Jan 2, 2021 at 7:51 PM Ilia Mirkin wrote:
> On Sat, Jan 2, 2021 at 1:35 PM Mario Kleiner
> wrote:
> > I'm less sure about nouveau. It uses modifiers, but has atomic support
> > only on nv50+ and that atomic support is off by default -- needs a
> > nouveau.no
On Sat, Jan 2, 2021 at 4:49 PM Bas Nieuwenhuizen
wrote:
>
> On Sat, Jan 2, 2021 at 4:05 PM Mario Kleiner
> wrote:
> >
> > On Sat, Jan 2, 2021 at 3:05 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > I think the problem here is that application A can se
On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
wrote:
>
> With modifiers one can actually have different format_info structs
> for the same format, which now matters for AMDGPU since we convert
> implicit modifiers to explicit modifiers with multiple planes.
>
> I checked other drivers and it do
under Mesa if pageflipping isn't used. Also good to test
synchronization on dual-display setups, e.g., for udal-display stereo
presentation.
I was actually surprised that this patch made it through the various
test suites and into drm-next. I thought page-flipping was covered
well e
y: Set new format info for converted
metadata.")
Cc: Bas Nieuwenhuizen
Cc: Alex Deucher
Cc: David Airlie
Cc: Ville Syrjälä
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_plane.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane
doesn't show any users of the getfb2 ioctl(), so the need for this
format info assignment seems to be more the exception than the rule?
Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
metadata.")
Cc: Bas Nieuwenhuizen
Cc: Alex Deucher
Signed-off-by: M
DCE-8 asic, so i assume that the more
recent DCE-10/11 will work equally well, now that
format-specific plane scaling constraints are properly
enforced, e.g., the inability of fp16 to scale on older
hw like DCE-8 to DCE-11.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/dc/dce100
This takes hw constraints specific to pixel formats into account,
e.g., the inability of older hw to scale fp16 format framebuffers.
It should now allow safely to enable fp16 formats also on DCE-8,
DCE-10, DCE-11.0
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Hi and happy post-christmas!
I wrote a patch 1/1 that now checks plane scaling factors against
the pixel-format specific limits in the asic specific dc_plane_cap
structures during atomic check and other appropriate places.
This should prevent things like asking for scaling on fp16 framebuffers
if
Assuming the hw supports fp16, this would be also
useful for standard dynamic range displays, not
only for HDR use cases, because it would allow
to get more precise color reproduction with about
~11 bpc linear precision in the unorm range
0.0 -1.0.
Signed-off-by: Mario Kleiner
---
drivers/gpu
Assuming the hw supports fp16, this would be also
useful for standard dynamic range displays, not
only for HDR use cases, because it would allow
to get more precise color reproduction with about
~11 bpc linear precision in the unorm range
0.0 -1.0.
Signed-off-by: Mario Kleiner
---
drivers/gpu
So i'm sending these on the off-chance that DCE-8/10 do
support fp16 scanout without hw bugs. Would be nice to
enable this if it is supported, even if the hw can't do
HDR. This is also useful for non-HDR to get effectively
11 bpc precision from the fb to the display outputs for
more precise color r
On Wed, May 20, 2020 at 9:07 PM Kazlauskas, Nicholas <
nicholas.kazlaus...@amd.com> wrote:
> On 2020-05-20 2:44 p.m., Mario Kleiner wrote:
> > On Wed, May 20, 2020 at 8:25 PM Alex Deucher > <mailto:alexdeuc...@gmail.com>> wrote:
> >
> > On Wed,
On Wed, May 20, 2020 at 8:25 PM Alex Deucher wrote:
> On Wed, May 20, 2020 at 12:39 PM Harry Wentland wrote:
> >
> > On 2020-05-15 1:19 a.m., Mario Kleiner wrote:
> > > Testing on a Polaris11 gpu with DCE-11.2 suggests that it
> > > seems to work fine there
Testing on a Polaris11 gpu with DCE-11.2 suggests that it
seems to work fine there, so optimistically enable it for
DCE-11 and later.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2
Expose support for DRM_FORMAT_ABGR16161616F and
DRM_FORMAT_XBGR16161616F to the DRM core, complementing
the already existing xRGB ordered fp16 formats.
These are especially useful for creating presentable
swapchains in Vulkan for VK_FORMAT_R16G16B16A16_SFLOAT.
Signed-off-by: Mario Kleiner
Hi,
two patches. The first one adds the xBGR ordered variants of fp16
in addition to the xRGB ordered variants that were merged just
very recently.
These variants are required for direct scanout of OpenGL and Vulkan
rendered content, as both OpenGL (GL_RGBA16F) and Vulkan
(VK_FORMAT_R16G16B16A16_
lem
is highly dependent on small timing differences in game execution, vblank
durations, etc.
So fwif here's my
Reviewed-and-Tested-by: Mario Kleiner
-mario
On 2020-05-07 12:58 p.m., Mario Kleiner wrote:
>
> Looking over it now, will do some testing. Alex amdgpu-drm-next branch
> wou
o send back events when active planes == 0.
> >
> > Some refactoring/cleanup was done to not have duplicated code in both
> > the handlers.
> >
> > Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at
> vsartup for DCN")
> > Fi
On Fri, Mar 13, 2020 at 5:02 PM Michel Dänzer wrote:
> On 2020-03-13 1:35 p.m., Kazlauskas, Nicholas wrote:
> > On 2020-03-12 10:32 a.m., Alex Deucher wrote:
> >> On Thu, Mar 5, 2020 at 4:21 PM Mario Kleiner
> >> wrote:
> >>>
> >>> Commit &#
On Mon, Mar 2, 2020 at 2:57 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-03-02 1:17 a.m., Mario Kleiner wrote:
> > Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
> > events at vsartup for DCN")' introduces a new way of pageflip
> > c
s: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup
for DCN")
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 80 ---
1 file changed, 67 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/displ
f this fixes the problem the original commit
tried to address, as i don't know what the test scenario was. It
does fix the observed too early pageflip events though and points
out the problem introduced.
Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup
for DCN
On Thu, Feb 27, 2020 at 8:11 PM Mario Kleiner
wrote:
>
> Hi Harry
>
> Ok, back from various other emergencies and deadlines, sorry for the
> late reply. I also fixed my e-mail address - it was mistyped, causing
> all these delivery failures :/
>
> On Thu, Jan 9, 2020 at
anel goes dark.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to override reported max link rate to the correct maximum
of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
precision.
Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
support.
Signe
Hi Harry
Ok, back from various other emergencies and deadlines, sorry for the
late reply. I also fixed my e-mail address - it was mistyped, causing
all these delivery failures :/
On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote:
>
> On 2020-01-09 4:13 p.m., Mario Kleiner wrote:
>
On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland wrote:
> On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> > If the current eDP link settings, as read from hw, provide a higher
> > bandwidth than the verified_link_cap ones (= reported_link_cap), then
> > override verified_
: Mario Kleiner
Cc: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 5ea4a1675259..f3acdb8fead5 100644
--- a
read_current_link_settings_on_detect() on eDP 1.4+ may use the
edp_supported_link_rates table which is set up by
detect_edp_sink_caps(), so that function needs to be called first.
Signed-off-by: Mario Kleiner
Cc: Martin Leung
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
1 file
Hi and happy new year!
Since i now have a MBP 2017 to play with, with a 10 bit Retina panel,
and Polaris gpu, i'm trying to get it to get 10 bits, and found one
small bug [fix: patch1], and a quirk of Apples Retina eDP sink, for
which i propose patch2 as solution. I sent a similar patch to i915 to
Hi Leo and others,
sorry for the late reply. I just spent some time looking at your patches
and testing them on a Raven DCN-1.
I looked at how the vstartup line is computed in the dc_bandwidth_calcs
etc., and added some DRM_DEBUG statements to the dm_dcn_crtc_high_irq and
dm_pflip_high_irq handle
On Tue, Apr 30, 2019 at 2:22 PM Kazlauskas, Nicholas
wrote:
>
> On 4/30/19 3:44 AM, Michel Dänzer wrote:
> > [CAUTION: External Email]
> >
> > On 2019-04-30 9:37 a.m., Mario Kleiner wrote:
> >> Allow to detect any connected display to be marked as
> >> V
DPCD caps.
It will use a hard-coded VRR range of 30 Hz - 144 Hz on
other displays without suitable EDID, e.g., standard
DisplayPort, HDMI, DVI monitors.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11
On Mon, Apr 29, 2019 at 2:51 PM Kazlauskas, Nicholas
wrote:
>
> On 4/26/19 5:40 PM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some t
On Fri, Apr 26, 2019 at 7:12 PM Kazlauskas, Nicholas
wrote:
>
> On 4/26/19 6:50 AM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some t
prevents missed vblanks at the border
between non-BTR and BTR.
Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.
Signed-off-by: Mario Kleiner
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
ons
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.
v2: Fix some wrong locking, as pointed out by Nicholas.
v3: Simplify if-condition in vupdate-irq - nit by Nicholas.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/d
Same as rev 2, except for patch 3/3 v3 to apply Nicholas
latest feedback into account. Retested on DCN1 and DCE8.
thanks,
-mario
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
prevents missed vblanks at the border
between non-BTR and BTR.
Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.
Signed-off-by: Mario Kleiner
ons
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.
v2: Fix some wrong locking, as pointed out by Nicholas.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 +--
1 file c
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
Updated series. The debug patch is dropped, a r-b by Nicholas is tacked
onto patch 1/3 and patch 3/3 has the locking fix that Nicholas proposed.
In terms of testing 3/3 didn't change anything for the better or worse,
observed behaviour on retested DCN-1 and DCE-8 is the same.
Patch 2/3 is identical
On Wed, Apr 24, 2019 at 4:34 PM Kazlauskas, Nicholas
wrote:
>
> On 4/17/19 11:51 PM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some t
Helps with debugging issues with low framerate compensation.
Signed-off-by: Mario Kleiner
---
.../amd/display/modules/freesync/freesync.c| 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd
Hi
This patch-series tries to improve amdgpu's below-the-range
behaviour with Freesync, hopefully not only for my use case,
but also for games etc.
Patch 1/4 adds a bit of debug output i found very useful, so maybe
worth adding?
Patch 2/4 fixes a bug i found when reading over the freesync code.
prevents missed vblanks at the border
between non-BTR and BTR.
Testing on DCE-8, DCE-11 and DCN-1.0 shows that this more
often avoids skipped frames when moving across the BTR
boundary, especially on DCE-8 and DCE-11 with the followup
commit for dealing with pre-DCE-12 hw.
Signed-off-by: Mario Kleiner
ons
(low fps to high fps) < DCE-12 is a little bit improved,
although by far not as much as for up-sweeps and constant
fps.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 ++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/d
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
.
v2: Implement feedback by Nicholas and Paul Menzel.
Signed-off-by: Mario Kleiner
Acked-by: Harry Wentland
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 128 +-
.../gpu/drm/amd
nk of even after it, without a negative impact on flip
throttling, so followup patches can shift the vblank core
handling trigger point wherever they need it.
Signed-off-by: Mario Kleiner
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
.../gpu/drm/a
d-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 +++
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6528258f8975..6c413bc012af 100644
--- a/dr
we are in case a) or b),
we check the current scanout position against the boundary of
front-porch. In non-VRR mode we just do what we did in the past.
Signed-off-by: Mario Kleiner
Reviewed-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 +++
1
The hopefully final patch series, with feedback applied and
r-b / acked-by tags added. Rebased to current agd5f/drm-5.2-wip
branch.
Numbering has slightly changed. Patches 3-5 are identical to last
series. Patch 2/5 v3 (the former 1/4 v2) trivially rebased on top of
the new 1/5.
Patch 1/5 is new
beginning of commit tail before the
vrr transition handling, and a late part that must run after
vrr transition handling inside the commit planes code for
enabled crtc's.
Suggested by Nicholas Kazlauskas.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
we are in case a) or b),
we check the current scanout position against the boundary of
front-porch. In non-VRR mode we just do what we did in the past.
Signed-off-by: Mario Kleiner
Reviewed-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 +++
1
fixed
refresh rate non-VRR mode.
v2: Make sure transition is also handled if vrr is
disabled and stream gets disabled in the same
atomic commit. Suggested by Nicholas.
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 +++
1 file change
The current patch series, with feedback from Paul, Nicholas and Harry
applied and r-b / acked-by tags added. Thanks for the feedback.
Rebased to current drm-5.2-wip branch.
Patch 1/4 is still the same though. Don't know if i or Nicholas could
fix it in a followup patch, or this one needs more work
.
v2: Implement feedback by Nicholas and Paul Menzel.
Signed-off-by: Mario Kleiner
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 128 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9
nk of even after it, without a negative impact on flip
throttling, so followup patches can shift the vblank core
handling trigger point wherever they need it.
Signed-off-by: Mario Kleiner
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
.../gpu/drm/a
On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas
wrote:
>
> On 3/20/19 3:51 AM, Mario Kleiner wrote:
> > Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
> >
> > On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas
> > wrote
On Wed, Mar 20, 2019 at 2:11 PM Kazlauskas, Nicholas
wrote:
>
> On 3/20/19 4:12 AM, Mario Kleiner wrote:
> > During VRR mode we can not allow vblank irq dis-/enable
> > transitions, as an enable after a disable can happen at
> > an arbitrary time during the video refresh
On Mon, Mar 18, 2019 at 6:29 PM Kazlauskas, Nicholas
wrote:
>
> On 3/18/19 1:19 PM, Mario Kleiner wrote:
> > During VRR mode we can not allow vblank irq dis-/enable
> > transitions, as an enable after a disable can happen at
> > an arbitrary time during the video refresh
fixed
refresh rate non-VRR mode.
v2: Make sure transition is also handled if vrr is
disabled and stream gets disabled in the same
atomic commit. Suggested by Nicholas.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 +++
1 file ch
1 - 100 of 179 matches
Mail list logo
