On 06/09/2014 01:23 PM, Daniel Stone wrote:
Hi,
On 9 June 2014 12:06, Pekka Paalanen <pekka.paalanen@collabora.co.uk mailto:pekka.paalanen@collabora.co.uk> wrote:
On Mon, 9 Jun 2014 11:00:04 +0200 Benjamin Gaignard <benjamin.gaignard@linaro.org <mailto:benjamin.gaignard@linaro.org>> wrote: > One of the main comment on the latest patches was that wl_dmabuf use > DRM for buffer allocation. > This appear to be an issue since wayland doesn't want to rely on one > specific framework (DRM, or V4L2) for buffer allocation, so we have > start working on a "central dmabuf allocation" on kernel side. The > goal is provide some as generic as possible to make it acceptable by > wayland. Why would Wayland need a central allocator for dmabuf?
I think you've just answered your own question further below:
> On my hardware the patches you have (+ this one on gstwaylandsink > https://bugzilla.gnome.org/show_bug.cgi?id=711155 <https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.gnome.org/show_bug.cgi?id%3D711155&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0A&s=f6d8c24d7fa4ccdacae79aeaa8221773d892350a191f96cb3bab4f542fb3ad1c>) allow me to do zero > copy between the hardware video decoder and the display engine. I > don't have implemented GPU yet because my hardware is able to do > compose few video overlays planes and it was enough for my tests. Right. What I have been thinking is, that the compositor must be able to use the new wl_buffer and we need to guarantee that before-hand. If the compositor fails to use a wl_buffer when the client has already attached it to a wl_surface and it is time to repaint, it is too late and the user will see a glitch. Recovering from that requires asking the client to provide a new wl_buffer of a different kind, which might take time. Or a very rude compositor would just send a protocol error, and then we'd get bug reports like "the video player just disappears when I try to play (and ps. I have an old kernel that doesn't support importing whatever)". I believe we must allow the compositor to test the wl_buffer before it is usable for the client. That is the reason for the roundtrippy design of the below proposal.
A central allocator would solve these issues, by having everyone agree on the restrictions upfront, instead of working out which of the media decode engine, camera, GPU, or display controller is the lowest common denominator, and forcing all allocations through there.
One such solution was discussed a while back WRT ION: https://lwn.net/Articles/565469/ https://urldefense.proofpoint.com/v1/url?u=https://lwn.net/Articles/565469/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0A&s=36b71b58f7fc6f3d594529cc674364a23718e5cbb38a439e4a9c628848a13b3a
See the 'possible solutions' part for a way for people to agree on restrictions wrt tiling, stride, contiguousness, etc.
Hi!
I think before deciding on something like this, one needs also to account for the virtual drivers like vmwgfx.
Here, a dma-buf internally holds an opaque handle to an object on the host / hypervisor, and the actual memory buffer is only temporarily allocated for dma-buf operations that strictly need it. Not to hold the data while transferring it between devices or applications.
Let's say you'd want to use a USB display controller in a virtual machine with the vmwgfx exported prime objects, for example. There's no common denominator. The vmwgfx driver would need to read the dma-buf data from the host object at sg-table export (dma-buf map) time.
Whereas if you just want to share data between a wayland server and client, no pages are ever allocated and the only thing passed around is in effect the opaque handle to the host / hypervisor object.
I'm currently having trouble seeing how a central allocator would be able to deal with this?
/Thomas
Cheers, Daniel
wayland-devel mailing list wayland-devel@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mail...
On Wed, Jun 11, 2014 at 2:26 AM, Thomas Hellstrom thellstrom@vmware.com wrote:
On 06/09/2014 01:23 PM, Daniel Stone wrote:
Hi,
On 9 June 2014 12:06, Pekka Paalanen <pekka.paalanen@collabora.co.uk mailto:pekka.paalanen@collabora.co.uk> wrote:
On Mon, 9 Jun 2014 11:00:04 +0200 Benjamin Gaignard <benjamin.gaignard@linaro.org <mailto:benjamin.gaignard@linaro.org>> wrote: > One of the main comment on the latest patches was that wl_dmabuf use > DRM for buffer allocation. > This appear to be an issue since wayland doesn't want to rely on one > specific framework (DRM, or V4L2) for buffer allocation, so we have > start working on a "central dmabuf allocation" on kernel side. The > goal is provide some as generic as possible to make it acceptable by > wayland. Why would Wayland need a central allocator for dmabuf?
I think you've just answered your own question further below:
> On my hardware the patches you have (+ this one on gstwaylandsink > https://bugzilla.gnome.org/show_bug.cgi?id=711155 <https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.gnome.org/show_bug.cgi?id%3D711155&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0A&s=f6d8c24d7fa4ccdacae79aeaa8221773d892350a191f96cb3bab4f542fb3ad1c>) allow me to do zero > copy between the hardware video decoder and the display engine. I > don't have implemented GPU yet because my hardware is able to do > compose few video overlays planes and it was enough for my tests. Right. What I have been thinking is, that the compositor must be able to use the new wl_buffer and we need to guarantee that before-hand. If the compositor fails to use a wl_buffer when the client has already attached it to a wl_surface and it is time to repaint, it is too late and the user will see a glitch. Recovering from that requires asking the client to provide a new wl_buffer of a different kind, which might take time. Or a very rude compositor would just send a protocol error, and then we'd get bug reports like "the video player just disappears when I try to play (and ps. I have an old kernel that doesn't support importing whatever)". I believe we must allow the compositor to test the wl_buffer before it is usable for the client. That is the reason for the roundtrippy design of the below proposal.
A central allocator would solve these issues, by having everyone agree on the restrictions upfront, instead of working out which of the media decode engine, camera, GPU, or display controller is the lowest common denominator, and forcing all allocations through there.
One such solution was discussed a while back WRT ION: https://lwn.net/Articles/565469/ https://urldefense.proofpoint.com/v1/url?u=https://lwn.net/Articles/565469/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0A&s=36b71b58f7fc6f3d594529cc674364a23718e5cbb38a439e4a9c628848a13b3a
See the 'possible solutions' part for a way for people to agree on restrictions wrt tiling, stride, contiguousness, etc.
Hi!
I think before deciding on something like this, one needs also to account for the virtual drivers like vmwgfx.
Here, a dma-buf internally holds an opaque handle to an object on the host / hypervisor, and the actual memory buffer is only temporarily allocated for dma-buf operations that strictly need it. Not to hold the data while transferring it between devices or applications.
Let's say you'd want to use a USB display controller in a virtual machine with the vmwgfx exported prime objects, for example. There's no common denominator. The vmwgfx driver would need to read the dma-buf data from the host object at sg-table export (dma-buf map) time.
Whereas if you just want to share data between a wayland server and client, no pages are ever allocated and the only thing passed around is in effect the opaque handle to the host / hypervisor object.
I'm currently having trouble seeing how a central allocator would be able to deal with this?
well, central standalone allocator device would need to know about all possible devices. Works ok in a cell phone. I don't really see it scaling well to desktop, so it isn't really an option.
BR, -R
/Thomas
Cheers, Daniel
wayland-devel mailing list wayland-devel@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mail...
linaro-mm-sig@lists.linaro.org