Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1634700
| From | Michel Dänzer <michel@daenzer.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN |
| Date | 2017-05-03 05:10 +0200 |
| Message-ID | <tCSPT-7i5-1@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> <tCHB8-8eV-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 03/05/17 12:06 AM, Gerd Hoffmann wrote: > >> 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 by default, but not exclusively. > 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). 32-bit swaps for 32 bpp, 16-bit swaps for 16 bpp. > 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 [...] It includes 16bpp. Looking at drivers/gpu/drm/radeon/atombios_crtc.c:dce4_crtc_do_set_base(), it sets up byte-swapping for all multi-byte formats, so it effectively treats all those formats as if they had DRM_FORMAT_BIG_ENDIAN set. If the radeon (and amdgpu) driver were to be changed to use drm_mode_legacy_fb_format_he for >= R600, that must also handle 16 bpp, which requires DRM_FORMAT_BIG_ENDIAN. So I still don't see how that can be removed or even deprecated. From Ilia's followup it sounds like there's a similar situation with nouveau. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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