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

Bug #1118903 reported by Daniel van Vugt
268
This bug affects 53 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Triaged
High
Unassigned
Mir
Triaged
Medium
Unassigned
mesa (Ubuntu)
Invalid
High
Unassigned
mir (Ubuntu)
Triaged
High
Unassigned

Bug Description

As always, it's a critical requirement for Ubuntu to be able to render the same thing on any machine (metal or virtual), regardless of the availability of hardware acceleration.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

See also: bug 1118909

Revision history for this message
Chris Halse Rogers (raof) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

information type: Proprietary → Public
Changed in mir:
status: New → Confirmed
Revision history for this message
Robert Ancell (robert-ancell) wrote :

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

Changed in mir:
status: Confirmed → Triaged
importance: High → Wishlist
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mir:
importance: Wishlist → Medium
Revision history for this message
kevin gunn (kgunn72) wrote :

just bumping priority on this.

Changed in mir:
importance: Medium → High
assignee: nobody → Daniel van Vugt (vanvugt)
summary: - System compositor lacks a software rendering backend
+ Mir lacks a software rendering backend
Changed in unity-system-compositor:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Mir lacks a software rendering backend

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

Changed in unity-system-compositor:
status: Triaged → Incomplete
Revision history for this message
Robert Ancell (robert-ancell) wrote :

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.

Changed in unity-system-compositor:
status: Incomplete → Triaged
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Changed in xmir:
status: New → Triaged
assignee: nobody → Chris Halse Rogers (raof)
Revision history for this message
Kai Mast (kai-mast) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Revision history for this message
kevin gunn (kgunn72) wrote :

not critical for 13.10

Changed in xmir:
importance: Undecided → Medium
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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 :(

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

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

summary: - Mir lacks a software rendering backend
+ [feature] Mir lacks a software rendering backend
tags: added: feature
summary: - [feature] Mir lacks a software rendering backend
+ [enhancement] Mir lacks a software rendering backend
tags: added: enhancement
removed: feature
Revision history for this message
kevin gunn (kgunn72) wrote : Re: [enhancement] Mir lacks a software rendering backend

QA is still interested in rendering without gpu

Revision history for this message
kevin gunn (kgunn72) wrote :

hint, this would be a great community contribution

Changed in mir:
assignee: Daniel van Vugt (vanvugt) → nobody
description: updated
Revision history for this message
Cemil Azizoglu (cemil-azizoglu) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Cemil Azizoglu (cemil-azizoglu) wrote :

I meant Android devices as opposed to desktop.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mir:
milestone: none → 0.9.1
milestone: 0.9.1 → none
Revision history for this message
Robert Ancell (robert-ancell) wrote :

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

affects: xmir → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
status: Triaged → Fix Released
assignee: Chris Halse Rogers (raof) → nobody
tags: added: xmir
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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".

no longer affects: xorg-server (Ubuntu)
no longer affects: unity-system-compositor
Changed in mir:
assignee: nobody → Alexandros Frantzis (afrantzis)
status: Triaged → In Progress
milestone: none → 0.16.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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 :(

Changed in mir:
milestone: 0.16.0 → 0.17.0
tags: removed: xmir
Changed in mir:
status: In Progress → Triaged
milestone: 0.17.0 → none
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

Why it is not fixed?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mir (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in mir:
assignee: Alexandros Frantzis (afrantzis) → nobody
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mesa (Ubuntu):
importance: Undecided → High
tags: added: egl-platform-mir
Revision history for this message
Daniel van Vugt (vanvugt) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in mesa (Ubuntu):
status: New → Confirmed
tags: added: black-screen
summary: - [enhancement] Mir lacks a software rendering backend
+ [enhancement] Mir lacks a software rendering backend (and doesn't work
+ in virtual machines)
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

news?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

tags: added: unity8-desktop
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mesa (Ubuntu):
status: Confirmed → Invalid
tags: added: vm
Revision history for this message
Emanuele Antonio Faraone (emanueleant03) wrote :

News?

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mir:
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in canonical-devices-system-image:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Bryan Quigley (bryanquigley) wrote :

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

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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?).

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mir:
milestone: none → 1.0.0
kevin gunn (kgunn72)
Changed in canonical-devices-system-image:
milestone: none → u8c-1
assignee: nobody → Stephen M. Webb (bregma)
Changed in mir:
assignee: Daniel van Vugt (vanvugt) → Kevin DuBois (kdub)
status: Triaged → In Progress
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mir:
assignee: Kevin DuBois (kdub) → nobody
status: In Progress → Triaged
Revision history for this message
kevin gunn (kgunn72) wrote :

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

Changed in canonical-devices-system-image:
milestone: u8c-1 → u8c-2
Changed in mir:
milestone: 0.27.0 → 0.28.0
Changed in canonical-devices-system-image:
assignee: Stephen M. Webb (bregma) → nobody
Changed in mir:
importance: High → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.