I can't give a definite answer on the Thinkpad compatibility, but it sounds like the i915 driver should be compatible with the Intel 945GM, and the CPU shouldn't be the problem. I might be wrong, but I don't think your problem lies there. As for the console output, there are instructions in the 13.05 release notes: http://genode.org/documentation/release-notes/13.05#Output_and_reset_with_In... Also, if you are able to get a serial port connection, be sure to use a null modem (crossover) cable. other serial cables will not work.
On Thu, Sep 3, 2015 at 3:31 AM, Jamey Sharp <jamey@...343...> wrote:
Thanks to your pointers, Norman, I've gotten as far as building Genode 14.11 for nova_x86_32 with the eglgears run script, with i915 added to SPECS.
I've booted the resulting .iso on a couple of Thinkpads from various eras, as well as in qemu of course. I don't actually get any gears rendering on any of them.
I don't expect it to work right under qemu since I don't think Intel integrated graphics is emulated there, but it's the only way I know to get debugging output so far. Under qemu, I see the following output:
[init -> launchpad -> init -> eglgears] native_probe* native_create_probe(EGLNativeDisplayType): not yet implemented dpy=0 [init -> launchpad -> init -> eglgears] native_probe_result native_get_probe_result(native_probe*): not yet implemented [init -> launchpad -> init -> eglgears] falling back to softpipe driver [init -> launchpad -> init -> eglgears] returned from init display->screen [init -> launchpad -> init -> eglgears] no plugin found for fcntl(2) [init -> launchpad -> init -> eglgears] no plugin found for write(2) [init -> launchpad -> init -> eglgears] called, return 1 connector no RM attachment (READ pf_addr=9 pf_ip=481c4 from a2bfefc6 eglgears) virtual void Genode::Signal_session_component::submit(Genode::Signal_context_capability, unsigned int): invalid signal-context capability static void Genode::Pager_object::_page_fault_handler(): unhandled page fault, 'pager:eglgears' address=0x9 ip=0x481c4
So under qemu I guess eglgears crashes by dereferencing a bogus pointer. How can I get this console output on real hardware, to see if it's crashing the same way?
Also, Norman, do you remember exactly which hardware you tested this code on in 2010? I grabbed an old Thinkpad to try to match your setup more closely, so my test box has Intel 945GM graphics (PCI ID 8086:27a2) and a 32-bit Core Duo CPU. I may have gone a little too far back as it's a 2006 model, perhaps?
Jamey
On Mon, Aug 10, 2015 at 6:44 AM, Norman Feske <norman.feske@...1...> wrote:
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_...
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...
https://github.com/genodelabs/genode/blob/master/repos/libports/lib/mk/libdr...
https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/libd...
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/eglg...
https://github.com/genodelabs/genode/blob/master/repos/libports/run/eglgears...
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
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main