[PATCH 0/6] drm: tackle byteorder issues, take two

[Ville Syrjälä]

On Mon, Apr 24, 2017 at 05:26:03PM +0300, 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

So after some further thought this seems like a somewhat crazy
combination. It does make sense from the simplicity POV in that 
the CPU byte swapping isn't needed, and thus the problems with
concurrent access to buffers with different pixel sizes vanish.

However the GPU has to somehow be able to produce data the display
can consume, so presumably there must be some knobs in the GPU to do
the opposite byte swapping that the display does, or the GPU must be
restricted to only use framebuffers in formats like 8888.

> 
> BE CPU w/ CPU access byte swapping:
>  display: DCBA
>  GPU: DCBA
>  CPU: DCBA
>  = everyone agrees
> 
> BE CPU w/ both display and CPU byte swapping:
>  display: ABCD
>  GPU: DCBA
>  CPU: DCBA
>  = CPU and GPU agree (doesn't seem all that useful)
> 
> The different byte swapping tricks must have seemed like a great idea to
> someone, but in the end they're just making our life more miserable.
> 
> > > The gpu view can certainly differ from that.  Implementing this is up
> > > to the driver IMO.
> > > 
> > > When running on dumb framebuffers userspace doesn't need to know what
> > > the gpu view is.
> 
> True. So for that we'd just need to consider whether the CPU and display
> agree or disagree on the byte order. And I guess we'd have to pick from
> the following choices for a BE CPU:
> 
> CPU and display agree:
>  * FB is big endian, or FB is host endian (or whatever we would call it)
> CPU and display disagree:
>  * FB is little endian, or FB is foreign endian (or whatever)
> 
> > > 
> > > When running in opengl mode there will be a hardware-specific mesa
> > > driver in userspace, which will either know what the gpu view is (for
> > > example because there is only one way to implement this in hardware) or
> > > it can use hardware-specific ioctls to ask the kernel driver what the
> > > gpu view is.
> > 
> > Not sure this can be hidden in the OpenGL driver. How would e.g. a
> > Wayland compositor or the Xorg modesetting driver know which OpenGL
> > format corresponds to a given DRM_FORMAT?
> 
> How are GL formats defined? /me needs to go read the spec again.
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Ville Syrjälä
Intel OTC