From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Date: Mon, 24 Apr 2017 16:03:48 +0300 Message-ID: <20170424130348.GV30290@intel.com> References: <20170421075825.6307-1-kraxel@redhat.com> <20170421092530.GE30290@intel.com> <1492768218.25675.33.camel@redhat.com> <20170421110804.GH30290@intel.com> <1492780323.25675.45.camel@redhat.com> <1492791271.25675.57.camel@redhat.com> <20170422100522.GS30290@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, open list , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Gerd Hoffmann , Daniel Vetter , Christian =?iso-8859-1?Q?K=F6nig?= T24gTW9uLCBBcHIgMjQsIDIwMTcgYXQgMDM6NTc6MDJQTSArMDkwMCwgTWljaGVsIETDpG56ZXIg d3JvdGU6Cj4gT24gMjIvMDQvMTcgMDc6MDUgUE0sIFZpbGxlIFN5cmrDpGzDpCB3cm90ZToKPiA+ IE9uIEZyaSwgQXByIDIxLCAyMDE3IGF0IDA2OjE0OjMxUE0gKzAyMDAsIEdlcmQgSG9mZm1hbm4g d3JvdGU6Cj4gPj4gICBIaSwKPiA+Pgo+ID4+Pj4gTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0 IGZvcm1hdHMgaW4gZHJtX2ZvdXJjYy5oIHNob3VsZCBiZSAKPiA+Pj4+IGluZGVwZW5kZW50IG9m IHRoZSBDUFUgYnl0ZSBvcmRlciBhbmQgdGhlIGZ1bmN0aW9uIAo+ID4+Pj4gZHJtX21vZGVfbGVn YWN5X2ZiX2Zvcm1hdCgpIGFuZCBkcml2ZXJzIGRlcGVuZGluZyBvbiB0aGF0IGluY29ycmVjdCAK PiA+Pj4+IGFzc3VtcHRpb24gYmUgZml4ZWQgaW5zdGVhZC4KPiA+Pj4KPiA+Pj4gVGhlIHByb2Js ZW0gaXMgdGhpcyBpc24ndCBhIGtlcm5lbC1pbnRlcm5hbCB0aGluZyBhbnkgbW9yZS4gIFdpdGgg dGhlCj4gPj4+IGFkZGl0aW9uIG9mIHRoZSBBRERGQjIgaW9jdGwgdGhlIGZvdXJjYyBjb2RlcyBi ZWNhbWUgcGFydCBvZiB0aGUKPiA+Pj4ga2VybmVsL3VzZXJzcGFjZSBhYmkgLi4uCj4gPj4KPiA+ PiBPaywgYWRkZWQgc29tZSBwcmludGsncyB0byB0aGUgQURERkIgYW5kIEFEREZCMiBjb2RlIHBh dGhzIGFuZCB0ZXN0ZWQgYQo+ID4+IGJpdC4gIEFwcGFyZW50bHkgcHJldHR5IG11Y2ggYWxsIHVz ZXJzcGFjZSBzdGlsbCB1c2VzIHRoZSBBRERGQiBpb2N0bC4KPiA+PiB4b3JnIChtb2Rlc2V0dGlu ZyBkcml2ZXIpIGRvZXMuICBnbm9tZS1zaGVsbCBpbiB3YXlsYW5kIG1vZGUgZG9lcy4KPiA+PiBT ZWVtcyB0aGUgYmlnIHRyYW5zaXRpb24gdG8gQURERkIyIGRpZG4ndCBoYXBwZW4geWV0Lgo+ID4+ Cj4gPj4gSSBndWVzcyB0aGF0IG1ha2VzIGNoYW5naW5nIGRybV9tb2RlX2xlZ2FjeV9mYl9mb3Jt YXQgKyBkcml2ZXJzIGEKPiA+PiByZWFzb25hYmxlIG9wdGlvbiAuLi4KPiA+IAo+ID4gWWVhaCwg SSBjYW1lIHRvIHRoZSBzYW1lIGNvbmNsdXNpb24gYWZ0ZXIgY2hhdHRpbmcgd2l0aCBzb21lCj4g PiBmb2xrcyBvbiBpcmMuCj4gPiAKPiA+IFNvIG15IGN1cnJlbnQgaWRlYSBpcyB0aGF0IHdlIGNo YW5nZSBhbnkgZHJpdmVyIHRoYXQgd2FudHMgdG8gZm9sbG93IHRoZQo+ID4gQ1BVIGVuZGlhbm5l c3MKPiAKPiBUaGlzIGlzbid0IHJlYWxseSBvcHRpb25hbCBmb3IgdmFyaW91cyByZWFzb25zLCBz b21lIG9mIHdoaWNoIGhhdmUgYmVlbgo+IGNvdmVyZWQgaW4gdGhpcyBkaXNjdXNzaW9uLgo+IAo+ IAo+ID4gdG8gZGVjbGFyZSBzdXBwb3J0IGZvciBiaWcgZW5kaWFuIGZvcm1hdHMgaWYgdGhlIENQ VSBpcwo+ID4gYmlnIGVuZGlhbi4gUHJlc3VtYWJseSB0aGVzZSBhcmUgbW9zdGx5IHRoZSB2aXJ0 dWFsIEdQVSBkcml2ZXJzLgo+ID4gCj4gPiBBZGRpdG9uYWxseSB3ZSdsbCBtYWtlIHRoZSBtYXBw aW5nIHBlcmZvcm1lZCBieSBkcm1fbW9kZV9sZWdhY3lfZmJfZm9ybWF0KCkKPiA+IGRyaXZlciBj b250cm9sbGVkLiBUaGF0IHdheSBkcml2ZXJzIHRoYXQgZ290IGNoYW5nZWQgdG8gZm9sbG93IENQ VQo+ID4gZW5kaWFubmVzcyBjYW4gcmV0dXJuIGEgZnJhbWVidWZmZXIgdGhhdCBtYXRjaGVzIENQ VSBlbmRpYW5uZXNzLiBBbmQKPiA+IGRyaXZlcnMgdGhhdCBleHBlY3QgdGhlIEdQVSBlbmRpYW5u ZXNzIHRvIG5vdCBkZXBlbmQgb24gdGhlIENQVQo+ID4gZW5kaWFubmVzcyB3aWxsIGtlZXAgd29y a2luZyBhcyB0aGV5IGRvIG5vdy4gVGhlIGRvd25zaWRlIGlzIHRoYXQgdXNlcnMKPiA+IG9mIHRo ZSBsZWdhY3kgYWRkZmIgaW9jdGwgd2lsbCBuZWVkIHRvIG1hZ2ljYWxseSBrbm93IHdoaWNoIGVu ZGlhbm5lc3MKPiA+IHRoZXkgd2lsbCBnZXQsIGJ1dCB0aGF0IGlzIGFwcGFyZW50bHkgYWxyZWFk eSB0aGUgY2FzZS4gQW5kIHVzZXJzIG9mCj4gPiBhZGRmYjIgd2lsbCBrZWVwIG9uIHNwZWNpZnlp bmcgdGhlIGVuZGlhbm5lc3MgZXhwbGljaXRseSB3aXRoCj4gPiBEUk1fRk9STUFUX0JJR19FTkRJ QU4gdnMuIDAuCj4gCj4gSSdtIGFmcmFpZCBpdCdzIG5vdCB0aGF0IHNpbXBsZS4KPiAKPiBUaGUg ZGlzcGxheSBoYXJkd2FyZSBvZiBvbGRlciAocHJlLVI2MDAgZ2VuZXJhdGlvbikgUmFkZW9uIEdQ VXMgZG9lcyBub3QKPiBzdXBwb3J0IHRoZSAiYmlnIGVuZGlhbiIgZm9ybWF0cyBkaXJlY3RseS4g SW4gb3JkZXIgdG8gYWxsb3cgdXNlcnNwYWNlCj4gdG8gYWNjZXNzIHBpeGVsIGRhdGEgaW4gbmF0 aXZlIGVuZGlhbm5lc3Mgd2l0aCB0aGUgQ1BVLCB3ZSBpbnN0ZWFkIHVzZQo+IGJ5dGUtc3dhcHBp bmcgZnVuY3Rpb25hbGl0eSB3aGljaCBvbmx5IGFmZmVjdHMgQ1BVIGFjY2Vzcy4KCk9LLCBJJ20g Z2V0dGluZyBjb25mdXNlZC4gQmFzZWQgb24gb3VyIGlyYyBkaXNjdXNzaW9uIEkgZ290IHRoZQpp bXByZXNzaW9uIHlvdSBkb24ndCBieXRlIHN3YXAgQ1BVIGFjY2Vzc2VzLiBCdXQgc2luY2UgeW91 IGRvLCBob3cKZG8geW91IGRlYWwgd2l0aCBtaXhpbmcgOGJwcCB2cy4gMTZicHAgdnMuIDMyYnBw PwoKPiBUaGlzIG1lYW5zCj4gdGhhdCB0aGUgR1BVIGFuZCBDUFUgZWZmZWN0aXZlbHkgc2VlIGRp ZmZlcmVudCByZXByZXNlbnRhdGlvbnMgb2YgdGhlCj4gc2FtZSB2aWRlbyBtZW1vcnkgY29udGVu dHMuCj4gCj4gVXNlcnNwYWNlIGNvZGUgZGVhbGluZyB3aXRoIEdQVSBhY2Nlc3MgdG8gcGl4ZWwg ZGF0YSBuZWVkcyB0byBrbm93IHRoZQo+IGZvcm1hdCBhcyBzZWVuIGJ5IHRoZSBHUFUsIHdoZXJl YXMgY29kZSBkZWFsaW5nIHdpdGggQ1BVIGFjY2VzcyBuZWVkcyB0bwo+IGtub3cgdGhlIGZvcm1h dCBhcyBzZWVuIGJ5IHRoZSBDUFUuIEkgZG9uJ3Qgc2VlIGFueSB3YXkgdG8gZXhwcmVzcyB0aGlz Cj4gd2l0aCBhIHNpbmdsZSBmb3JtYXQgZGVmaW5pdGlvbi4KCkhtbS4gV2VsbCB0aGF0IGNlcnRh aW5seSBtYWtlcyBsaWZlIGV2ZW4gbW9yZSBpbnRlcmVzdGluZy4KCi0tIApWaWxsZSBTeXJqw6Rs w6QKSW50ZWwgT1RDCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmFtZC1nZnggbWFpbGluZyBsaXN0CmFtZC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0 dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vYW1kLWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1170596AbdDXNEL (ORCPT ); Mon, 24 Apr 2017 09:04:11 -0400 Received: from mga07.intel.com ([134.134.136.100]:50254 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1170584AbdDXNED (ORCPT ); Mon, 24 Apr 2017 09:04:03 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,244,1488873600"; d="scan'208";a="78153626" Date: Mon, 24 Apr 2017 16:03:48 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: Gerd Hoffmann , amd-gfx@lists.freedesktop.org, open list , dri-devel@lists.freedesktop.org, Daniel Vetter , Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality. Message-ID: <20170424130348.GV30290@intel.com> References: <20170421075825.6307-1-kraxel@redhat.com> <20170421092530.GE30290@intel.com> <1492768218.25675.33.camel@redhat.com> <20170421110804.GH30290@intel.com> <1492780323.25675.45.camel@redhat.com> <1492791271.25675.57.camel@redhat.com> <20170422100522.GS30290@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Mon, Apr 24, 2017 at 03:57:02PM +0900, Michel Dänzer wrote: > On 22/04/17 07:05 PM, Ville Syrjälä wrote: > > On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote: > >> Hi, > >> > >>>> My personal opinion is that formats in drm_fourcc.h should be > >>>> independent of the CPU byte order and the function > >>>> drm_mode_legacy_fb_format() and drivers depending on that incorrect > >>>> assumption be fixed instead. > >>> > >>> The problem is this isn't a kernel-internal thing any more. With the > >>> addition of the ADDFB2 ioctl the fourcc codes became part of the > >>> kernel/userspace abi ... > >> > >> Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a > >> bit. Apparently pretty much all userspace still uses the ADDFB ioctl. > >> xorg (modesetting driver) does. gnome-shell in wayland mode does. > >> Seems the big transition to ADDFB2 didn't happen yet. > >> > >> I guess that makes changing drm_mode_legacy_fb_format + drivers a > >> reasonable option ... > > > > Yeah, I came to the same conclusion after chatting with some > > folks on irc. > > > > So my current idea is that we change any driver that wants to follow the > > CPU endianness > > This isn't really optional for various reasons, some of which have been > covered in this discussion. > > > > to declare support for big endian formats if the CPU is > > big endian. Presumably these are mostly the virtual GPU drivers. > > > > Additonally we'll make the mapping performed by drm_mode_legacy_fb_format() > > driver controlled. That way drivers that got changed to follow CPU > > endianness can return a framebuffer that matches CPU endianness. And > > drivers that expect the GPU endianness to not depend on the CPU > > endianness will keep working as they do now. The downside is that users > > of the legacy addfb ioctl will need to magically know which endianness > > they will get, but that is apparently already the case. And users of > > addfb2 will keep on specifying the endianness explicitly with > > DRM_FORMAT_BIG_ENDIAN vs. 0. > > I'm afraid it's not that simple. > > The display hardware of older (pre-R600 generation) Radeon GPUs does not > support the "big endian" formats directly. In order to allow userspace > to access pixel data in native endianness with the CPU, we instead use > byte-swapping functionality which only affects CPU access. OK, I'm getting confused. Based on our irc discussion I got the impression you don't byte swap CPU accesses. But since you do, how do you deal with mixing 8bpp vs. 16bpp vs. 32bpp? > This means > that the GPU and CPU effectively see different representations of the > same video memory contents. > > Userspace code dealing with GPU access to pixel data needs to know the > format as seen by the GPU, whereas code dealing with CPU access needs to > know the format as seen by the CPU. I don't see any way to express this > with a single format definition. Hmm. Well that certainly makes life even more interesting. -- Ville Syrjälä Intel OTC