From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: nouveau <nouveau@lists.freedesktop.org>,
Ben Skeggs <bskeggs@redhat.com>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: nouveau 30bpp / deep color status
Date: Fri, 9 Feb 2018 16:32:36 +0200 [thread overview]
Message-ID: <20180209143236.GG5453@intel.com> (raw)
In-Reply-To: <CAKb7UvgfeRna6MDq9StaFWR8j4QTy_9Dm+3hrB9hgzZZcg-9PA@mail.gmail.com>
On Thu, Feb 08, 2018 at 07:34:11PM -0500, Ilia Mirkin wrote:
> On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
> >> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> >> > In case anyone's curious about 30bpp framebuffer support, here's the
> >> > current status:
> >> >
> >> > Kernel:
> >> >
> >> > Ben and I have switched the code to using a 256-based LUT for Kepler+,
> >> > and I've also written a patch to cause the addfb ioctl to use the
> >> > proper format. You can pick this up at:
> >> >
> >> > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
> >> > https://patchwork.freedesktop.org/patch/202322/
> >> >
> >> > With these two, you should be able to use "X -depth 30" again on any
> >> > G80+ GPU to bring up a screen (as you could in kernel 4.9 and
> >> > earlier). However this still has some deficiencies, some of which I've
> >> > addressed:
> >> >
> >> > xf86-video-nouveau:
> >> >
> >> > DRI3 was broken, and Xv was broken. Patches available at:
> >> >
> >> > https://github.com/imirkin/xf86-video-nouveau/commits/master
> >> >
> >> > mesa:
> >> >
> >> > The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
> >> > nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
> >> > Mesa was only enabled for XRGB, so I've piped XBGR through all the
> >> > same places:
> >> >
> >> > https://github.com/imirkin/mesa/commits/30bpp
> >> >
> >> > libdrm:
> >> >
> >> > For testing, I added a modetest gradient pattern split horizontally.
> >> > Top half is 10bpc, bottom half is 8bpc. This is useful for seeing
> >> > whether you're really getting 10bpc, or if things are getting
> >> > truncated along the way. Definitely hacky, but ... wasn't intending on
> >> > upstreaming it anyways:
> >> >
> >> > https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441
> >> >
> >> > -------------------------------------
> >> >
> >> > Results with the patches (tested on a GK208B and a "deep color" TV over HDMI):
> >> > - modetest with a 10bpc gradient shows up smoother than an 8bpc
> >> > gradient. However it's still dithered to 8bpc, not "real" 10bpc.
> >> > - things generally work in X -- dri2 and dri3, xv, and obviously
> >> > regular X rendering / acceleration
> >> > - lots of X software can't handle 30bpp modes (mplayer hates it for
> >> > xv and x11 rendering, aterm bails on shading the root pixmap, probably
> >> > others)
> >> >
> >> > I'm also told that with DP, it should actually send the higher-bpc
> >> > data over the wire. With HDMI, we're still stuck at 24bpp for now
> >> > (although the hardware can do 36bpp as well). This is why my gradient
> >> > result above was still dithered.
> >> >
> >> > Things to do - mostly nouveau specific, but probably some general
> >> > infra needed too:
> >> > - Figure out how to properly expose the 1024-sized LUT
> >>
> >> We have the properties in the kernel. Not sure if x11 could expose it
> >> to clients somehow, or would we just have to interpolate the missing
> >> bits in the ddx?
> >
> > Oh, and I think we're going to have to come up with a fancier uapi for
> > this stuff because in the future the input points may not be evenly
> > spaced (for HDR stuff). Also the hardware may provide various different
> > modes for the gamma LUTs with different tradeoffs. So we may even want
> > to somehow try to enumerate the different modes and let userspace pick
> > the mode that best suits its needs.
>
> That's already the case -- NVIDIA actually has like 5 different LUT
> modes on recent chips.
>
> https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L25
>
> <value value="0x4" name="INTERPOLATE_1025_UNITY_RANGE" variants="GF119-"/>
> <value value="0x5" name="INTERPOLATE_1025_XRBIAS_RANGE" variants="GF119-"/>
> <value value="0x6" name="INTERPOLATE_1025_XVYCC_RANGE" variants="GF119-"/>
> <value value="0x7" name="INTERPOLATE_257_UNITY_RANGE" variants="GF119-"/>
> <value value="0x8" name="INTERPOLATE_257_LEGACY_RANGE" variants="GF119-"/>
Yeah, we also have several LUT modes on intel hw. IIRC ~4 on current hw.
The main questions are whether all of them are actually useful for userspace,
and how we can expose the relevant details to userspace in a succinct and hw
independent way.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-02-09 14:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-04 23:50 nouveau 30bpp / deep color status Ilia Mirkin
2018-02-07 16:28 ` Ville Syrjälä
2018-02-07 17:01 ` Ville Syrjälä
2018-02-09 0:34 ` Ilia Mirkin
2018-02-09 14:32 ` Ville Syrjälä [this message]
2018-03-05 7:25 ` Mario Kleiner
[not found] ` <af14dbae-fe25-6d5d-fe25-e955ddc825fa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-03-05 12:40 ` Ilia Mirkin
[not found] ` <CAKb7UvipOtS48kQocRU6kpzxN5MSb7zUDBQYkc4Oo4E-oqmcTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-03-08 16:57 ` Mario Kleiner
[not found] ` <3caddc39-7962-060b-895a-f2456588d59f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-03-08 17:08 ` Ilia Mirkin
2018-03-08 17:36 ` Daniel Stone
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=20180209143236.GG5453@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=imirkin@alum.mit.edu \
--cc=nouveau@lists.freedesktop.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