search for: 10bpc

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

...sa 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/comm...

...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/9b8776f58448b5745675c3...

...back into the server/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/9b8776f58448b5745675c3...

...your logs you have [ 289.906506] nouveau 0000:01:00.0: disp: outp 00:0006:0344: data 281925 KB/s link 0 KB/s mst 0->0 [ 289.906511] nouveau 0000:01:00.0: disp: outp 00:0006:0344: link requirements changed Where completely coincidentally, 75180 * 30 / 8 = 281925 So it's clearly wanting 10bpc. And based on my reading of the logic in drm_edid.c, your display_info.bpc with that edid would == 0. However in nouveau_connector_detect_depth() we would then force it to 6. And in nv50_mstc_get_modes it'd become 8. So this is still a bit unclear to me. If you're up to it, do some tracing...

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

...> which is what causes us to even try 540MB/s link training. However > > with this fix applied, it'll just give up faster. I'm told eDP is > > generally a single lane, and you're trying to get more than 270MB/s. > > So ... the question is ... why is it trying to do 10bpc. One likely > > reason is that the display_info.bpc == 0 for some reason (and we, > > rather questionably, default to 10bpc for bandwidth determination). > > There's no concrete theory as to what that reason might be, but it > > would explain what's going on. > &g...

...7d2b0c3b0731433d60a494c78ab58cb216 which is what causes us to even try 540MB/s link training. However with this fix applied, it'll just give up faster. I'm told eDP is generally a single lane, and you're trying to get more than 270MB/s. So ... the question is ... why is it trying to do 10bpc. One likely reason is that the display_info.bpc == 0 for some reason (and we, rather questionably, default to 10bpc for bandwidth determination). There's no concrete theory as to what that reason might be, but it would explain what's going on. After resuming into a bad state, can you grab...

...pointer. Iow. dead code that can be removed. I'll send some follow up patch, once this one is in. We have similar dead code in intel-ddx and modesetting-ddx which only serves to confuse the reader. > note that the kernel currently only exposes a 256-sized LUT to > userspace, even for 10bpc modes. > Yes, but that doesn't matter. In xbgr2101010 mode, the gpu seems to properly interpolate between the 256 (or 257) hw lut slots, as far as my measurments go. The X-Server maintains separate color palettes, per-x-screen xf86vidmode gamma lut's and per-crtc RandR gamma lut'...

...moved. I'll >> send some follow up patch, once this one is in. We have similar dead code in >> intel-ddx and modesetting-ddx which only serves to confuse the reader. >> >>> note that the kernel currently only exposes a 256-sized LUT to >>> userspace, even for 10bpc modes. >>> >> >> Yes, but that doesn't matter. In xbgr2101010 mode, the gpu seems to properly >> interpolate between the 256 (or 257) hw lut slots, as far as my measurments >> go. The X-Server maintains separate color palettes, per-x-screen xf86vidmode >>...

...code that can be removed. I'll > send some follow up patch, once this one is in. We have similar dead code in > intel-ddx and modesetting-ddx which only serves to confuse the reader. > >> note that the kernel currently only exposes a 256-sized LUT to >> userspace, even for 10bpc modes. >> > > Yes, but that doesn't matter. In xbgr2101010 mode, the gpu seems to properly > interpolate between the 256 (or 257) hw lut slots, as far as my measurments > go. The X-Server maintains separate color palettes, per-x-screen xf86vidmode > gamma lut's and per-...

...what causes us to even try 540MB/s link training. However > > > with this fix applied, it'll just give up faster. I'm told eDP is > > > generally a single lane, and you're trying to get more than 270MB/s. > > > So ... the question is ... why is it trying to do 10bpc. One likely > > > reason is that the display_info.bpc == 0 for some reason (and we, > > > rather questionably, default to 10bpc for bandwidth determination). > > > There's no concrete theory as to what that reason might be, but it > > > would explain what'...

...t; 8cb216 > > which is what causes us to even try 540MB/s link training. However > with this fix applied, it'll just give up faster. I'm told eDP is > generally a single lane, and you're trying to get more than 270MB/s. > So ... the question is ... why is it trying to do 10bpc. One likely > reason is that the display_info.bpc == 0 for some reason (and we, > rather questionably, default to 10bpc for bandwidth determination). > There's no concrete theory as to what that reason might be, but it > would explain what's going on. > > After resuming i...

The various clut handling functions like a setup consistent with the x-screen color depth. Otherwise we observe improper sampling in the gamma tables at depth 30. Tested at depths 16, 24 and 30 and tested at depths 24 and 30 that xgamma and gamma table animations work, and with measurement equipment to make sure identity gamma ramps actually are identity mappings at the output. Signed-off-by:

...er 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 VGA and DisplayPort, but only dithering over DVI and > HDMI. I think that 10bpc HDMI support came with HDMI 1.3. Older devices (esp Tesla era) won't support that. Intuitively seems like it should Just Work (tm) over VGA. Not sure which DP version supported 10bpc+. > I think i read somewhere that at least Pascal could do some deep color > output over HDMI as well, wh...

...;s or future gallium drivers it is not so clear if the > right thing will happen. E.g., freedreno seems to support both BGR and RGB > 10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by > luck the right thing would happen? FWIW freedreno does not presently support 10bpc scanout. > > Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to > DRIconfigs, so we could probably implement dri_loader_get_cap(screen, > DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders. > > But for GLX it is not so easy or quick. I looked if i c...

...rivers it is not so clear if the >> right thing will happen. E.g., freedreno seems to support both BGR and RGB >> 10 bit formats as PIPE_BIND_DISPLAY_TARGET afaics, so i don't know if by >> luck the right thing would happen? > > FWIW freedreno does not presently support 10bpc scanout. > >> >> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs to >> DRIconfigs, so we could probably implement dri_loader_get_cap(screen, >> DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders. >> >> But for GLX it is not so e...

https://bugs.freedesktop.org/show_bug.cgi?id=111841 Bug ID: 111841 Summary: Setting gamma or color temperature on GK104 causes horizontal artifacts / flickering Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority:

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