On Fri, Jan 10, 2014 at 10:46 AM, Thomas Hellstrom thellstrom@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@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