Hi, Peter,
Please see inline.
On 03/27/2017 10:37 AM, Peter Hanzel wrote:
> Hello.
>
> I have downloaded kmscube from git://anonogit.freedesktop.org/mesa/kmscube.
> I have tried it inside VMware with vmwgfx acceleration.
>
> The smooth mode works correctly and I see rotating cube.
> But I have also tried textured cube (-M rgba) and this doesn't work in vmwgfx.
>
> it asserts in init_tex_rgba: Assertion 'img' failed.
> The I compiled mesa in debug mode
> And this is the cause:
> svga_texture_from_handle wrong format SVGA3D_R8G8B8A8_UNORM !=
> SVGA3D_B8G8R8A8_UNORM.
>
> So I change the code in cube-tex.c
> in init_tex_rgba in EGLint attr[]
> from:
> EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_ABGR8888
> to:
> EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_ARGB8888
Thanks for the problem report. The vmwgfx driver is substantially
pickier about imported buffer formats than many other drivers,
and we're currently looking at that but no immediate quick fix other
than changing the format in the kmscube code as you have done
>
> Then I see the rotating cube but texture is all black.
>
> I tested the rgba mode on raspberry pi with Eric Anholt's vc4 driver
> and the texture mode works normally and I see texture.
>
> What can be a problem?
As for the rgba mode, there appears to be a bug in kmscube / gbm / dri2
state tracker in that when the newly created gbm bo is mapped, the
mapping context is never flushed before the gbm bo is exported. This
makes the mapping DMA-like operation remain in that context's queue and
the texture will never be initialized. Since there doesn't appear to be
a way to flush gbm, I think the fix needs to be in gbm rather than in
kmscube, where it otherwise would be natural to place a flush. Please
see attached diff.
Thanks,
Thomas
>
> Thanks.
> _______________________________________________
> mesa-dev mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index ac7ede8..6c2244c 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -243,7 +243,7 @@ struct dri_extension_match {
};
static struct dri_extension_match dri_core_extensions[] = {
- { __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
+ { __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
{ __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
{ __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
{ __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
@@ -992,6 +992,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
return;
dri->image->unmapImage(dri->context, bo->image, map_data);
+
+ /*
+ * Not all DRI drivers use direct maps. They may queue up DMA operations
+ * on the mapping context. Since there is no explicit gbm flush
+ * mechanism. We need to flush here.
+ */
+ dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 0);
}
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
