[Mesa-dev] [PATCH v3 0/4] Fix OpenGL 1.3 big-endian support in r600g

[Ilia Mirkin]

It appears you regressed vbo-subdata-many
drawelements/drawrangeelements. This seems highly relevant, since it's
mapping a buffer and updating data within it. Any idea what happened
there? Or was it just passing by luck before?

On Thu, Apr 21, 2016 at 10:39 AM, Oded Gabbay <oded.gabbay at gmail.com> wrote:
> Hi,
>
> In v3 I removed all changes to gallium and mesa/st as they are no longer needed.
> All the work to recognize if and when we need to do endian swapping is done
> inside the r600g driver and no additional flag was added to any structure.
>
> This magic is done by understanding that the only use case where endian swapping
> is *not* needed in a big-endian machine is for textures that are handled by the
> DB unit in the GPU, because DB can't do swapping. Therefore, if a texture is
> marked as depth and not flushing, I disable the swap (treat it with GPU
> endianess). In all other cases, I configure endian swap. Credit is due to
> Marek Olšák who gave me this information.
>
> That is not the entire picture though. There are exceptions, such as array
> formats. There are also cases where it is not enough to do byte-swapping and
> I need to do component swapping or change the swizzling configuration. But all
> that is done strictly in the r600g translation functions.
>
> As a result, and because two patches that were approved have already been
> pushed to master, the patch-set got a lot smaller.
>
> The results got a bit better than v2. Still there are some difference vs.
> x86-64 but the majority of cases were fixed.
>
> Tests were done using piglit and by visual observance (I often looked at
> the screen to verify the colors are correct).
>
> For BE, I used a POWER7 machine with a CEDAR GL card (Evergreen).
> For LE, I used a skylake machine with the same card.
>
> I fixed most of the major tests (and some minor ones) - readpixsanity,
> draw-pixels, texwrap, copy-pixels and more. I started with 222 failed tests and
> finished with 122 failed tests. Most of the tests I fixed were already working
> in llvmpipe BE, so I knew that at least the core mesa code is working. In
> accordance to that, most of the remaining failed tests also don't work in
> llvmpipe BE, so there is probably something more fundamentaly wrong there.
>
> Results of piglit tests are found in my fdo web folder:
> https://people.freedesktop.org/~gabbayo/piglit_results/r600g-big-endian/
>
> There are three comparisons, all of them done after reducing OpenGL version to
> 1.3:
>
> 1. r600g-1.3-base-le-vs-be -
>    Diff between LE and BE with upstream code to see the current status
>
> 2. r600g-1.3-le-vs-be -
>    Diff between LE and BE with upstream + patch-set to see the remaining tests
>    to be fixed
>
> 3. r600g-be-1.3-all-fixes -
>    Diff between upstream code and upstream + patch-set, both running in BE.
>    This shows all the tests my patch-set fixed (and no regressions)
>
> In addition, I of course checked for regressions on LE, without reducing OpenGL
> version.
>
> Thanks,
>
>    Oded
>
> Oded Gabbay (4):
>   r600g/radeonsi: send endian info to format translation functions
>   r600g: set endianess of 16/32-bit buffers according to do_endian_swap
>   r600g: use do_endian_swap in color swapping functions
>   r600g: use do_endian_swap in texture swapping function
>
>  src/gallium/drivers/r600/evergreen_state.c    | 42 ++++++++++++------
>  src/gallium/drivers/r600/r600_pipe.h          |  8 ++--
>  src/gallium/drivers/r600/r600_state.c         | 27 ++++++++----
>  src/gallium/drivers/r600/r600_state_common.c  | 62 ++++++++++++++++++++++-----
>  src/gallium/drivers/radeon/r600_pipe_common.h |  2 +-
>  src/gallium/drivers/radeon/r600_texture.c     | 24 +++++++----
>  src/gallium/drivers/radeonsi/si_state.c       |  4 +-
>  7 files changed, 122 insertions(+), 47 deletions(-)
>
> --
> 2.5.5
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev