On Wed, Jun 11, 2014 at 2:26 AM, Thomas Hellstrom <[email protected]> wrote: > On 06/09/2014 01:23 PM, Daniel Stone wrote: >> Hi, >> >> On 9 June 2014 12:06, Pekka Paalanen <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Mon, 9 Jun 2014 11:00:04 +0200 >> Benjamin Gaignard <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/wayland-devel&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=NHSSDNdXVt2oCxexwhcqQAQSZ3K6Xa8Zvuv0jMYfS2c%3D%0A&s=c4f94901274570868164b5aac297336d544bdba1bc12bda6c09b915fa5495423 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
