Re: [PATCH] drm/vgem: implement virtual GEM

[Thomas Hellstrom <thellstrom@vmware.com>]

On 05/21/2015 04:19 PM, Rob Clark wrote:
> On Thu, May 21, 2015 at 9:49 AM, Thomas Hellstrom <thellstrom@vmware.com> wrote:
>> On 05/21/2015 11:13 AM, Daniel Vetter wrote:
>>> On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote:
>>>> On 11/25/2014 02:08 AM, Zachary Reizner wrote:
>>>>> After looking into removing platform_device, I found that using
>>>>> dma_buf_attach with a NULL device always returns an error, thereby
>>>>> preventing me from using VGEM for import and mmap. The solution seems
>>>>> to be to skip using dma_buf_attach, and instead use dma_buf_mmap when
>>>>> user-space tries to mmap a gem object that was imported into VGEM. The
>>>>> drawback to this approach is that most drivers stub their
>>>>> dma_buf_ops->mmap implementation. Presumably mmap could be implemented
>>>>> for the drivers that this would make sense for. Are there any
>>>>> comments, questions, or concerns for this proposed solution?
>>>> I see now that this driver has entered -next, and I'm sorry this comment
>>>> didn't arrive before. I simply missed this discussion :(
>>>>
>>>> My biggest concern, as stated many many times before, is that dma-buf
>>>> mmap is a horrible interface for incoherent drivers, and for drivers
>>>> that use odd format (tiled) dma-bufs, basically since it doesn't supply
>>>> a dirtied region. Therefore (correct me if I'm wrong) there has been an
>>>> agreement that for purposes outside of ARM SOC, we should simply not
>>>> implement dma-buf mmap for other uses than for internal driver use.
>>>>
>>>> So assume a real driver implements dma-buf mmap, but it is crawling due
>>>> to coherency- or untiling / tiling operations. How do you tell a generic
>>>> user of the vgem driver *NOT* to mmap for performance reasons? Or is
>>>> this driver only intended for ARM SOC systems?
>>> Seconded. Somehow I thought we've pulled in vgem to support software
>>> rendering like llvmpipe, and I remember that that's been the original
>>> justification. TIL that that's indeed not the case and google is
>>> splattering their cros tree with dma_buf->mmap implementations this is
>>> obviously not the case and the intention really seems to be to use
>>> dma_buf->mmap and vgem as the generic interface to expose buffer objects
>>> of real drivers to software rendering.
>>>
>>> Given that neither vgem nor dma_buf->mmap has any sane concept of handling
>>> coherency I'm really unhappy about this and tempted to just submit the
>>> revert for vgem before 4.1 ships. I'll chat with relevant people a bit
>>> more. Worse I chatted with Stephane today and he brushed this off as
>>> not-my-problem and if this hurts intel intel should fix this. That's not
>>> how a proper usptream interface is getting designd, and coherency handling
>>> is an even more serious problem on arm an virtual hw like vmwgfx.
>> So given how this has turned out, my opinion is that before a usable
>> generic mmap of accelerated buffer objects
>> goes upstream, there should be a proper interface to request regions
>> present and to dirty regions. It seems to me that so far
>> all use-cases are for one- or two-dimensional access so it should be
>> sufficient to start with that and add other access
>> modes later on. Now this is no guarantee that people won't request and
>> dirty the whole dma-buf on each access, but at least
>> that would make people think, and if things become slow it's pretty
>> clear where the problem is.
>>
>> I'm all for delaying vgem until we have such an interface in place.
> so, for llvmpipe use-case, I think dri2 is sufficient.  So why don't
> we just drop DRIVER_PRIME flag for now..
>
> BR,
> -R

Fine with me!

/Thomas



>
>> Thanks,
>> Thomas
>>
>>
>>
>>
>>>  On intel
>>> (well at least big core thanks to the huge coherent cache fabric) this is
>>> mostly a non-issue, except that the patch in the cros tree obviously gets
>>> things wrong.
>>>
>>> Decently pissed tbh.
>>>
>>> Cheers, Daniel
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=sLK_B5IzlsF7zUqLCrxPQUtxzZt77RtzKxrZaJGYews&s=tfXDNoFQ1d044YyOewiTg_Qa0gsSvjOZGT603lZtZVo&e= 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel