On Tue, Apr 25, 2017 at 09:49:38AM +0900, Michel Dänzer wrote: > On 24/04/17 11:26 PM, Ville Syrjälä wrote: > > On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote: > >> On 24/04/17 04:36 PM, Gerd Hoffmann wrote: > >>> > >>>>> drm: fourcc byteorder: add DRM_FORMAT_CPU_* > >>>>> drm: fourcc byteorder: add bigendian support to > >>>>> drm_mode_legacy_fb_format > >>>> > >>>> As I explained in my last followup in the "[PATCH] drm: fourcc > >>>> byteorder: brings header file comments in line with reality." thread, > >>>> the mapping between GPU and CPU formats has to be provided by the > >>>> driver, it cannot be done statically. > >>> > >>> Well, the drm fourcc codes represent the cpu view (i.e. what userspace > >>> will fill the ADDFB2-created framebuffers with). > >> > >> Ville is adamant that they represent the GPU view. This needs to be > >> resolved one way or the other. > > > > Since the byte swapping can happen either for CPU or display access > > I guess we can't just consider the GPU and display as a single entity. > > > > We may need to consider several agents: > > 1. display > > 2. GPU > > 3. CPU > > 4. other DMA > > > > Not sure what we can say about 4. I presume it's going to be like the > > GPU or the CPU in the sense that it might go through the CPU byte > > swapping logic or not. I'm just going to ignore it. > > > > Let's say we have the following bytes in memory > > (in order of increasing address): A,B,C,D > > We'll assume GPU and display are LE natively. Each component will see > > the resulting 32bpp 8888 pixel as follows (msb left->lsb right): > > > > LE CPU w/ no byte swapping: > > display: DCBA > > GPU: DCBA > > CPU: DCBA > > = everyone agrees > > > > BE CPU w/ no byte swapping: > > display: DCBA > > GPU: DCBA > > CPU: ABCD > > = GPU and display agree > > > > BE CPU w/ display byte swapping: > > display: ABCD > > GPU: DCBA > > CPU: ABCD > > = CPU and display agree > > > > BE CPU w/ CPU access byte swapping: > > display: DCBA > > GPU: DCBA > > CPU: DCBA > > = everyone agrees > > Beware that for this list, you're using a format definition Actually I'm not using any format definitions here. > which is > based on a packed 32-bit value. This does *not* match the current > DRM_FORMAT_*8888 definitions. E.g. in the last case, display and GPU use > the same DRM_FORMAT, but the CPU uses the "inverse" one. I wasn't concerned about the specific drm format, just what kind of a 32bpp value everyone will see given the same memory contents. -- Ville Syrjälä Intel OTC
