search for: 8bpc

This just limits the BPC for MST connectors to a maximum of 8 from nv50_mstc_get_modes(), instead of doing so during nv50_msto_atomic_check(). This doesn't introduce any functional changes yet (other then userspace now lying about the max bpc, but we can't support that yet anyway so meh). But, we'll need this in a moment so that we can share mode validation between SST and MST which

...r 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/9b8776f58448b57456...

...#39;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 --------------------------...

...R 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...

...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 &g...

.../mesa code-base? The current patches in mesa for XBGR also lack enablement pieces for EGL, Wayland and X11 compositing, but that's a different problem. -mario > 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 &g...

...ne weird thing i still observed though is that in depth 30 xbgr2101010 >> scanout mode nouveau used dithering when i tried to output a linear >> intensity ramp, despite me disabling dithering via the xrandr property. But >> that is an unrelated problem. > > It's sending 8bpc data out to the screen, unless you're using a DP > monitor (and probably would need a Kepler GPU for that anyways). I think a long time ago i tested 10 bpc output over VGA with the proprietary driver on GeForce 8800, and the current readme for the NVidia blob says it can do 10 bpc over VG...

On 03/01/2018 07:21 PM, nouveau-request at lists.freedesktop.org wrote: > > Message: 1 > Date: Thu, 1 Mar 2018 08:15:55 -0500 > From: Ilia Mirkin <imirkin at alum.mit.edu> > To: Mario Kleiner <mario.kleiner.de at gmail.com> > Cc: nouveau <nouveau at lists.freedesktop.org> > Subject: Re: [Nouveau] [PATCH] Fix colormap handling at screen depth > 30. >

...depth 30. > > One weird thing i still observed though is that in depth 30 xbgr2101010 > scanout mode nouveau used dithering when i tried to output a linear > intensity ramp, despite me disabling dithering via the xrandr property. But > that is an unrelated problem. It's sending 8bpc data out to the screen, unless you're using a DP monitor (and probably would need a Kepler GPU for that anyways). Although setting dither to off should still kill the dithering... probably some experimentation required. I'm pretty sure I could tell that it was dithering for me on Kepler. W...

...'ll never be able to set and therefore want to prune. So, even if we're not using 6 in the majority of situations, I'm fairly confident it's the right value here. It's also what i915 does as well (and they previously had to fix a bug that was the result of assuming a minimum of 8bpc instead of 6). > > -ilia > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat

...o the > server-1.19 branch as well. Hrmph. That means we should try to adjust the gamma_set helper to do the sampling when receiving a 1024-sized LUT, if people will use older X servers (seems likely). Should hopefully be straightforward, to handle just that one case. >> It's sending 8bpc data out to the screen, unless you're using a DP >> monitor (and probably would need a Kepler GPU for that anyways). > > > I think a long time ago i tested 10 bpc output over VGA with the proprietary > driver on GeForce 8800, and the current readme for the NVidia blob says it...

That's OK - nouveau doesn't let you pick bit depth either (yet). It's all 8bpc - higher bpc mode support will come ... eventually. On Tue, Aug 6, 2019 at 5:25 PM James <bjlockie at lockie.ca> wrote: > > I think I may have updated the tv firmware between when it worked and > when it didn't. > I wonder it it has to do with bit depth. > I use lubuntu an...

https://bugs.freedesktop.org/show_bug.cgi?id=92297 Bug ID: 92297 Summary: dithering detected incorrectly Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Driver/nouveau Assignee: nouveau at

...> set and therefore want to prune. > > So, even if we're not using 6 in the majority of situations, I'm fairly > confident it's the right value here. It's also what i915 does as well (and they > previously had to fix a bug that was the result of assuming a minimum of 8bpc > instead of 6). Here's the situation I'm trying to avoid: 1. Mode is considered "OK" from a bandwidth perspective @6bpc 2. Modesetting logic never tries 6bpc and the modeset fails As long as the two bits of logic agree on what is settable, I'm happy. Cheers, -ilia

I think I may have updated the tv firmware between when it worked and when it didn't. I wonder it it has to do with bit depth. I use lubuntu and it doesn't let me pick the bit depth so I don't know what it using.

On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > Hi, > > > Hmm. Maybe it's still possible to salvage something by redefining the > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > might still result in something usable. > > Also at least for the virtual machine use case this doesn't buy us much. > The

On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > Hi, > > > Hmm. Maybe it's still possible to salvage something by redefining the > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > might still result in something usable. > > Also at least for the virtual machine use case this doesn't buy us much. > The

...ly that the gamma table updates no-op, so the server runs with an identity gamma table setup at startup. Not perfect, but also not that bad, given that probably most people run their setups with a gamma of 1.0 anyway. At default depth 24 stuff works as usual. > >>> It's sending 8bpc data out to the screen, unless you're using a DP >>> monitor (and probably would need a Kepler GPU for that anyways). >> >> >> I think a long time ago i tested 10 bpc output over VGA with the proprietary >> driver on GeForce 8800, and the current readme for the...

On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? I don't think that display_info.bpc actually implies a minimum bpc, only a maximum bpc iirc (Ville would know the answer to this one). The other thing to note here is that we want to assume

...ng a LUT. Finally, experimental evidence suggests you can't mix sizes for degamma and gamma. Disallow this as well. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Note that all the gv100+ changes are purely speculative. Tested on a GK208 with 8- and 10-bpc formats (but still 8bpc output). This is on top of the patches which I've sent in the past. You'll end up with some conflicts, I suspect, but I can't rebase easily on your changes since they're not in a linux tree. drivers/gpu/drm/nouveau/dispnv50/base907c.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/c...