exploring Mesa in Genode

[Norman Feske]

Hello Jamey,

welcome to the list! Great that you are interested in picking up the
GPU-related line of work.

I'd like to chime in because I conceived the original i915 GPU work 5
years ago.

On 10.08.2015 00:15, Jamey Sharp wrote:
> I was referring to the Genode "challenges" list, which mentions that
> "Genode 10.08 introduced Gallium3D including the GPU driver for Intel
> GMA CPUs." (I'm guessing this has bit-rotted somewhat since then? I
> haven't found where that code might live yet.)

The state of my original port is roughly explained in the release notes
of Genode 10.08:


http://genode.org/documentation/release-notes/10.08#Gallium3D_and_Intel%27s_Graphics_Execution_Manager

We maintained this state until spring this year when we decided to
abandon it until somehow becomes interested again. Now, just shortly
after, you are showing up. ;-)

The code is still there but not regularly tested or maintained. The
important pieces are:

* The port of the i915 GPU driver / the GEM subsystem of the Linux
  kernel. I ported the code via our DDE approach. But unlike all
  recent DDE-Linux-based drivers, the code resides in a separate
  repository:

  https://github.com/genodelabs/linux_drivers/tree/master/src/drivers/gpu

  We planned to add the revived version of this code to our new
  'repos/dde_linux' repository within the Genode tree but haven't
  done so yet.

* The port of libdrm:


https://github.com/genodelabs/genode/blob/master/repos/libports/ports/libdrm.port

https://github.com/genodelabs/genode/blob/master/repos/libports/lib/mk/libdrm.mk

https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/libdrm

  As you can see in ioctl.cc, the code implements ioctl by simply
  calling the corresponding function of the GPU driver. Normally,
  we'd need to redirect those calls via RPC. But in my setup, I
  just co-located the GPU driver + libdrm + gallium3d + application
  within a single component.

* Mesa / Gallium3d, which is part of 'repos/libports/'.

* A custom EGL driver to interface Mesa with Genode:


https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/egl

* An example application and a corresponding run script:


https://github.com/genodelabs/genode/tree/master/repos/libports/src/app/eglgears

https://github.com/genodelabs/genode/blob/master/repos/libports/run/eglgears.run

> It goes on to say that "the current approach executes the GPU driver
> alongside the complete Gallium3D software stack and the application code
> in one address space," which of course is undesirable for security, but
> also because it limits users to a single 3D client at a time.
> 
> I think what I want to do is:
> 
> - define an analogue of the Linux DRM API using Genode IPC,
> - port the Linux kernel generic DRM layer and the driver for Intel
>   integrated graphics to this IPC interface (as part of dde_linux I
>   guess?),
> - and port libdrm to the IPC interface.

I hope that the pointers above will serve you well as a suitable
starting point.

> I'm hoping that the libdrm abstraction layer is comprehensive enough
> that Mesa would not need much, if any, patching.

That it consistent with my experience. As far as I remember, I have not
modified Mesa at all.

> As you pointed out, I'd really like to wind up with a Wayland interface
> replacing Genode's Nitpicker. (Which is another wishlist item on the
> "challenges" page, I noticed.)

I do not think that the replacement of Nitpicker by something else is
strictly necessary as Nitpicker and Wayland share the same principle
architecture.

>> * There should probably be an intermediate resource management server
>> between the kernel/libdrm container and the app.
> 
> Agreed! In a complete implementation, something should keep track of how
> much video memory is available and share it fairly between clients.
> Bonus points if it also can provide a generic implementation of command
> scheduling, to keep any one client from starving other clients' access
> to the GPU.

I would refer to this component simply as "GPU driver". It would contain
both, the actual driver code that talks to the GPU and the code for
multiplexing the GPU. I think that, given the re-use of the Linux kernel
code, it would be quite difficult to separate those both concerns into
two distinct components.

> That said, I'm hoping to get a single-client demo working without any
> resource management first. :-)
> 
>> * You should think of whether you want to allow multiple clients to
>> access the same buffer simultaneously or make the access exclusive.
> 
> I think, to support the Wayland model, multiple clients need to be
> allowed to access the same buffer. But they shouldn't usually be trying
> to map the raw buffer contents into their local address space, right?
> That is a recipe for a performance disaster, especially on graphics
> cards with dedicated VRAM.

Buffer objects are mapped directly into the application's address
spaces. This is also the case on Linux where a custom page-fault handler
manages the part of the address space where the /dev/drm device node is
mapped via mmap. The code (and the overloading of the mmap arguments
with different semantics by the i915 driver) is quite frightening. But
in principle, the construct could work very similar on Genode where are
have a proper interface for managing (parts of) virtual address spaces
from a remote component. On Genode, each buffer object would be
represented as a dataspace. But let us keep this topic for later.

Have fun with you exploration! For giving the existing code a try, I
would recommend you to test a slightly older Genode version (like 14.11)
where the i915 GPU driver was still known to work.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth