Re: [Mesa-dev] gallium endianness and hw drivers
On Thu, Jan 16, 2014 at 8:43 AM, Michel Dänzer mic...@daenzer.net wrote: On Mit, 2014-01-15 at 14:27 +0100, Marek Olšák wrote: On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer mic...@daenzer.net wrote: On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote: I think the format conversion functions should look like: #ifdef BIG_ENDIAN case PIPE_FORMAT_A8B8G8R8_UNORM: return hw_format_for_R8G8B8A8_UNORM; ... #else case PIPE_FORMAT_R8G8B8A8_UNORM: return hw_format_for_R8G8B8A8_UNORM; #endif which can be simplified to: case PIPE_FORMAT_RGBA_UNORM: return hw_format_for_R8G8B8A8_UNORM; So that the GPU can see the same formats, but they are different for the CPU. What do you think? That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE exactly. I wouldn't worry about such optimizations when we don't even have proper big endian support. I'd consider it part of proper big endian support though. I'd rather stick to the simplest solution for the old hardware. What do you mean by old hardware? Remember that SI and newer have basically no hardware byteswapping facilities anymore, and PowerPC machines with PCIe slots are still being produced and sold. R300-R500. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer mic...@daenzer.net wrote: On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote: I think the format conversion functions should look like: #ifdef BIG_ENDIAN case PIPE_FORMAT_A8B8G8R8_UNORM: return hw_format_for_R8G8B8A8_UNORM; ... #else case PIPE_FORMAT_R8G8B8A8_UNORM: return hw_format_for_R8G8B8A8_UNORM; #endif which can be simplified to: case PIPE_FORMAT_RGBA_UNORM: return hw_format_for_R8G8B8A8_UNORM; So that the GPU can see the same formats, but they are different for the CPU. What do you think? That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE exactly. Well, there's the added complication that GL_RGBA / GL_UNSIGNED_BYTE can be specified with an unaligned pointer on architectures that does not support unaligned reads (e.g ARM), and packed formats cannot. And then there's GL_RGB / GL_UNSIGNED_BYTE which further messes the treat-array-formats-as-if-they-were-packed strategy. I think one issue here is that we're trying to use a single format attribute for several purposes (API visible representation, GPU/driver internal representation). Indeed, and if we stopped doing that, the issues above should be solvable. I've actually been involved in the successful shipping of an OpenGL ES 2.0 implementation written for little-endian machines, on a big-endian machine. But we had the benefit of being able to make hardware-modifications, which made this a whole lot easier. IIRC, we just made the texture-fetches and pixel-writes use native endianess. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer mic...@daenzer.net wrote: On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote: I think the format conversion functions should look like: #ifdef BIG_ENDIAN case PIPE_FORMAT_A8B8G8R8_UNORM: return hw_format_for_R8G8B8A8_UNORM; ... #else case PIPE_FORMAT_R8G8B8A8_UNORM: return hw_format_for_R8G8B8A8_UNORM; #endif which can be simplified to: case PIPE_FORMAT_RGBA_UNORM: return hw_format_for_R8G8B8A8_UNORM; So that the GPU can see the same formats, but they are different for the CPU. What do you think? That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE exactly. I wouldn't worry about such optimizations when we don't even have proper big endian support. I'd rather stick to the simplest solution for the old hardware. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Mit, 2014-01-15 at 14:27 +0100, Marek Olšák wrote: On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer mic...@daenzer.net wrote: On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote: I think the format conversion functions should look like: #ifdef BIG_ENDIAN case PIPE_FORMAT_A8B8G8R8_UNORM: return hw_format_for_R8G8B8A8_UNORM; ... #else case PIPE_FORMAT_R8G8B8A8_UNORM: return hw_format_for_R8G8B8A8_UNORM; #endif which can be simplified to: case PIPE_FORMAT_RGBA_UNORM: return hw_format_for_R8G8B8A8_UNORM; So that the GPU can see the same formats, but they are different for the CPU. What do you think? That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE exactly. I wouldn't worry about such optimizations when we don't even have proper big endian support. I'd consider it part of proper big endian support though. I'd rather stick to the simplest solution for the old hardware. What do you mean by old hardware? Remember that SI and newer have basically no hardware byteswapping facilities anymore, and PowerPC machines with PCIe slots are still being produced and sold. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote: I think the format conversion functions should look like: #ifdef BIG_ENDIAN case PIPE_FORMAT_A8B8G8R8_UNORM: return hw_format_for_R8G8B8A8_UNORM; ... #else case PIPE_FORMAT_R8G8B8A8_UNORM: return hw_format_for_R8G8B8A8_UNORM; #endif which can be simplified to: case PIPE_FORMAT_RGBA_UNORM: return hw_format_for_R8G8B8A8_UNORM; So that the GPU can see the same formats, but they are different for the CPU. What do you think? That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE exactly. I think one issue here is that we're trying to use a single format attribute for several purposes (API visible representation, GPU/driver internal representation). -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
I think the format conversion functions should look like: #ifdef BIG_ENDIAN case PIPE_FORMAT_A8B8G8R8_UNORM: return hw_format_for_R8G8B8A8_UNORM; ... #else case PIPE_FORMAT_R8G8B8A8_UNORM: return hw_format_for_R8G8B8A8_UNORM; #endif which can be simplified to: case PIPE_FORMAT_RGBA_UNORM: return hw_format_for_R8G8B8A8_UNORM; So that the GPU can see the same formats, but they are different for the CPU. What do you think? Marek On Mon, Jan 6, 2014 at 10:00 AM, Michel Dänzer mic...@daenzer.net wrote: On Fre, 2013-12-27 at 19:41 +0100, Marek Olšák wrote: Okay. Using Axxx for transfers only is a good idea, just please make sure the formats are not advertised to the state tracker. Advertising the format to the state tracker is the whole point :), as it's the format that matches the X11 semantics on big endian hosts. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Fre, 2013-12-27 at 19:41 +0100, Marek Olšák wrote: Okay. Using Axxx for transfers only is a good idea, just please make sure the formats are not advertised to the state tracker. Advertising the format to the state tracker is the whole point :), as it's the format that matches the X11 semantics on big endian hosts. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
Okay. Using Axxx for transfers only is a good idea, just please make sure the formats are not advertised to the state tracker. Also, resource_copy_region doesn't (it sometimes does, but shouldn't) do format conversions, so pipe-blit must be used instead. You can fork r600_copy_region_with_blit for that purpose. r300_blit doesn't check if the formats are supported (unlike resource_copy_region), so you should be fine there. Marek On Thu, Dec 26, 2013 at 1:32 AM, Michel Dänzer mic...@daenzer.net wrote: On Mit, 2013-12-25 at 15:57 +0100, Marek Olšák wrote: Some comments about the r300g patch. The hardware doesn't support Axxx texture formats for blending and alpha-test. Only xxxA formats are supported. I know, the idea is to only actually use the Axxx layout for transfers but to use xxxA for actual rendering. But I guess that could break in other ways... So, do you think the way to go is to handle this explicitly in the state trackers? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
Some comments about the r300g patch. The hardware doesn't support Axxx texture formats for blending and alpha-test. Only xxxA formats are supported. The driver already supports all formats it can support and no other formats can be added (except for those where the component ordering matches currently-advertised formats). Most importantly, the Axxx formats shouldn't be advertised to the state tracker. I think the hardware only has states for bit swapping. Other than that, I'm afraid there's not much else we can do. Marek On Mon, Dec 16, 2013 at 10:15 AM, Michel Dänzer mic...@daenzer.net wrote: On Mon, 2013-12-16 at 17:05 +1000, Dave Airlie wrote: So the llvmpipe endian work broke the nouveau nv40 support for the nv43 in the ppc G5 a few people have, Same for r300g: https://bugs.freedesktop.org/show_bug.cgi?id=71789 Now I'm not really sure how this is supposed to be fixed, the gallium driver exports the formats it supports, which doesn't include the translated formats for PIPE_FORMAT_BGRA and PIPE_FORMAT_8BGRX which end up like PIPE_FORMAT_A8R8G8B8_UNORM this. This means no 8-bit visuals and ensuing fail. Now I'm not sure the hw has any swappers or anything to facilitate these formats for rendering to, so it seems to me the pipe driver is doing the right thing, so my thinking is the state tracker should probably be dealing with this better, but again I'm not really sure how, maybe this just all worked in the past by luck. I'm afraid it did. So should dri_fill_in_modes be doing a bit more on big endian? so if it can't find any formats the way it wants, it tries the other way, and reports those back so X gets different visuals with the masks all moved about? Not sure we can do anything about the visuals, as X11 requires that all the non-alpha bits are packed in the least significant bits in host byte order. This could probably still be solved in the state trackers though, by falling back to formats which don't match the APIs they're providing, and fixing things up as necessary when copying data to/from transfers. Note that this would require adding explicit-endianness variants of many formats, such as e.g. PIPE_FORMAT_*32*, where the components are now defined in host byte order. I'm attaching WIP patches for a different approach with r300g. The second patch makes r300g advertise PIPE_FORMAT_*8R8G8B8_UNORM, but treats them like PIPE_FORMAT_B8G8R8*8_UNORM for actual rendering operations, and only converts to the API-specified formats for transfer access. This mirrors what the Xorg radeon driver does to translate between what X11 imposes and what the hardware supports. I assume xf86-video-nouveau might be doing something similar. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Mit, 2013-12-25 at 15:57 +0100, Marek Olšák wrote: Some comments about the r300g patch. The hardware doesn't support Axxx texture formats for blending and alpha-test. Only xxxA formats are supported. I know, the idea is to only actually use the Axxx layout for transfers but to use xxxA for actual rendering. But I guess that could break in other ways... So, do you think the way to go is to handle this explicitly in the state trackers? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Mon, 2013-12-16 at 17:05 +1000, Dave Airlie wrote:
So the llvmpipe endian work broke the nouveau nv40 support for the
nv43 in the ppc G5 a few people have,
Same for r300g: https://bugs.freedesktop.org/show_bug.cgi?id=71789
Now I'm not really sure how this is supposed to be fixed,
the gallium driver exports the formats it supports, which doesn't
include the translated formats for PIPE_FORMAT_BGRA and
PIPE_FORMAT_8BGRX which end up like PIPE_FORMAT_A8R8G8B8_UNORM
this. This means no 8-bit visuals and ensuing fail.
Now I'm not sure the hw has any swappers or anything to facilitate
these formats for rendering to, so it seems to me the pipe driver is
doing the right thing, so my thinking is the state tracker should
probably be dealing with this better, but again I'm not really sure
how, maybe this just all worked in the past by luck.
I'm afraid it did.
So should dri_fill_in_modes be doing a bit more on big endian? so if
it can't find any formats the way it wants, it tries the other way,
and reports those back so X gets different visuals with the masks all
moved about?
Not sure we can do anything about the visuals, as X11 requires that all
the non-alpha bits are packed in the least significant bits in host byte
order.
This could probably still be solved in the state trackers though, by
falling back to formats which don't match the APIs they're providing,
and fixing things up as necessary when copying data to/from transfers.
Note that this would require adding explicit-endianness variants of many
formats, such as e.g. PIPE_FORMAT_*32*, where the components are now
defined in host byte order.
I'm attaching WIP patches for a different approach with r300g. The
second patch makes r300g advertise PIPE_FORMAT_*8R8G8B8_UNORM, but
treats them like PIPE_FORMAT_B8G8R8*8_UNORM for actual rendering
operations, and only converts to the API-specified formats for transfer
access. This mirrors what the Xorg radeon driver does to translate
between what X11 imposes and what the hardware supports. I assume
xf86-video-nouveau might be doing something similar.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
From b3c5896e87036bdfd744e3b1b768a58c3e38ac2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= michel.daen...@amd.com
Date: Mon, 25 Nov 2013 10:13:42 +0900
Subject: [PATCH 1/2] st/dri: Use packed RGB formats
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/state_trackers/dri/common/dri_drawable.c | 8
src/gallium/state_trackers/dri/drm/dri2.c| 20 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c b/src/gallium/state_trackers/dri/common/dri_drawable.c
index f255108..cb94799 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -231,11 +231,11 @@ dri_set_tex_buffer2(__DRIcontext *pDRICtx, GLint target,
if (format == __DRI_TEXTURE_FORMAT_RGB) {
/* only need to cover the formats recognized by dri_fill_st_visual */
switch (internal_format) {
- case PIPE_FORMAT_B8G8R8A8_UNORM:
-internal_format = PIPE_FORMAT_B8G8R8X8_UNORM;
+ case PIPE_FORMAT_BGRA_UNORM:
+internal_format = PIPE_FORMAT_BGRX_UNORM;
break;
- case PIPE_FORMAT_A8R8G8B8_UNORM:
-internal_format = PIPE_FORMAT_X8R8G8B8_UNORM;
+ case PIPE_FORMAT_ARGB_UNORM:
+internal_format = PIPE_FORMAT_XRGB_UNORM;
break;
default:
break;
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c b/src/gallium/state_trackers/dri/drm/dri2.c
index 868cd25..06bdaa8 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -125,10 +125,10 @@ dri2_drawable_get_buffers(struct dri_drawable *drawable,
* may occur as the stvis-color_format.
*/
switch(format) {
- case PIPE_FORMAT_B8G8R8A8_UNORM:
+ case PIPE_FORMAT_BGRA_UNORM:
depth = 32;
break;
- case PIPE_FORMAT_B8G8R8X8_UNORM:
+ case PIPE_FORMAT_BGRX_UNORM:
depth = 24;
break;
case PIPE_FORMAT_B5G6R5_UNORM:
@@ -398,10 +398,10 @@ dri2_allocate_buffer(__DRIscreen *sPriv,
switch (format) {
case 32:
- pf = PIPE_FORMAT_B8G8R8A8_UNORM;
+ pf = PIPE_FORMAT_BGRA_UNORM;
break;
case 24:
- pf = PIPE_FORMAT_B8G8R8X8_UNORM;
+ pf = PIPE_FORMAT_BGRX_UNORM;
break;
case 16:
pf = PIPE_FORMAT_Z16_UNORM;
@@ -544,13 +544,13 @@ dri2_create_image_from_name(__DRIscreen *_screen,
pf = PIPE_FORMAT_B5G6R5_UNORM;
break;
case
Re: [Mesa-dev] gallium endianness and hw drivers
Wouldn't it be easier to just revert the gallium endianness rework? If it breaks all hw drivers on big endian machines, it's apparently not done right. Marek On Mon, Dec 16, 2013 at 8:05 AM, Dave Airlie airl...@gmail.com wrote: So the llvmpipe endian work broke the nouveau nv40 support for the nv43 in the ppc G5 a few people have, Now I'm not really sure how this is supposed to be fixed, the gallium driver exports the formats it supports, which doesn't include the translated formats for PIPE_FORMAT_BGRA and PIPE_FORMAT_8BGRX which end up like PIPE_FORMAT_A8R8G8B8_UNORM this. This means no 8-bit visuals and ensuing fail. Now I'm not sure the hw has any swappers or anything to facilitate these formats for rendering to, so it seems to me the pipe driver is doing the right thing, so my thinking is the state tracker should probably be dealing with this better, but again I'm not really sure how, maybe this just all worked in the past by luck. So should dri_fill_in_modes be doing a bit more on big endian? so if it can't find any formats the way it wants, it tries the other way, and reports those back so X gets different visuals with the masks all moved about? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Mon, 2013-12-16 at 13:30 +0100, Marek Olšák wrote: Wouldn't it be easier to just revert the gallium endianness rework? If it breaks all hw drivers on big endian machines, it's apparently not done right. It also makes llvmpipe work on P7 and P8 and enables r600 ... which some people rely on as well nowadays. We need to find the right fix. I'm eager to see what Adam thinks :-) Cheers, Ben. Marek On Mon, Dec 16, 2013 at 8:05 AM, Dave Airlie airl...@gmail.com wrote: So the llvmpipe endian work broke the nouveau nv40 support for the nv43 in the ppc G5 a few people have, Now I'm not really sure how this is supposed to be fixed, the gallium driver exports the formats it supports, which doesn't include the translated formats for PIPE_FORMAT_BGRA and PIPE_FORMAT_8BGRX which end up like PIPE_FORMAT_A8R8G8B8_UNORM this. This means no 8-bit visuals and ensuing fail. Now I'm not sure the hw has any swappers or anything to facilitate these formats for rendering to, so it seems to me the pipe driver is doing the right thing, so my thinking is the state tracker should probably be dealing with this better, but again I'm not really sure how, maybe this just all worked in the past by luck. So should dri_fill_in_modes be doing a bit more on big endian? so if it can't find any formats the way it wants, it tries the other way, and reports those back so X gets different visuals with the masks all moved about? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium endianness and hw drivers
On Mon, 2013-12-16 at 13:30 +0100, Marek Olšák wrote: Wouldn't it be easier to just revert the gallium endianness rework? That would be putting our heads in the sand. If it breaks all hw drivers on big endian machines, it's apparently not done right. The HW drivers were already broken before, the rework just made the breakage more obvious. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] gallium endianness and hw drivers
So the llvmpipe endian work broke the nouveau nv40 support for the nv43 in the ppc G5 a few people have, Now I'm not really sure how this is supposed to be fixed, the gallium driver exports the formats it supports, which doesn't include the translated formats for PIPE_FORMAT_BGRA and PIPE_FORMAT_8BGRX which end up like PIPE_FORMAT_A8R8G8B8_UNORM this. This means no 8-bit visuals and ensuing fail. Now I'm not sure the hw has any swappers or anything to facilitate these formats for rendering to, so it seems to me the pipe driver is doing the right thing, so my thinking is the state tracker should probably be dealing with this better, but again I'm not really sure how, maybe this just all worked in the past by luck. So should dri_fill_in_modes be doing a bit more on big endian? so if it can't find any formats the way it wants, it tries the other way, and reports those back so X gets different visuals with the masks all moved about? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
