Mir on vmwgfx

[Thomas Hellstrom]

Hi Alexandros.
Thanks for responding.

On 11/05/2013 11:04 AM, Alexandros Frantzis wrote:
>
>> 4) vmwgfx does not yet implement the drm "Prime" mechanism for
>> sharing of dma buffers, which Mir relies on. I'm about to implement
>> that.
>> However, it seems like Mir is using dma buffers in an illegal way:
>> 1) Mir creates a GBM bufffer.
>> 2) Mir uses Prime to export a dma_buf handle which it shares with
>> its clients.
>> 3) The client imports the dma_buf handle and uses drm to turn it
>> into a drm buffer handle.
>> 4) The buffer handle is typecast to a "dumb" buffer handle, and then
>> mmap'ed. in struct GBMMemoryRegion : mcl::MemoryRegion.
>>
>> It's illegal to typecast a GBM buffer to a dumb buffer in this way.
>> It accidently happens to work on the major driver because deep
>> inside, both a GBM buffer and a dumb buffer is represented by a GEM
>> buffer object. With vmwgfx that's not the case either for a GBM
>> buffer or a dumb buffer, and they are different objects.
> This code path (i.e. mmap-ing the buffer on the client side) is only
> valid when the client has requested a "software" buffer, which on the
> server side leads to the creation of a "dumb" DRM buffer (i.e., with
> DRM_IOCTL_MODE_CREATE_DUMB). Although mmaping non-dumb buffers doesn't
> fail per se with the major hardware drivers, the returned pixel data
> usually has a non-linear layout (e.g. some sort of tiling), so it's not
> really usable for our purpose.

Ah, that sounds good to hear! Will save us a lot of pain.

>
> Note that the Mesa codebase we are using has some changes in the GBM code
> (experimental, not upstream yet). Notably:
>    * we allow creation of "dumb" drm buffers of arbitrary size (not just 64x64)
>      when using GBM_BO_USE_WRITE

It depends on the intended use-case. Currently these buffers are meaningful
and intended only as cursors when created from GBM, and the vmwgfx cursor
code will currently refuse any other cursors than 64x64 sized ones, but I
think that could be relaxed. Need to check internally.

>    * gbm buffers backed by a "dumb" DRM buffer also get a DRIimage

Again that depends on the use-case. Is there any coherence assumed or 
data-transfer
going on between the dumb drm buffer and the DRIimage? Or are you using 
it to be
able to render to cursors?

>
> We have found that the major hardware drivers support these changes.
> Do they pose a problem for the VMware driver?

Thanks,
Thomas


> See http://github.com/RAOF/mesa/ for the changed code base. It's still
> based on the Mesa version shipped in Ubuntu 13.10, but we plan to rebase
> on a more recent version.
>
> Thanks,
> Alexandros