exploring Mesa in Genode

[Jamey Sharp]

On Sun, Aug 02, 2015 at 07:33:07PM +0300, Alexander Tarasikov wrote:
> Hi Jamey!
> 
> Welcome to Genode. I'm also interested in 3D and GPU architecture, though
> not doing much Genode hacking recently.

Thank you for the warm welcome! I'd have replied sooner if this week
didn't get so busy.

> I suggest that you use the NOVA or Fiasco.OC kernels because they're
> the primary platforms.

That was one thing I wondered, thanks!

> Could you elaborate on what you mean by a multi-process 3D?

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

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'm hoping that the libdrm abstraction layer is comprehensive enough
that Mesa would not need much, if any, patching.

For testing, I imagine primarily using some EGL/libgbm/modesetting
render-only demo, because I don't want to have to think about input APIs
at the same time.

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

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

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.

Jamey