[enhancement] Mir lacks a software rendering backend (and doesn't work in virtual machines)

See also: bug 1118909

I'm not sure if we actually *do* need to be able to run without hardware acceleration.

We certainly need, *in Ubuntu*, to handle the case where there's a problem with the graphics driver configuration or whatever. It's less clear to me that the solution to this is for Mir to handle it.

I think being able to run Ubuntu in a VM is important. It would be a big call to drop that ability.

Please note: It would probably be a bad idea to resolve this bug before bug 1118909 is addressed.

Setting to wishlist - there is not a requirement to run without EGL support that I know of.

I think Medium is a better compromise. You can't make the unity system compositor the default one for Ubuntu unless it works in VMs too. So it's critical in the long run, but only medium now because the Mir-based system compositor won't be default for a while.

just bumping priority on this.

I don't see anything specific to unity-system-compositor here... ?

The requirement is both unity-system-compositor and XMir can run with software rendering. The solution is for Mir to implement this and both u-s-c and XMir to make use of this functionality.

OK, but no change whatsoever is required in unity-system-compositor, AFAIK.

Some change will be required in XMir though. We now have the XMir project for that.

What about LLVMpipe? This should really be handled by mesa.

Yes, using LLVMpipe is the plan. But LLVMpipe needs a screen to render to. So Mir needs to be modified to provide that.

not critical for 13.10

Please not fbdev. Most recent article I could find on this: http://www.phoronix.com/scan.php?page=news_item&px=MTM5MDc

Ideally we would be moving to a KMS based VESA/EUFI driver.

Bryan,

Thanks for pointing that out. It led me to find this, which would certainly be preferable if it's mature enough;
http://lists.freedesktop.org/archives/dri-devel/2013-January/034058.html

Not sure. I'm not working on this task yet.

It seems KMS support for VBE is effectively non-existent (never landed and was never finished anyway). Red Hat too, are planning for vesa/fbdev being their fallback:

https://lists.fedoraproject.org/pipermail/devel/2013-August/188429.html

No one wants to use fbdev, but it is apparently still the only software rendering interface to that works /everywhere/. I hope to be proven wrong :(

Seems like it's still being worked on (or at least something similar, by the same author), and maybe pushing for mainline in 3.12.
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1MTM
http://lists.freedesktop.org/archives/dri-devel/2013-September/044638.html

QA is still interested in rendering without gpu

hint, this would be a great community contribution

What about touch devices? Is this a requirement for them too?

Mir (conveniently) maintains no relationship between input devices (touch screens) and display devices.

So yes, a full software rendering solution should still work on touch devices (or anything with a basic framebuffer). Whether "touch" works at the same time is up to our input/evdev support. So "touch" isn't related to this bug.

I meant Android devices as opposed to desktop.

The "Android device" distinction is actually just a platform where our "android" graphics driver works. A software rendering solution would likely be either a new driver, or an augmentation of the "mesa" driver. So when software mode's in use the "android" driver would be removed from the equation. It wouldn't matter at all what kind of device you run it on, so long as the device provides a basic framebuffer with the interfaces we use (not decided yet).

So yeah, any device should be supported by software mode, in theory.

The new XMir uses glamor so (correct me if I'm wrong) it can run with a software driver.

XMir really is not related to this bug any more. It was only linked from back when XMir was going to be our desktop.

In reality a Mir server is just as able to use LLVMpipe as any other GL app. But we're still lacking a screen to render to or "software mode setting".

Also coming soon in newer kernels: http://phoronix.com/scan.php?page=news_item&px=VirtIO-GPU-3D-Virgl

Sadly it's not the generic solution (to work on any machine/hypervisor) that fbdev would have provided :(

Why it is not fixed?

Our attention is mostly on mobile right now. Of course this bug is a blocking issue for desktop, so it will get resolved.

Three main pieces I can think of right now:

  1. Buffer type: In progress now: https://code.launchpad.net/~raof/mir/make-shmbuffer-into-common-code/+merge/290397

  2. GL support: Should be easy as resolving Mesa bug 1543952

  3. Mode setting: The greatest point of contention as the traditional (and only existing) solution of fbdev is also considered deprecated. So we kind of are waiting for newer kernel features that don't yet exist, or need to settle on using existing but deprecated kernel features. Assuming Mesa hasn't already deprecated support for them too.

Status update...

GL Support:
DONE: Verified LLVMpipe supports Mir's default GL renderer (see bug 1576032)

Client buffers:
DONE: We have separated ShmBuffer into generic code so all graphics drivers can use it.
TODO: Add support for rendering GL from LLVMpipe to ShmBuffers instead of GBM (see bug 1576032)

Server display buffers:
TODO: Add support for rendering GL from LLVMpipe to DRM dumb buffers (see bug 1575516), or something fb-ish.

Mode setting:
Stuck between a rock and a hard place. Mesa dropped support for fbdev last year [1]. Meanwhile, its likely replacement has fallen silent and nothing has landed [2].

[1] https://lists.freedesktop.org/archives/mesa-commit/2015-March/055567.html
[2] https://lists.freedesktop.org/archives/dri-devel/2014-January/052584.html

Is this what we need?
https://www.khronos.org/registry/egl/extensions/MESA/EGL_MESA_drm_image.txt

Mode setting might not be as stuck as I thought.

If LLVMpipe can be directed to render to an arbitrary bitmap then we could simply write a Mir graphics driver for fbdev and bind LLVMpipe to it.

Status changed to 'Confirmed' because the bug affects multiple users.

news?

We appreciate your enthusiasm. If there was more news you would see it here.

The development team is meeting this week to discuss and prioritise such desktop issues.

I'm tempted to separate the recent duplicates from VirtualBox users where Mir only crashes with 'Failed to schedule page flip'. That issue we might be able to fix separately and sooner than fully resolving this bug.

With some hints from RAOF I think this is doable now...

1. Write a Mir driver that does basic modesetting on fbdev
2. For GL support use http://www.mesa3d.org/osmesa.html

I've separated the more recent duplicate bugs on VirtualBox where Mir is starting OK (there are sufficient DRM resources) but then crashing. I think that will inevitably require a separate fix -> bug 1584894.

Further to comment #30, the "preferred" solution of SimpleDRM is making a comeback (but doesn't yet exist in anyone's kernel):
  https://lists.freedesktop.org/archives/dri-devel/2016-August/114861.html

It doesn't have to be the only option though. We can still do an fbdev+osmesa driver in the meantime that will work with current kernels instead of having to wait for some future kernel.

News?

I've found I can get Unity8 to render in virt-manager (Qemu/KVM) with Display set to Spice and Video: QXL.

That might be a faster target (for QA) then getting full software rendering. The only showstopper is the mouse doesn't let me go across the entire screen. It seems what Mir says is the screen is different than what the virt-viewer thinks.

Indeed, the current state of VM support for Mir/Unity8 is:

(1) QXL works already (modulo that mouse problem, please log a new bug)
(2) VirtualBox will be next (aiming before 17.04): bug 1584894
(3) Generalised software rendering on fbdev or SimpleDRM later (still hoping for 17.04): this bug 1118903

- mouse problem reported as unity8 bug 1636901 - let me know if I should reassign to mir.

Another interesting idea:
If we implement a headless driver (discussed today) with GL support (OSMesa) then that gets us halfway to resolving this bug. Then all that's required is to replace the headless output with a linear framebuffer device (which fbdev is?).

This is a stretch goal in 1.0.0 for me. Please don't take the milestone to mean a definite plan.

Unassigned, because technically kdub is working on the prerequisite work only right now. And I don't want to get into the situation again where we are arguing over whether VM support is "done". So will assign this when the plan is closer to completion.

if so many caveats, then lets not target u8c-1