Server: CPU Accelerator?

[ronag]

Should we keep maintaining the CPU accelerator? What use cases is there for it? Is it worth it?

I can see some advantage in removing it. If we can remove the whole accelerator abstraction and natively support opengl in producer and consumers without having to make up complicated abstractions. This would e.g. make the scene_producer, psd_producer, text_producer etc... a lot simpler to implement if they can use OpenGL directly.

@5opr4ni @sesse @Julusian @dotarmin @TomKaltz @niklaspandersson

[sesse]

The use case for my part is simple; I don't need a mixer at all, I just push a single CEF layer out. So pulling the texture data to the GPU and back means only extra CPU and GPU load I don't need.

I guess the original intended use was running on cloud instances without GPUs. I can't comment on whether that still makes sense or not.

[ronag]

@sesse That kind of makes sense from a performance perspective but I'm not sure that it makes it worth it in terms of development and maintenance. It still works.

Though the cloud thing is a valid point though and doesn't have any other workaround. Question is whether this is something we should aim to support?

[sesse]

Well, cloud also has a workaround; you can use LLVMpipe or OpenSWR. It will be slow, though.

I'm not particularly personally attached to having the CPU mixer in mainline—I forked off my own private branch a while ago, and it's unlikely I will be rebasing anytime soon.

[ronag]

We could add support for multiple opengl context support which would allow us to implement scene_producer, psd_producer, text_producer based on OpenGL directly and simply transfer the result to the mixer context. Maybe that is a better path.