[Mesa-dev] kmscube on vmwgfx

Peter Hanzel hanzelpeter at gmail.com
Tue Mar 28 12:56:24 UTC 2017


Hello.

I have attached patch and it works now.

So thank you very much and hopefully the others will find a way to fix
it in mesa-dev.

On Tue, Mar 28, 2017 at 2:46 PM, Thomas Hellstrom <thomas at shipmail.org> wrote:
> 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
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>


More information about the mesa-dev mailing list