From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB Date: Tue, 10 Jan 2017 17:52:44 +0200 Message-ID: <20170110155244.GD31595@intel.com> References: <20170104132225.GE31595@intel.com> <8528542b-27fb-096f-8e22-af1fb7d5f0a1@synopsys.com> <20170104163607.GK31595@intel.com> <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com> <20170105114640.GO31595@intel.com> <2700086a-00b9-e8c7-f502-df132fbbe2dc@synopsys.com> <20170110111601.GY31595@intel.com> <4233e877-8ca6-b3d4-e986-a2bf3e17f1e1@synopsys.com> <20170110153315.GC31595@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4C4D26E323 for ; Tue, 10 Jan 2017 15:52:48 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20170110153315.GC31595@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jose Abreu Cc: Daniel Vetter , Carlos Palminha , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCBKYW4gMTAsIDIwMTcgYXQgMDU6MzM6MTVQTSArMDIwMCwgVmlsbGUgU3lyasOkbMOk IHdyb3RlOgo+IE9uIFR1ZSwgSmFuIDEwLCAyMDE3IGF0IDEyOjI2OjUzUE0gKzAwMDAsIEpvc2Ug QWJyZXUgd3JvdGU6Cj4gPiBIaSBWaWxsZSwKPiA+IAo+ID4gCj4gPiBPbiAxMC0wMS0yMDE3IDEx OjE2LCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPiA+IE9uIFRodSwgSmFuIDA1LCAyMDE3IGF0 IDAyOjQ2OjA2UE0gKzAwMDAsIEpvc2UgQWJyZXUgd3JvdGU6Cj4gPiA+Pgo+ID4gCj4gPiBbc25p cF0KPiA+IAo+ID4gPj4gVGhlIHBpeGVsIGNsb2NrIHJhdGUgaXMgaGFsZiBvZiB0aGUgVE1EUyBj aGFyYWN0ZXIgcmF0ZSBpbiA0OjI6MAo+ID4gPj4gKGluIDI0IGJpdCksIGJ1dCBmb3IgZXhhbXBs ZSBpbiBkZWVwIGNvbG9yIDQ4IGJpdCBpdCB3aWxsIGJlIHRoZQo+ID4gPj4gc2FtZSByYXRlLiBU aGVyZSBpcyBhbHNvIGEgcmVkdWN0aW9uIHRvIGhhbGYgb2YgaHRvdGFsLCBoYWN0aXZlLAo+ID4g Pj4gaGJsYW5rLCBoZnJvbnQsIGhzeW5jIGFuZCBoYmFjayBidXQgSSBkb24ndCB0aGluayBpdCdz IGEgZ29vZAo+ID4gPj4gc29sdXRpb24gdG8gZ3VpZGUgdXMgZnJvbSB0aGVyZS4KPiA+ID4gSSB3 YXMgYXNraW5nIGlmIHdlIGNhbiBsb29rIGF0IGEgc3BlY2lmaWMgbW9kZWxpbmUgYW5kIHdoZXRo ZXIgd2UKPiA+ID4gY2FuIHRlbGwgZnJvbSB0aGF0IGlmIHdlIHdvdWxkIG5lZWQgdG8gb3V0cHV0 IGl0IGFzIDQ6MjowLgo+ID4gCj4gPiBIbW0sIGFjY29yZGluZyB0byBIRE1JIDIuMCBzcGVjIHRo ZXJlIGFyZSBubyA0OjI6MCBvbmx5IG1vZGVzIGFuZAo+ID4gdGhlIG9ubHkgd2F5IHRvIGZpZ3Vy ZSBvdXQgaWYgdGhlIG1vZGUgaXMgNDoyOjAgb25seSAob3IgYWJsZSkgaXMKPiA+IHRvIHBhcnNl IHRoZSBWQ0IgYW5kIFZCRCBibG9ja3MgZnJvbSBFRElELiBUaGUgY2xvY2sgaXMgaGFsZiByYXRl Cj4gPiBidXQgdGhpcyBpcyB0aGUgc291cmNlIHRoYXQgaGFzIHRvIGZpZ3VyZSBpdCBvdXQuIFRo ZSBtb2RlIGlzCj4gPiBzdGlsbCBwYXNzZWQgaW4gYSByZWd1bGFyIHdheSAoQnkgVklDLCBieSB0 aW1pbmcsIC4uLikuCj4gPiAKPiA+ID4KPiA+ID4+IFdoeSBkb2VzIGl0IGZlZWwgd3JvbmcgdG8g eW91Cj4gPiA+PiBleHBhbmRpbmcgdGhlIHVhcGk/Cj4gPiA+IEJlY2F1c2UgaXQgcmVxdWlyZXMg Y2hhbmdpbmcgZXZlcnkgc2luZ2xlIHVzZXJzcGFjZSBrbXMgY2xpZW50LiBBbmQKPiA+ID4gaXQn cyBub3Qgc29tZXRoaW5nIHVzZXJzcGFjZSBzaG91bGQgaGF2ZSB0byB3b3JyeSBhYm91dC4KPiA+ IAo+ID4gSSBhZ3JlZSBidXQsIGFzIERhbmllbCBzYWlkIFsxXSwgd2UgY291bGQgbWFrZSB0aGVz ZSBuZXcgSERNSSAyLjAKPiA+IGZlYXR1cmVzIG9wdGlvbmFsIGFuZCBvbmx5IHBhc3MgdGhlbSB0 byB1c2Vyc3BhY2UgaWYgY2xpZW50IGFza2VkCj4gPiBmb3IgdGhlbS4gV2hhdCBkbyB5b3UgdGhp bms/Cj4gCj4gQXJlIHlvdSBnb2luZyB0byB1cGRhdGUgYWxsIHRoZSB1c2Vyc3BhY2UgY2xpZW50 cz8gRXhwb3NpbmcgSERNSSAyLjAKPiBtb2RlcyBvbmx5IGZvciB5b3VyIGZhdm9yaXRlIGNsaWVu dCBkb2Vzbid0IHNvdW5kIGxpa2UgYSBnb29kIHBsYW4gdG8KPiBtZS4KPiAKPiBJZiB3ZSBzaW1w bHkgY29tcHV0ZSBmcm9tIGEgc3BlY2lmaWMgbW9kZWxpbmUgd2hldGhlciBpdCBuZWVkcyB0byBi ZQo+IHRyYW5zbWl0dGVkIGFzIDQ6MjowLCBJIHN1cHBvc2Ugd2UgY291bGQgc2ltcGx5IGxvb2sg Zm9yIGEgbWF0Y2hpbmcKPiBtb2RlIGluIHRoZSA0OjI6MCBtb2RlLiBCdXQgdGhhdCB3b3VsZCBt ZWFuIHRoYXQgb25seSB0aGUgZXhhY3QgbW9kZXMKPiBsaXN0ZWQgYnkgdGhlIEVESUQgd2lsbCB3 b3JrLCBhbmQgb3RoZXJzIG1pZ2h0IG5vdC4KCk9LLCBzbyB0aGUgNDoyOjAgc3VwcG9ydCBpcyBh cHBhcmVudGx5IGxpc3RlZCBvbmx5IGZvciBzcGVjaWZpYyBWSUNzLgpIZW5jZSB3ZSB3aWxsIG5l ZWQgdG8ganVzdCBnbyB0aHJvdWdoIHRob3NlIGxpc3RzIHRvIHNlZSBpZiB3ZSBjYW4KKG9yIGlu IGZhY3QgbXVzdCkgdXNlIDQ6MjowIGZvciBhIHNwZWNpZmljIHVzZXIgc3BlY2lmaWVkIG1vZGUu CgpJIHdvdWxkIHNheSB0aGUgb25seSBzbGlnaHQgcXVlc3Rpb24gbWFyayBhdCB0aGlzIHBvaW50 IGlzIHdoZXRoZXIgd2UKc2hvdWxkIGZhdm9yIDQ6NDo0IGF0IGxvd2VyIGJwYyBvciA0OjI6MCBh dCBoaWdoZXIgYnBjIGlmIHdlIGNhbiBjaG9vc2UKYmV0d2VlbiB0aGUgdHdvLiBNeSBmaXJzdCBp bnN0aW5jdCBpcyB0byBmYXZvciB0aGUgNDo0OjQgbW9kZXMgZm9yIG5vdy4KV2UgY291bGQgYWRk IHNvbWUga25vYnMgbGF0ZXIgdG8gbGV0IHRoZSB1c2VyIG1ha2UgdGhhdCBjaG9pY2UuCgo+IAo+ ID4gCj4gPiBbMV0KPiA+IGh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL2FyY2hpdmVzL2Ry aS1kZXZlbC8yMDE3LUphbnVhcnkvMTI4NjgzLmh0bWwKPiA+IAo+ID4gPgo+ID4gPj4gSSB0aGlu ayBpdHMgaW1wb3J0YW50IHRvIHNheSB0aGF0IHRoZSBjaG9zZW4gY29sb3JzcGFjZSBjYW4KPiA+ ID4+IGltcHJvdmUgcGVyZm9ybWFuY2UgaW4gc3lzdGVtczogZm9yIGV4YW1wbGUsIGFzIEkgc2Fp ZCwgNDoyOjAKPiA+ID4+IDI0LWJpdCB1c2VzIGhhbGYgdGhlIHJhdGUgdGhhdCBSR0IgMjQtYml0 IHVzZXMgc28gd2UgaGF2ZSBsZXNzCj4gPiA+PiB0cmFmaWMgaW4gdGhlIGJ1cy4gSSBhbSByZWNl bnRseSB3b3JraW5nIHdpdGggYSBGUEdBIGNvbm5lY3RlZAo+ID4gPj4gdHJvdWdoIHBjaWUgYW5k IEkgY2FuIGRlZmluaXRlbHkgc2F5IHRoYXQgdGhpcyBpcyB0cnVlLiBCdXQsIGFzCj4gPiA+PiBl eHBlY3RlZCwgbGVzcyB0cmFmZmljIG1lYW5zIGxlc3MgcXVhbGl0eSBpbiBmaW5hbCBpbWFnZSBz byBpdHMKPiA+ID4+IG5vdCBhIG1hdHRlciBvZiBsZXR0aW5nIGtlcm5lbCBkZWNpZGUsIEkgdGhp bmsgaXRzIGEgbWF0dGVyIG9mCj4gPiA+PiB1c2VyIGNob29zaW5nIGJldHdlZW4gcGVyZm9ybWFu Y2UgdnMuIHF1YWxpdHkuCj4gPiA+IEltYWdlIHF1YWxpdHkgY29udHJvbCBmb3IgdXNlcnNwYWNl IGlzIGEgbXVjaCBiaWdnZXIgdG9waWMuIEFuZAo+ID4gPiBzb21ldGhpbmcgd2UgaGF2ZSBubyBy ZWFsIHByZWNlZGVudCBmb3IgYXQgdGhlIG1vbWVudCAoYXBhcnQgZnJvbSAKPiA+ID4gdXNlciBj aG9vc2luZyBhIGRpZmZlcmVudCBmYiBwaXhlbCBmb3JtYXQpLgo+ID4gPgo+ID4gPiBUaGUgcGVy Zm9ybWFuY2UgYXJ1bWVudCBpcyB2ZXJ5IGhhcmR3YXJlIGRlcGVuZGVudCwgYW5kIG5vdCByZWFs bHkKPiA+ID4gYWxsIHRoYXQgcmVsZXZhbnQgSU1PLiBJZiB0aGUgdXNlciB3YW50cyB0aGUgYmln IG1vZGUgdGhleSBlaXRoZXIKPiA+ID4gZ2V0IGl0IG9yIG5vdCBkZXBlbmRpbmcgb24gd2hldGhl ciB0aGUgc3lzdGVtIGNhbiBkZWxpdmVyLgo+ID4gPgo+ID4gCj4gPiBPay4gQnV0IG5vdGUgdGhh dCB0aGVyZSBpcyBubyBuaWNlIHdheSB0byBmaWd1cmUgdGhpcyBvdXQuIEZvcgo+ID4gZXhhbXBs ZSwgZm9yIGEgZ3JhcGhpY3MgY2FyZCBpdCBhbGwgZGVwZW5kcyAoYXBhcnQgZnJvbSB0aGUKPiA+ IGdyYXBoaWNzIEhXKSBvbiB0aGUgUENJZSBidXMuIElmIHRoZSBidXMgaXMgbm90IGZyZWUgZm9y IGVub3VnaAo+ID4gZGF0YSByYXRlIHRoZW4gdXNlciBjYW4gcmVhY2ggYm90dGxlbmVja3MgYW5k IG5vdCBvdXRwdXQgYXQgYmVzdAo+ID4gcGVyZm9ybWFuY2UuIElmIHdlIGdhdmUgdXNlciB0aGUg YWJpbGl0eSB0byBzd2l0Y2ggZnJvbSwgZm9yCj4gPiBleGFtcGxlLCBSR0IgdG8gWUNiQ3IgNDoy OjAgdGhpcyBib3R0bGVuZWNrIGNvdWxkIGJlIGVsaW1pbmF0ZWQuCj4gCj4gVXNlcnNwYWNlIHdv bid0IGtub3cgYW55dGhpbmcgYWJvdXQgc3VjaCBib3R0bGVuZWNrcy4gVGhlIGtlcm5lbAo+IGNh biBrbm93IGl0IGFuZCBoZW5jZSBzaG91bGQgYXV0b21hZ2ljYWxseSBkcm9wIGludG8gNDoyOjAg bW9kZQo+IGlmIG5lY2Vzc2FyeS4KPiAKPiA+IFVubGVzcyBvZiBjb3Vyc2Ugd2UgYWx3YXlzIHBy ZWZlciBZQ2JDciA0OjI6MCwgd2hlbiBwb3NzaWJsZS4gSQo+ID4gZGlkIHRoaXMgaW50ZXJuYWxs eSBmb3IgYnJpZGdlIGRyaXZlciBkdy1oZG1pLiBXZSBhbHdheXMgcHJlZmVyCj4gPiBZQ2JDciBv dmVyIFJHQiB3aGVuIHRoZXkgYXJlIGF2YWlsYWJsZS4gSXQgaXMgdXNlciB0cmFuc3BhcmVudCBh cwo+ID4gdGhlIGNvbnRyb2xsZXIgZG9lcyB0aGUgbmVjZXNzYXJ5IGNvbG9yIHNwYWNlIGNvbnZl cnNpb24sIHRob3VnaCwKPiA+IG5vdCBpZGVhbCBpbiBteSBvcGluaW9uLgo+IAo+IE15IGlkZWEg d2FzIHRoYXQgd2UnZCBoYXZlIGEgcHJvcGVydHkgZm9yIHRoZSBvdXRwdXQgY29sb3JzcGFjZSBh bmQKPiB3b3VsZCBwZXJoYXBzIGRlZmF1bHQgdG8gWUNiQ3IgZm9yIHRoZSBDRUEgbW9kZXMgKGFz IHBlciBDRUEtODYxKS4KPiBUaG91Z2ggSSdtIHN1cmUgc29tZSBwZW9wbGUgd291bGQgY3J5IGFi b3V0IHRoYXQgYmVoYXZpb3VyIGFzIHdlbGwuCj4gQnV0IGZvciB0aGUgY2FzZXMgd2hlcmUgdGhl cmUgaXMgbm8gY2hvaWNlIGJ1dCB0byB1c2UgYSBzcGVjaWZpYwo+IG91dHB1dCBjb2xvcnNwYWNl LCB0aGUga2VybmVsIHNob3VsZCBqdXN0IGRvIGl0IGF1dG9tYWdpY2FsbHkgSU1PLiBObwo+IHBv aW50IGluIG1hbmtpbmcgbGlmZSBkaWZmY3VsdCBmb3IgdXNlcnNwYWNlLgo+IAo+IC0tIAo+IFZp bGxlIFN5cmrDpGzDpAo+IEludGVsIE9UQwoKLS0gClZpbGxlIFN5cmrDpGzDpApJbnRlbCBPVEMK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031487AbdAJPw6 (ORCPT ); Tue, 10 Jan 2017 10:52:58 -0500 Received: from mga05.intel.com ([192.55.52.43]:26844 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932567AbdAJPw4 (ORCPT ); Tue, 10 Jan 2017 10:52:56 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,344,1477983600"; d="scan'208";a="1092283951" Date: Tue, 10 Jan 2017 17:52:44 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Jose Abreu Cc: dri-devel@lists.freedesktop.org, Carlos Palminha , linux-kernel@vger.kernel.org, Daniel Vetter Subject: Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB Message-ID: <20170110155244.GD31595@intel.com> References: <20170104132225.GE31595@intel.com> <8528542b-27fb-096f-8e22-af1fb7d5f0a1@synopsys.com> <20170104163607.GK31595@intel.com> <9df9f649-d3e9-7fd6-3dda-1d47799f50f7@synopsys.com> <20170105114640.GO31595@intel.com> <2700086a-00b9-e8c7-f502-df132fbbe2dc@synopsys.com> <20170110111601.GY31595@intel.com> <4233e877-8ca6-b3d4-e986-a2bf3e17f1e1@synopsys.com> <20170110153315.GC31595@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170110153315.GC31595@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 10, 2017 at 05:33:15PM +0200, Ville Syrjälä wrote: > On Tue, Jan 10, 2017 at 12:26:53PM +0000, Jose Abreu wrote: > > Hi Ville, > > > > > > On 10-01-2017 11:16, Ville Syrjälä wrote: > > > On Thu, Jan 05, 2017 at 02:46:06PM +0000, Jose Abreu wrote: > > >> > > > > [snip] > > > > >> The pixel clock rate is half of the TMDS character rate in 4:2:0 > > >> (in 24 bit), but for example in deep color 48 bit it will be the > > >> same rate. There is also a reduction to half of htotal, hactive, > > >> hblank, hfront, hsync and hback but I don't think it's a good > > >> solution to guide us from there. > > > I was asking if we can look at a specific modeline and whether we > > > can tell from that if we would need to output it as 4:2:0. > > > > Hmm, according to HDMI 2.0 spec there are no 4:2:0 only modes and > > the only way to figure out if the mode is 4:2:0 only (or able) is > > to parse the VCB and VBD blocks from EDID. The clock is half rate > > but this is the source that has to figure it out. The mode is > > still passed in a regular way (By VIC, by timing, ...). > > > > > > > >> Why does it feel wrong to you > > >> expanding the uapi? > > > Because it requires changing every single userspace kms client. And > > > it's not something userspace should have to worry about. > > > > I agree but, as Daniel said [1], we could make these new HDMI 2.0 > > features optional and only pass them to userspace if client asked > > for them. What do you think? > > 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. 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. 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. > > > > > [1] > > https://lists.freedesktop.org/archives/dri-devel/2017-January/128683.html > > > > > > > >> I think its important to say that the chosen colorspace can > > >> improve performance in systems: for example, as I said, 4:2:0 > > >> 24-bit uses half the rate that RGB 24-bit uses so we have less > > >> trafic in the bus. I am recently working with a FPGA connected > > >> trough pcie and I can definitely say that this is true. But, as > > >> expected, less traffic means less quality in final image so its > > >> not a matter of letting kernel decide, I think its a matter of > > >> user choosing between performance vs. quality. > > > Image quality control for userspace is a much bigger topic. And > > > something we have no real precedent for at the moment (apart from > > > user choosing a different fb pixel format). > > > > > > The performance arument is very hardware dependent, and not really > > > all that relevant IMO. If the user wants the big mode they either > > > get it or not depending on whether the system can deliver. > > > > > > > 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. > > -- > Ville Syrjälä > Intel OTC -- Ville Syrjälä Intel OTC