All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used
Date: Tue, 30 Apr 2019 10:22:40 +0530	[thread overview]
Message-ID: <1b775593-5259-70b8-84da-9a3dee237f64@intel.com> (raw)
In-Reply-To: <20190426143715.GP24299@intel.com>


On 4/26/2019 8:07 PM, Ville Syrjälä wrote:
> On Fri, Apr 26, 2019 at 06:40:11PM +0530, Sharma, Shashank wrote:
>> On 4/13/2019 12:00 AM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> The pipe has a special HDR mode with higher precision when only
>>> HDR planes are active. Let's use it.
>>>
>>> Curiously this fixes the kms_color gamma/degamma tests when
>>> using a HDR plane, which is always the case unless one hacks
>>> the test to use an SDR plane. If one does hack the test to use
>>> an SDR plane it does pass already.
>>>
>>> I have no actual explanation how the output after the gamma
>>> LUT can be different between the two modes. The way the tests
>>> are written should mean that the output should be identical
>>> between the solid color vs. the gradient. But clearly that
>>> somehow doesn't hold true for the HDR planes in non-HDR pipe
>>> mode. Anyways, as long as we stick to one type of plane the
>>> test should produce sensible results now.
>>>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/i915_reg.h      |  1 +
>>>    drivers/gpu/drm/i915/intel_display.c |  7 +++++++
>>>    drivers/gpu/drm/i915/intel_sprite.h  | 12 ++++++++----
>>>    3 files changed, 16 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>>> index 8ad2f0a03f28..90d60ecd3317 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -5767,6 +5767,7 @@ enum {
>>>    #define _PIPE_MISC_B			0x71030
>>>    #define   PIPEMISC_YUV420_ENABLE	(1 << 27)
>>>    #define   PIPEMISC_YUV420_MODE_FULL_BLEND (1 << 26)
>>> +#define   PIPEMISC_HDR_MODE		(1 << 23) /* icl+ */
>>>    #define   PIPEMISC_OUTPUT_COLORSPACE_YUV  (1 << 11)
>>>    #define   PIPEMISC_DITHER_BPC_MASK	(7 << 5)
>>>    #define   PIPEMISC_DITHER_8_BPC		(0 << 5)
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>> index 490bd49ff42a..d0dbdbd5db3f 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -4055,6 +4055,9 @@ static void intel_update_pipe_config(const struct intel_crtc_state *old_crtc_sta
>>>    			ironlake_pfit_disable(old_crtc_state);
>>>    	}
>>>    
>>> +	if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
>>> +		bdw_set_pipemisc(new_crtc_state);
>>> +
>>>    	if (INTEL_GEN(dev_priv) >= 11)
>>>    		icl_set_pipe_chicken(crtc);
>>>    }
>>> @@ -8869,6 +8872,10 @@ static void bdw_set_pipemisc(const struct intel_crtc_state *crtc_state)
>>>    		val |= PIPEMISC_YUV420_ENABLE |
>>>    			PIPEMISC_YUV420_MODE_FULL_BLEND;
>>>    
>>> +	if (INTEL_GEN(dev_priv) >= 11 &&
>>> +	    (crtc_state->active_planes & ~icl_hdr_plane_mask()) == 0)
>>> +		val |= PIPEMISC_HDR_MODE;
>>> +
>> Shouldn't we check if the content being played on plane is HDR before
>> enabling this bit (even though I am not sure if there is any harm in
>> doing that)? Or maybe check the connector->output_hdr_metadata ? Most of
>> the times we would be sending SDR buffers on this plane. What happens
>> exactly when we set this bit ? The bspec says:
>>
>> "This field enables the HDR mode, allowing for higher precision output
>> from the HDR supporting planes and bypassing the SDR planes in blending. "
> I think the bit is just misnamed (like most things with "HDR" in their
> name). It's just a "gimme moar precision" bit.

Lets make this a bit more clear, may be rename the bit to 
PIPEMISC_HDR_PRECISION_MODE instead?

With that change, this patch is

Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>

>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-04-30  4:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 18:30 [PATCH 1/2] drm/i915: Flatten and rename haswell_set_pipemisc() Ville Syrjala
2019-04-12 18:30 ` [PATCH 2/2] drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used Ville Syrjala
2019-04-26 13:10   ` Sharma, Shashank
2019-04-26 14:37     ` Ville Syrjälä
2019-04-30  4:52       ` Sharma, Shashank [this message]
2019-04-30 10:39         ` Ville Syrjälä
2019-04-30 13:43           ` Sharma, Shashank
2019-04-30 19:19             ` Ville Syrjälä
2019-04-30  9:17       ` Shankar, Uma
2019-04-12 18:34 ` [PATCH 1/2] drm/i915: Flatten and rename haswell_set_pipemisc() Chris Wilson
2019-04-12 19:41 ` ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork
2019-04-12 23:27 ` ✓ Fi.CI.IGT: " Patchwork

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=1b775593-5259-70b8-84da-9a3dee237f64@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.