[Bug 93361] 12bpc hdmi causes wrong real refresh rate (swapbuffers return time)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93361

--- Comment #17 from Kevin Mitchell <kevmitch at gmail.com> ---
(In reply to Tomeu Vizoso from comment #14)
> (In reply to Kevin Mitchell from comment #0)
> > Created attachment 120472 [details]
> > Samsung un40eh5000 edid reported by xrandr --prop
> > 
> > I have a Samsung un40eh5000 tv that I connect to my Ivy Bridge Lenovo T530
> > laptop via mini display-port to hdmi. I have attached the raw and decoded
> > EDID. 
> > 
> > As of 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67, it seems 12bpc gets enabled
> > on this setup (though I can't imagine that my machine or my TV actually
> > support that in real life).
> 
> Why do you think that? The EDID says that DC_36bit is supported, and from
> sandy bridge up, 12bpc is supported by the graphics hw.

Well I assume that if my TV could do deep colour, it would have been advertised
as such and cost a lot more money. But to confirm, I see bands when I use mpv
on the drm-intel git master kernel to play 10-bit test clips like

http://www.avsforum.com/forum/139-display-calibration/2269338-10-bit-gradient-test-patterns.html

Maybe the TVs DSP can take deep color as input, but it only displays as 8-bit
on the panel. Do I need special xorg settings / patches to get this to work
correctly?

> > Unfortunately, this seems to change the
> > effective refresh rate as measured between returns from opengl swapbuffers
> > calls for example in glxgears.
> > 
> >        | glxgears fps   |
> >        +----------------+
> > xrandr | before | after |
> > -------+--------+-------+
> > 23.98  | 24.00  | 23.85 |
> > 24.00  | 24.00  | 24.13 |
> > 29.97  | 30.00  | 29.81 |
> > 30.00  | 30.00  | 30.17 |
> > 59.94  | 60.00  | 60.12 |
> > 60.00  | 60.00  | 60.12 |
> > 
> > This is problematic for displaying video at native frame rates. For example
> > when the actual refresh rate of 24.00 hz could be achieved, 23.98fps video
> > would only have to repeat a frame every 50 seconds. Now it must either drop
> > or repeat one every 7 seconds which is much more noticeable.
> 
> So you want a mechanism for disabling deep color even if it could be used?

It would be great if this was just enabled where it was supported and there
were no problems, but if it has the possibility to cause regressions like this,
that might be an idea. That is effectively what I am doing now by reverting
this change in my kernel.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170218/2c319c59/attachment.html>