On Tue, Jan 10, 2017 at 05:01:08PM +0000, Jose Abreu wrote: > Hi Ville, > > > [snip] > > >> Are you going to update all the userspace clients? Exposing HDMI 2.0 > >> modes only for your favorite client doesn't sound like a good plan to > >> me. > >> > >> If we simply compute from a specific modeline whether it needs to be > >> transmitted as 4:2:0, I suppose we could simply look for a matching > >> mode in the 4:2:0 mode. But that would mean that only the exact modes > >> listed by the EDID will work, and others might not. > > OK, so the 4:2:0 support is apparently listed only for specific VICs. > > Hmm, the spec is not very clear. It lists video timings which may > be used with YCbCr 4:2:0 but does not explicitly say that only > these timings can be used. Anyway, I checked with a colleague who > has direct access to HDMI Forum and indeed only VIC 96, 97, 101, > 102, 106 and 107 can be used with 4:2:0, so you are correct. He > said that the initial intention of this pixel encoding was to > give 60Hz refresh rate in 4k to users who had limited > performance, so it was only intended for higher resolutions. > > > Hence we will need to just go through those lists to see if we can > > (or in fact must) use 4:2:0 for a specific user specified mode. > > We don't have yet support for these VICs, so this will have to > wait :( > > > > > I would say the only slight question mark at this point is whether we > > should favor 4:4:4 at lower bpc or 4:2:0 at higher bpc if we can choose > > between the two. My first instinct is to favor the 4:4:4 modes for now. > > We could add some knobs later to let the user make that choice. > > I agree that 4:4:4 should be preferred. > > [snip] > > >>> Ok. But note that there is no nice way to figure this out. For > >>> example, for a graphics card it all depends (apart from the > >>> graphics HW) on the PCIe bus. If the bus is not free for enough > >>> data rate then user can reach bottlenecks and not output at best > >>> performance. If we gave user the ability to switch from, for > >>> example, RGB to YCbCr 4:2:0 this bottleneck could be eliminated. > >> Userspace won't know anything about such bottlenecks. The kernel > >> can know it and hence should automagically drop into 4:2:0 mode > >> if necessary. > >> > >>> Unless of course we always prefer YCbCr 4:2:0, when possible. I > >>> did this internally for bridge driver dw-hdmi. We always prefer > >>> YCbCr over RGB when they are available. It is user transparent as > >>> the controller does the necessary color space conversion, though, > >>> not ideal in my opinion. > >> My idea was that we'd have a property for the output colorspace and > >> would perhaps default to YCbCr for the CEA modes (as per CEA-861). > >> Though I'm sure some people would cry about that behaviour as well. > >> But for the cases where there is no choice but to use a specific > >> output colorspace, the kernel should just do it automagically IMO. No > >> point in manking life diffcult for userspace. > > But we already have color_formats field in drm_display_info > struct, right? Shouldn't we instead create for example a helper > which returns the best output colorspace? According to what you > said it would be something like: > > if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > return YCBCR444; > else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > return YCBCR422; > else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR420 > && vic_is_420) > return YCBCR420; > else > return RGB444; /* Mandatory by spec */ Perhaps. But it would have to be more involved than that since there might limitations on eg. the max TMDS clock imposed by the source or cable/dongle which presumably might require that we pick 4:2:0 over 4:4:4. It would also need to account which formats are actually supported by the source. I guess for bpc it would be enough to just consider 8bpc in such a function, and then the driver can bump it up afterwards if possible. As for the RGB vs. YCbCr question, I guess we should just prefer RGB444 for now. And fall back to YCbCr 4:2:2 or 4:2:0 if necessary. And that leaves YCbCr 4:4:4 unsed since it has the same requirements as RGB 4:4:4 and thus doesn't provide any benefit as such. We could later add a property to let the user choose between RGB vs. YCbCr more explicitly. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
