From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Date: Tue, 02 May 2017 17:06:31 +0200 Message-ID: <1493737591.8581.126.camel@redhat.com> References: <20170502133404.15354-1-kraxel@redhat.com> <20170502133404.15354-2-kraxel@redhat.com> <20170502172724.31188e2d@eldfell> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170502172724.31188e2d@eldfell> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Pekka Paalanen Cc: amd-gfx mailing list , Michel =?ISO-8859-1?Q?D=E4nzer?= , Emil Velikov , open list , ML dri-devel , Daniel Vetter List-Id: amd-gfx.lists.freedesktop.org ICBIaSwKCj4gSSBhbHNvIHRoaW5rIHRoYXQgdGhpcyBwYXRjaCByZXF1aXJlcyBtb3JlIGNvbW1l bnRzIHRoYW4gdGhlCj4gY29tbWl0IG1lc3NhZ2UgaGFzIGF0IHRoZSBtb21lbnQuCj4gCj4gUmVt b3ZpbmcgdGhlIGRlZmluaXRpb24gYWxzbyByZW1vdmVzIHRoZSBwb3NzaWJpbGl0eSB0byBkZXNj cmliZSBhIGxvdAo+IG9mIHBpeGVsIGZvcm1hdHMsIHNvIHRoYXQgc2hvdWxkIGRlZmluaXRlbHkg YmUgbWVudGlvbmVkLiBJIHRoaW5rIGl0Cj4gd291bGQgYWxzbyBiZSBnb29kIHRvIGhhdmUgc29t ZSBraW5kIG9mIGp1c3RpZmllZCBjbGFpbSB0aGF0IG5vCj4gaGFyZHdhcmUgYWN0dWFsbHkgbmVl ZHMgdGhlIHBpeGVsIGZvcm1hdHMgdGhpcyBpcyByZW1vdmluZyAoZS5nLiBSR0I1NjUKPiBCRSku CgpUaGF0IGFuZCBSR0IyMTAxMDEwIEJFIGFyZSB0aGUgb25seSBjYW5kaWRhdGVzIEkgY2FuIHRo aW5rIG9mLgoKRGVhbGluZyB3aXRoIHRob3NlIGluIG5vbmUtbmF0aXZlIGJ5dGVvcmRlciBpcyBh IFBJVEEgdGhvdWdoLiAgRGlzcGxheQpoYXJkd2FyZSBpcyBsaXR0bGUgZW5kaWFuIChwY2kgYnl0 ZSBvcmRlcikgZm9yIHF1aXRlIGEgd2hpbGUgYWxyZWFkeS4KCj4gTWF5YmUgdGhpcyB3YXMgYWxy ZWFkeSBpbiB0aGUgbG9uZyBkaXNjdXNzaW9ucywgYnV0IEkgZmVlbCBpdAo+IHNob3VsZCBiZSBz dW1tYXJpemVkIGluIHRoZSBjb21taXQgbWVzc2FnZS4KClJhZGVvbiBhbmQgbnZpZGlhIChudjQw KSBjYXJkcyB3aGVyZSBtZW50aW9uZWQuICBJJ2xsIHRyeSB0byBzdW1tYXJpemUKKGZlZWwgZnJl ZSB0byBjb3JyZWN0IG1lIGlmIEknbSB3cm9uZykuCgpudmlkaWEgaGFzIHN1cHBvcnQgZm9yIDgg Yml0LXBlci1jb2xvciBmb3JtYXRzIG9ubHkgb24gYmlnZW5kaWFuIGhvc3RzLgpOb3Qgc3VyZSB3 aGVuZXZlciB0aGlzIGlzIGEgZHJpdmVyIG9yIGhhcmR3YXJlIGxpbWl0YXRpb24uCgpyYWRlb24g bG9va3MgZGlmZmVyZW50bHkgb24gcHJlLVI2MDAgYW5kIFI2MDArIGhhcmR3YXJlLgoKcHJlLVI2 MDAgY2FuIGJ5dGVzd2FwIG9uIGNwdSBhY2Nlc3MsIHNvIHRoZSBjcHUgdmlldyBpcyBiaWdlbmRp YW4Kd2hlcmVhcyB0aGluZ3MgYXJlIGFjdHVhbGx5IHN0b3JlZCBvbiBsaXR0bGUgZW5kaWFuIGJ5 dGUgb3JkZXIuCkhhcmR3YXJlIHN1cHBvcnRzIGJvdGggMTZiaXQgYW5kIDMyYml0IHN3YXBzLiAg VXNlZCBmb3IgZmJkZXYgZW11bGF0aW9uCihwcm9iYWJseSAzMmJpdCBzd2FwcywgYnV0IG5vdCBm dWxseSBzdXJlKS4gIHhvcmcgcmFkZW9uIGRyaXZlciBkb2Vzbid0CnVzZSB0aGUgYnl0ZXN3YXBw aW5nIGZlYXR1cmUsIGJlY2F1c2UgaXQgaXMgYSBQSVRBIHdoZW4gYm8ncyBhcmUgbW92ZWQKYmV0 d2VlbiB2cmFtIGFuZCBzeXN0ZW0gbWVtb3J5LgoKUjYwMCsgc3VwcG9ydHMgYmlnZW5kaWFuIGZy YW1lYnVmZmVyIGZvcm1hdHMsIHNvIG5vIGJ5dGVzd2FwcGluZyBvbgphY2Nlc3MgaXMgbmVlZGVk LiAgTm90IHN1cmUgd2hlbmV2ZXIgdGhhdCBpbmNsdWRlcyAxNmJwcCBmb3JtYXRzIG9yCndoZW5l dmVyIHRoaXMgaXMgbGltaXRlZCB0byB0aGUgOCBiaXQtcGVyLWNvbG9yIGZvcm1hdHMgKHNpbWxp YXIgdG8KbnZpZGlhKS4gIERpc2N1c3Npb24gZm9jdXNlZCBvbiB0aGUgcHJlLVI2MDAgaGFyZHdh cmUgYW5kIGhvdyB0aGlzCm9uLWFjcHUtYWNjZXNzIGJ5dGVzd2FwcGluZyBpcyBtb3JlIGEgcHJv YmxlbSB0aGFuIGl0IGhlbHBzIC4uLgoKY2hlZXJzLAogIEdlcmQKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751405AbdEBPGh convert rfc822-to-8bit (ORCPT ); Tue, 2 May 2017 11:06:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60014 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751093AbdEBPGf (ORCPT ); Tue, 2 May 2017 11:06:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 62C5D7247C Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 62C5D7247C Message-ID: <1493737591.8581.126.camel@redhat.com> Subject: Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN From: Gerd Hoffmann To: Pekka Paalanen Cc: Emil Velikov , ML dri-devel , Jani Nikula , David Airlie , Michel =?ISO-8859-1?Q?D=E4nzer?= , open list , amd-gfx mailing list , Sean Paul , Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= , Alex Deucher , Daniel Vetter , Ilia Mirkin Date: Tue, 02 May 2017 17:06:31 +0200 In-Reply-To: <20170502172724.31188e2d@eldfell> References: <20170502133404.15354-1-kraxel@redhat.com> <20170502133404.15354-2-kraxel@redhat.com> <20170502172724.31188e2d@eldfell> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 02 May 2017 15:06:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > I also think that this patch requires more comments than the > commit message has at the moment. > > Removing the definition also removes the possibility to describe a lot > of pixel formats, so that should definitely be mentioned. I think it > would also be good to have some kind of justified claim that no > hardware actually needs the pixel formats this is removing (e.g. RGB565 > BE). That and RGB2101010 BE are the only candidates I can think of. Dealing with those in none-native byteorder is a PITA though. Display hardware is little endian (pci byte order) for quite a while already. > Maybe this was already in the long discussions, but I feel it > should be summarized in the commit message. Radeon and nvidia (nv40) cards where mentioned. I'll try to summarize (feel free to correct me if I'm wrong). nvidia has support for 8 bit-per-color formats only on bigendian hosts. Not sure whenever this is a driver or hardware limitation. radeon looks differently on pre-R600 and R600+ hardware. pre-R600 can byteswap on cpu access, so the cpu view is bigendian whereas things are actually stored on little endian byte order. Hardware supports both 16bit and 32bit swaps. Used for fbdev emulation (probably 32bit swaps, but not fully sure). xorg radeon driver doesn't use the byteswapping feature, because it is a PITA when bo's are moved between vram and system memory. R600+ supports bigendian framebuffer formats, so no byteswapping on access is needed. Not sure whenever that includes 16bpp formats or whenever this is limited to the 8 bit-per-color formats (simliar to nvidia). Discussion focused on the pre-R600 hardware and how this on-acpu-access byteswapping is more a problem than it helps ... cheers, Gerd