From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162414AbdD0HDQ (ORCPT ); Thu, 27 Apr 2017 03:03:16 -0400 Received: from mail.netline.ch ([148.251.143.178]:49513 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933426AbdD0HDK (ORCPT ); Thu, 27 Apr 2017 03:03:10 -0400 Subject: Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format To: Gerd Hoffmann Cc: Daniel Vetter , amd-gfx@lists.freedesktop.org, open list , dri-devel@lists.freedesktop.org References: <20170424062532.26722-1-kraxel@redhat.com> <20170424062532.26722-4-kraxel@redhat.com> <3b872a56-80b5-0c44-712f-a9517489eb24@daenzer.net> <1493185990.23739.7.camel@redhat.com> <8f91cc58-16dc-5899-66b6-06d430a18801@daenzer.net> <1493208671.23739.19.camel@redhat.com> <6bd62182-0de5-a8a7-78c3-029fc73ecc91@daenzer.net> <1493275550.31995.31.camel@redhat.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <668bc373-1614-a095-6085-15c040f322b8@daenzer.net> Date: Thu, 27 Apr 2017 16:02:58 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1493275550.31995.31.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/04/17 03:45 PM, Gerd Hoffmann wrote: > Hi, > >>> That is done using the RADEON_TILING_SWAP_{16,32}BIT flag mentioned in >>> another thread? >> >> Right. >> >> >>> What about dumb bos? You've mentioned the swap flag isn't used for >>> those. Which implies they are in little endian byte order (both gpu and >>> cpu view). >> >> Right, AFAICT from looking at the code. > > Ok. > > And I also don't see an easy way to make them big endian (cpu view) > using swapping with the existing drm interfaces, given we apply a format > when we put the bo into use as framebuffer, not when creating it. So > userspace can: (1) create dumb bo, (2) map bo, (3) write something bo, > (4) create fb + attach to crtc. And at (3) we don't know the format > yet, so we can't configure swapping accordingly. > > So just not using the swapping indeed looks like the only sensible > option. Which in turn implies there is no BGRA8888 support for dumb > bos. Hmm, I can see the problem. Userspace expectation appears to be > that ADDFB configures a native endian framebuffer, which the driver > simply can't do on bigendian. ... with pre-R600 GPUs. > So, what can/should the driver do here? Throw errors for ADDFB and > force userspace to use ADDFB2? From a design point of view the best > option, but in the other hand I suspect that could break the xorg radeon > driver ... Yes, it would. One thing we could do is provide a way for userspace to query the effective format(s) as seen by the GPU and/or CPU. It might also make sense for the radeon driver to set the RADEON_TILING_SWAP_{16,32}BIT flags for dumb BOs. I wonder about the status of apps using dumb BOs directly wrt this discussion. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer