On Fri, Jan 10, 2014 at 10:46 AM, Thomas Hellstrom <thellst...@vmware.com> wrote: > On 01/10/2014 04:23 PM, Rob Clark wrote: >> On Tue, Jan 7, 2014 at 1:37 PM, Thomas Hellstrom <thellst...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
