Mir

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

Bug #1118903 reported by Daniel van Vugt on 2013-02-08
204
This bug affects 42 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Undecided
Unassigned
Mir
High
Unassigned
mesa (Ubuntu)
High
Unassigned
mir (Ubuntu)
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.

Daniel van Vugt (vanvugt) wrote :

See also: bug 1118909

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.

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.

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

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

Changed in unity-system-compositor:
status: Triaged → Incomplete
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
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)
Kai Mast (kai-mast) wrote :

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

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.

kevin gunn (kgunn72) wrote :

not critical for 13.10

Changed in xmir:
importance: Undecided → Medium
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.

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.

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

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

QA is still interested in rendering without gpu

kevin gunn (kgunn72) wrote :

hint, this would be a great community contribution

Changed in mir:
assignee: Daniel van Vugt (vanvugt) → nobody
description: updated

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

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.

I meant Android devices as opposed to desktop.

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

Why it is not fixed?

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.

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

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

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

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.

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
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers