there is (briefly) high cpu usage when launching 'weston' (under x11 with forced software rendering), and continuously as one moves the cursor around in that session. cpu usage is consistently around 30-40% on all cores as the cursor moves. otherwise, there is not much computation happening. without sw-rendering, this is not an issue under x11. when using weston-launch under a tty, in sw-rendering mode, there is no apparent performance hit, and htop shows no significant cpu usage. to force software rendering before launching weston: $ export LIBGL_ALWAYS_SOFTWARE=1 i'm using weston master.
Software rendering is surely consuming CPU for it's using CPU to do the job of rendering, which contains lots of calculation. It's only a fallback if GPU can't be used somehow. Even a simple opengl application can eat up ~40% of CPU on my machine if I use software rendering. In my knowledge, software rendering under DRM backend is not supported. You are using your gpu even if you specify LIBGL_ALWAYS_SOFTWARE, you can check your log for that.
Also, with the DRM backend, you are very likely using the hardware cursor. That means that just moving the cursor does not need to paint anything. You can disable that with Win+shift+space then 'c' key sequence for comparison, IIRC. Under x11, there is no hardware cursor being used, and every cursor position updates means repainting. Painting in software rendered GL is heavy. I have no idea what LIBGL_ALWAYS_SOFTWARE does to Weston with the DRM backend, so please always attach the full output from weston so we see what you are getting. Weston does not even use libGL, it's a GLESv2 program. You might have better luck triggering software rendering with EGL environment variables, but that means that it would fail to put the rendering on screen unless you have quite new EGL-DRM software rendering support patch set from mesa-devel (I'm not sure if it was merged yet).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.