10-bit color support drastically reduced performance

[chrisduerr]

10-bit color support drastically reduced performance

[Drakulix]

I propose an API change, that makes it possible to query supported capabilities and to initialize the GlesRenderer with a set of requested capabilities (which fails if the requested ones aren't available).
If you are not using color transformations and you are never dealing with anything else, but 8-bit buffers, or your hardware is simply too slow, you can just drop the capability. But especially the types of buffers the compositor advertises or "too slow" implementations of set apis are nothing the renderer can figure out itself, so a user-driven approach seems to make sense here.

[chrisduerr]

I've been able to confirm that this line causes the performance issues:

smithay/src/backend/renderer/gles/mod.rs

Line 587 in fa58fec

capabilities.push(Capability::ColorTransformations);

[chrisduerr]

That would work fine for me. I don't care manual configuration of this.

[chrisduerr]

@Drakulix I was hoping you'd have some time to implement this, but if this is not the case could you go into some more detail of what you'd expect the changes to look like so I can fix these performance issues?

[Drakulix]

@Drakulix I was hoping you'd have some time to implement this, but if this is not the case could you go into some more detail of what you'd expect the changes to look like so I can fix these performance issues?

Sure thing, so the main thing to do here is splitting up GlesRenderer::new into two functions.

The current function is evaluating the feature-set to be used in this part of the code: https://github.com/Smithay/smithay/blob/master/src/backend/renderer/gles/mod.rs#L515-L603.

A new function (evaluate_capabilities? possibly a method of the Capability-type) would do essentially this and just return the capabilities array.

The new function would take a new capabilities-argument and compare the requested capabilities with the ones available. (So initializing the renderer in anvil would now evaluate the capabilities twice, but I don't think that is a huge issue. If one would want to avoid that, the new argument could be an Option, where None essentially means the previous behaviour of enabling everything possible.)

If the requested capabilities are not available, this has to throw a new error. Compositors like catacomb could then either hard-code as set of capabilities or dynamically drop the ColorTransformation-cap from the listed set for better performance.

This has a few remarks for the remaining renderers, that can wrap the GlesRenderer:

• The GlowRenderer needs to pass-through the capability arguments.
• The MultiRenderers EglGlesBackend and GbmGlesBackend platforms initialize GlesRenderers internally. They would probably need to take closure on construction and store that boxed, that returns a set of capabilities for maximum flexibility. Failing to request a given set of capabilities should likely not bring the whole MultiRenderer down, but simply log a warning and skip over the failed device in the platforms enumerate functions.

[cmeissl]

fixed by #1055