From: Harry Wentland <harry.wentland@amd.com>
To: Mario Kleiner <mario.kleiner.de@gmail.com>,
Alex Deucher <alexdeucher@gmail.com>
Cc: "Liviu Dudau" <liviu@dudau.co.uk>, "Leo Li" <sunpeng.li@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
LKML <linux-kernel@vger.kernel.org>,
"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH] drm/amd/display: Fix 10bit 4K display on CIK GPUs
Date: Thu, 15 Jul 2021 15:40:27 -0400 [thread overview]
Message-ID: <ea5363b5-a54e-383d-f5bd-214bb8b50c96@amd.com> (raw)
In-Reply-To: <CAEsyxyhurQ2vm=xwaRMqT8z+PJ2R60hYXt6kL8HnaB4zwbee3Q@mail.gmail.com>
On 2021-07-15 3:19 p.m., Mario Kleiner wrote:
> On Thu, Jul 15, 2021 at 6:10 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>>
>> On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau <liviu@dudau.co.uk> wrote:
>>>
>>> Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
>>> 30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
>>> DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
>>> image that looks like it has an effective resolution of 1920x1080 but
>>> scaled up in an irregular way. Reverting the commit or applying this
>>> patch fixes the problem on v5.14-rc1.
>>>
>>> Fixes: 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.")
>>> Signed-off-by: Liviu Dudau <liviu@dudau.co.uk>
>>
>> Harry or Mario any ideas? Maybe we need finer grained DCE version
>> checking? I don't remember all of the caveats of this stuff. DCE11
>> and older is getting to be pretty old at this point. I can just apply
>> this if you don't have any insights.
>>
>> Alex
>>
>
> Hi Alex
>
> I'd be fine with applying this. As my original commit says, photometer
> measurements showed that increasing the line buffer depth was only
> needed for my DCN-1 RavenRidge, not for my DCE-11.2 Polaris11 or a
> DCE-8.3 cik, so this should probably not cause harm to the increased
> precision modes.
>
> Note that given the hardware and USB-C/DP-HDMI adapters i have, I only
> tested this on a 2560x1440@144 Hz DP monitor with DCN-1, DCE-11.2, and
> a 2560x1440@100 Hz HDMI monitor iirc with DCN-1, DCE-8.3, and i think
> on a 2880x1800@60 Hz MBP Retina eDP panel with DCE-11.2. These are the
> highest resolution/framerate monitors I have atm.I don't have access
> to any 4k monitors, so maybe the problem is somehow specific to such
> 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.kleiner.de@gmail.com>
Makes sense.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Harry
>
> -mario
>
>>> ---
>>> drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>>> index a6a67244a322e..1596f6b7fed7c 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
>>> @@ -1062,7 +1062,7 @@ bool resource_build_scaling_params(struct pipe_ctx *pipe_ctx)
>>> * so use only 30 bpp on DCE_VERSION_11_0. Testing with DCE 11.2 and 8.3
>>> * did not show such problems, so this seems to be the exception.
>>> */
>>> - if (plane_state->ctx->dce_version != DCE_VERSION_11_0)
>>> + if (plane_state->ctx->dce_version > DCE_VERSION_11_0)
>>> pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_36BPP;
>>> else
>>> pipe_ctx->plane_res.scl_data.lb_params.depth = LB_PIXEL_DEPTH_30BPP;
>>> --
>>> 2.32.0
>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
next prev parent reply other threads:[~2021-07-15 19:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 8:06 [PATCH] drm/amd/display: Fix 10bit 4K display on CIK GPUs Liviu Dudau
2021-07-15 16:10 ` Alex Deucher
2021-07-15 19:19 ` Mario Kleiner
2021-07-15 19:40 ` Harry Wentland [this message]
2021-07-16 16:45 ` Alex Deucher
-- strict thread matches above, loose matches on Subject: below --
2021-07-13 20:18 Liviu Dudau
2021-07-13 20:10 Liviu Dudau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea5363b5-a54e-383d-f5bd-214bb8b50c96@amd.com \
--to=harry.wentland@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu@dudau.co.uk \
--cc=mario.kleiner.de@gmail.com \
--cc=sunpeng.li@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).