Hi Andreas,
On 30 March 2018 at 15:18, Andreas Müller <schnitzelt...@gmail.com> wrote:
> What happened: I build all images cross with Openembedded/Yocto. To
> prepare next release there I updated my builds and that moved mesa
> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g
> glmark2-es - tried others - same) complain with
>
> | Modifier 0x0 vs. tiling (0x700000000000001) mismatch
>
> and drawable region remains black.
> There was some discussion on meta-raspberrypi mailing list and it
> seems to happen to others too [1].
>
> I've attached a patch. That fixes glmark2-es and many others but e.g
> on KDE desktop mouse pointer is just pixel dust so I think that my
> (naive) approach only works around an issue caused somewhere else. To
> ne honest my background understanding is poor but it seems that
> modifier gets not properly for all cases.
Odd. That happens when something has already allocated the buffer as a
tiled buffer, but Mesa is being told that the buffer is linear. Are
you able to get a backtrace from when this error happens? (Either set
a breakpoint by hand, or just add 'uint32_t *crash = NULL; *crash =
1;' to force a segfault.)
I could only find one place where this would happen, which is when
using the old DRI2 interface with Gallium, but it really should be
using DRI3 ... nonetheless, does the attached patch help at all?
Cheers,
Daniel
diff --git a/src/gallium/state_trackers/dri/dri2.c b/src/gallium/state_trackers/dri/dri2.c
index 31d17d46c29..58a6757f037 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -806,6 +806,7 @@ dri2_allocate_textures(struct dri_context *ctx,
whandle.handle = buf->name;
whandle.stride = buf->pitch;
whandle.offset = 0;
+ whandle.modifier = DRM_FORMAT_MOD_INVALID;
if (screen->can_share_buffer)
whandle.type = DRM_API_HANDLE_TYPE_SHARED;
else
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
