On Thursday, November 15, 2018 6:11 PM, Philipp Zabel <p.za...@pengutronix.de> wrote: > Hi Pekka, > > thank you for the explanation.
Hi, Thanks Pekka for clarifying. > On Wed, 2018-11-14 at 11:03 +0200, Pekka Paalanen wrote: > [...] > > The hints protocol we are discussing here is a subset of what > > https://github.com/cubanismo/allocator aims to achieve. Originally we > > only concentrated on getting the format and modifier more optimal, but > > the question of where and how to allocate the buffers is valid too. Is > > it in scope for this extension is the big question below. > > My guess is: probably not. Either way, I'd prefer the protocol docs to > be explicit about this. > > > Ideally, the protocol would do something like this: > > > > - Tell the client which device and for which use case the device must > > be able to access the buffer at minimum and always. > > > > - Tell the client that if it could make the buffer suitable also for a > > secondary device and a secondary use case, the compositor could do a > > more optimal job (e.g. putting the buffer in direct scanout, > > bypassing composition, or a hardware video encoder in case the output > > is going to be streamed). > > > > We don't have the vocabulary for use cases and there are tons of > > different details to be taken into account, which is the whole point of > > the allocator project. So we cannot do the complete solution here and > > now, but we can do an approximate solution by negotiating pixel > > formats and modifiers. > > > > The primary device is what the compositor uses for the fallback path, > > which is compositing with a GPU. > > > > Therefore at very minimum, clients > > need to allocate buffers that can be used with the primary device. We > > guarantee this in the zwp_linux_dmabuf protocol by having the > > compositor test the buffer import into EGL (or equivalent) before it > > accepts that the buffer even exists. The client does not absolutely > > necessarily need the primary device for this, but it will have much > > better chances of making usable buffers if it uses it for allocation at > > least. > > So the client must provide buffers that the primary device can import > and sample a texture from, ideally directly. > Can something like this be added to the interface description, to make > it clear what the primary device actually is supposed to be in this > context? This seems sensible, I'll do that. > > The primary device also has another very different meaning: the > > compositor will likely be using the primary device anyway so it is kept > > active and if clients use the same device instead of some other device, > > it probably results in considerable power savings. IOW, the primary > > device is the preferred rendering device as well. Or so I assume, these > > two concepts could be decoupled as well. > > And the client should default to using the same primary device for > rendering for power savings. Will be in the next version, but with "can" instead of "should", because some clients (games with DRI_PRIME) might want to use another device to get better performance. > > A secondary device is optional. In system where the GPU and display > > devices are separate DRM devices, the GPU will be the primary device, > > and the display device would be the secondary device. So there seems to > > be a use case for sending the secondary device (or devices?) in > > addition to the primary device. > > > > AFAIK, the unix device memory allocator project does not yet have > > anything we should be encoding as a Wayland extension, so all we seem > > to be able to do is to deliver the device file descriptors and the > > format+modifier sets. > > Ok. > > > Now the design question: do we want to communicate the secondary > > devices in this extension? Quite likely we need a different extension > > to be used with the allocator project. > > As long as the use case is not clear, I'd say leave it out. > A "secondary_device" event may be added later with a version update if > needed. Yes, I agree, I'd prefer not having this in the protocol for now. > > My current opinion is that if there is no generic way for an > > application to benefit from the secondary device fd, then we should not > > add secondary devices in this extension yet. > > I agree. +1 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel