On Thu, Aug 17, 2017 at 10:52 AM, Erik Faye-Lund <[email protected]> wrote: > On Wed, Aug 16, 2017 at 8:32 PM, Karol Herbst <[email protected]> wrote: >> Fixes 'KHR-GL45.copy_image.functional' on Nouveau >> >> Signed-off-by: Karol Herbst <[email protected]> >> --- >> src/mesa/main/format_utils.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/format_utils.c >> index d16d69c379..a3ddaebb2e 100644 >> --- a/src/mesa/main/format_utils.c >> +++ b/src/mesa/main/format_utils.c >> @@ -485,7 +485,11 @@ _mesa_format_convert(void *void_dst, uint32_t >> dst_format, size_t dst_stride, >> >> assert(src_integer == dst_integer); >> >> - if (src_integer && dst_integer) { >> + /* do a simply memcpy if applicable */ >> + if (dst_format == src_format && dst_stride == src_stride && >> + !dst_format_is_mesa_array_format && !rebase_swizzle) { >> + memcpy(dst, src, src_stride * height); >> + } else if (src_integer && dst_integer) { > > This sounds like it just makes the bug harder to trigger. What if the > format is the same, but the pitch isn't the same? Won't that cause the > same issue, just without the CTS picking it up?
Okay, I forgot to mention that we have a few formats where we never are able to reproduce the original data. Think about RGB9_E5_EXT and 0xc0000000 as the raw data. We lose the exponent while converting to RGBA and can't reproduce it anymore when converting back to RGB9_E5_EXT. Maybe somebody knows a much better way how to solve this issue? Or maybe it's simple CTS which is wrong by trying to read out the GPU memory with glGetTexImage? _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
