[PATCH v4 3/3] compositor-drm: allow to be a wl_dmabuf server

[Rob Clark]

On Fri, Jan 10, 2014 at 10:46 AM, Thomas Hellstrom
<thellstrom at vmware.com> wrote:
> On 01/10/2014 04:23 PM, Rob Clark wrote:
>> On Tue, Jan 7, 2014 at 1:37 PM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>>> Conclusion: Avoid using dma-buf mmap() outside of drivers that know
>>> exactly what they are
>>> doing, and avoid it at all cost.
>>
>> well, to be fair, if you are using a gpu on the client side and pixman
>> backend on the server side, you probably deserve the results.
>>
>> Not to say that we shouldn't come up with a better way for sw access
>> to dmabuf, but just saying there are folks out there who would find
>> Benjamin's patch useful in it's current state (for example, platforms
>> where you have open src bits for video decoder but not for gpu).
>>
>> So I wouldn't block this patch strictly because we don't have a better
>> mmap story yet.
>
> I'm not sure I am in a position to block anything here, but in any case
> I disagree.
>
> Simply because if we allow this now, I'm quite sure it will spread
> because there are other people that will find this useful and use this
> implementation as an example and a motivation for doing the same thing
> in other places.
> IMHO to allow dma-buf mmap into generic code, it needs to be accompanied
> by a damage interface that is mandatory and makes people think twice.

Perhaps it would be worth including with this code a comment
explaining that cpu access like this to buffers shared with a gpu is
going to be a pretty bad slow-path..  for this particular case, I
don't see any problem, since sw composition of gpu rendered content is
a pretty lame idea.  But the warning comment would discourage against
using this approach more widely.

BR,
-R

> /Thomas
>
>
>
>
>>
>> BR,
>> -R