Client persistence across GPU hotexchange

Pekka Paalanen ppaalanen at gmail.com
Thu Sep 18 00:47:42 PDT 2014


On Wed, 17 Sep 2014 21:11:53 +0400
Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote:

> Good day, folks!
> 
> I'd like some light to be shed on the general area of GPU
> hotplug/hotremoval, and in particular, on how this is supposed to affect
> client persistence.
> 
> What is the state of multi-card output?

Which software components do you want to know about? In Weston it is
not implemented, only one card gets used per running Weston instance.

> Is it possible to have drm_outputs replaced with (non-GL) clients surviving?
> 
> A specific scenario I have in mind is:
> 
>   - weston initially starts with an accelerated DRM device (#1)
>   - some fairly pedestrian (plain GTK/Qt) clients start
>   - a dumb framebuffer DRM device (#2) is hot-added
>   - the accelerated device (#1) is removed

Weston does not support any hot-add or removal at the moment.

Do you mean that the clients actually use hardware acceleration?

If they don't, I don't see any problem for the clients as there is
nothing to be communicated or reinitialized. It would be purely a
compositor thing. But that is not an interesting case, so let's assume
acceleration was indeed used.

> Is it possible to even express this with the current infrastructure?

I'm not sure, I suppose EGL had some things to signal that the context
is lost, but I don't know if that is enough.

It is up to apps/toolkits to handle the loss of context.

> What is the estimate for the survival of the clients, if so?

I would guess zero right now.

I believe a more pressing matter is to support multiple GPUs in the
first place through the whole stack, before starting to hot-plug them.
A part of that problem is how the details of passing buffers between
different GPUs are solved, which I think is still a somewhat open
question. Dmabuf can pass bags of bytes, but the interpretation details
and synchronization are unsolved or WIP, AFAIK.

Sorry I couldn't be more helpful.


Thanks,
pq


More information about the wayland-devel mailing list