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. -- Ville Syrjälä Intel OTC
On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä <ville.syrjala at 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-"/>
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 at 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