Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1634476

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

From Gerd Hoffmann <kraxel@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN
Date 2017-05-02 17:10 +0200
Message-ID <tCHB8-8eV-13@gated-at.bofh.it> (permalink)
References <tCGc2-7i0-7@gated-at.bofh.it> <tCGc2-7i0-13@gated-at.bofh.it> <tCGvn-7oC-1@gated-at.bofh.it> <tCGYq-7Na-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


  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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Gerd Hoffmann <kraxel@redhat.com> - 2017-05-02 15:40 +0200
  Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Emil Velikov <emil.l.velikov@gmail.com> - 2017-05-02 16:00 +0200
    Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Gerd Hoffmann <kraxel@redhat.com> - 2017-05-02 16:20 +0200
    Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Pekka Paalanen <ppaalanen@gmail.com> - 2017-05-02 16:30 +0200
      Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Gerd Hoffmann <kraxel@redhat.com> - 2017-05-02 17:10 +0200
        Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Ilia Mirkin <imirkin@alum.mit.edu> - 2017-05-02 20:00 +0200
        Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Michel Dänzer <michel@daenzer.net> - 2017-05-03 05:10 +0200
          Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Gerd Hoffmann <kraxel@redhat.com> - 2017-05-03 11:30 +0200
            Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN Michel Dänzer <michel@daenzer.net> - 2017-05-08 02:40 +0200

csiph-web