From: Keith Packard <keithp@keithp.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/7] drm/i915: split out Ironlake pipe bpp picking code
Date: Tue, 10 May 2011 14:23:18 -0700 [thread overview]
Message-ID: <yun39kmb67t.fsf@aiko.keithp.com> (raw)
In-Reply-To: <1303240361-6057-5-git-send-email-jbarnes@virtuousgeek.org>
[-- Attachment #1.1: Type: text/plain, Size: 3998 bytes --]
On Tue, 19 Apr 2011 12:12:38 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Figuring out which pipe bpp to use is a bit painful. It depends on both
> the encoder and display configuration attached to a pipe. For instance,
> to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
> on the pipe but also enable dithering. But driving that same
> framebuffer to a DisplayPort output on another pipe means using 8bpc and
> no dithering.
>
> So split out and enhance the code to handle the various cases, returning
> an appropriate pipe bpp as well as whether dithering should be enabled.
>
> Save the resulting pipe bpp in the intel_crtc struct for use by encoders
> in calculating bandwidth requirements (defaults to 24bpp on pre-ILK).
>
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> ---
> drivers/gpu/drm/i915/intel_display.c | 181 ++++++++++++++++++++++++++--------
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 140 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 8ef0c39..e81e418 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4232,6 +4232,120 @@ static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
> return dev_priv->lvds_use_ssc && i915_panel_use_ssc;
> }
>
> +/**
> + * intel_choose_pipe_bpp - figure out what color depth the pipe should send
> + * @crtc: CRTC structure
> + *
> + * A pipe may be connected to one or more outputs. Based on the depth of the
> + * attached framebuffer, choose a good color depth to use on the pipe.
> + *
> + * If possible, match the pipe depth to the fb depth. In some cases, this
> + * isn't ideal, because the connected output supports a lesser or restricted
> + * set of depths. Resolve that here:
> + * LVDS typically supports only 6bpc, so clamp down in that case
> + * HDMI supports only 8bpc or 12bpc, so clamp to 8bpc with dither for 10bpc
> + * Displays may support a restricted set as well, check EDID and clamp as
> + * appropriate.
> + *
> + * RETURNS:
> + * Dithering requirement (i.e. false if display bpc and pipe bpc match,
> + * true if they don't match).
> + */
> +static bool intel_choose_pipe_bpp(struct drm_crtc *crtc, unsigned int
> *pipe_bpp)
Should mention dithering in the name, perhaps
choose_pipe_bpp_and_dithering or some such? Perhaps returning the
dithering in another by-reference parameter?
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_encoder *encoder;
> + struct drm_connector *connector;
> + unsigned int display_bpc = UINT_MAX, fb_bpc, bpc;
> +
> + fb_bpc = crtc->fb->depth / 3;
> +
> + /* Walk the encoders & connectors on this crtc, get min bpc */
Don't you want the max bpc?
> +
> + /*
> + * We could just drive the pipe at the highest bpc all the time and
> + * enable dithering as needed, but that costs bandwidth. So choose
> + * the minimum value that expresses the full color range of the fb but
> + * also stays within the max display bpc discovered above.
> + */
> +
> + switch (crtc->fb->depth) {
> + case 8:
> + case 15:
> + case 16:
> + bpc = 6; /* min is 18bpp */
> + break;
> + case 24:
> + bpc = min((unsigned int)8, display_bpc);
> + break;
> + case 30:
> + bpc = min((unsigned int)10, display_bpc);
> + break;
> + case 48:
> + bpc = min((unsigned int)12, display_bpc);
> + break;
> + default:
> + DRM_DEBUG("unsupported depth, assuming 24 bits\n");
> + bpc = min((unsigned int)8, display_bpc);
> + break;
> + }
Hrm. 8-bit through a colormap should probably use 8 bpc? We can probably
ignore 15/16-bit direct color (which might want 8bpc as well).
The simple fix would be to use 8bpc on 8bpp and otherwise leave things alone.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2011-05-10 21:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 19:12 [RFC] Deep color support Jesse Barnes
2011-04-19 19:12 ` [PATCH 1/7] drm/i915: color range only works on pre-ILK Jesse Barnes
2011-05-10 21:12 ` Keith Packard
2011-05-10 21:16 ` Jesse Barnes
2011-05-10 21:22 ` Jesse Barnes
2011-05-10 22:14 ` Keith Packard
2011-04-19 19:12 ` [PATCH 2/7] drm/i915: don't set transcoder bpc on CougarPoint Jesse Barnes
2011-04-19 19:12 ` [PATCH 3/7] drm/i915: set bpc for DP transcoder Jesse Barnes
2011-04-19 19:12 ` [PATCH 4/7] drm/i915: split out Ironlake pipe bpp picking code Jesse Barnes
2011-05-10 21:23 ` Keith Packard [this message]
2011-05-11 17:23 ` Jesse Barnes
2011-04-19 19:12 ` [PATCH 5/7] drm/i915: split out plane update code Jesse Barnes
2011-04-19 19:12 ` [PATCH 6/7] drm/i915: use pipe bpp in DP link bandwidth calculations Jesse Barnes
2011-04-19 19:16 ` Jesse Barnes
2011-04-19 19:12 ` [PATCH 7/7] drm/i915: use pipe bpp when setting HDMI bpc Jesse Barnes
2011-04-19 19:50 ` [ANCIENT PATCH] Enable 30-bit depth Andy Lutomirski
2011-04-19 19:56 ` Jesse Barnes
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=yun39kmb67t.fsf@aiko.keithp.com \
--to=keithp@keithp.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.org \
/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).