My name is Vivek (Trac: vivek-roy, IRC: vivu). I have been selected for Google Summer of Code 2017 to work with Haiku on the project 3D Hardware Acceleration in Haiku.
To me is the best news to this moment.
This is great news! Any progress on this front is always encouraging!
If the i915 driver gets up and running, a good next step would be radeon (I’d throw some cash at that). Radeon ends up in alot of laptops and Desktops, and will be in a lot of good value laptops with faster graphics than Intel around summertime this year when the Raven Ridge platform comes out.
Nvidia would be a complete waste of time, since it’s support is barely passable even on Linux.
Awesome and thanks for the summary! This will be a great push for Haiku!
It´s now or never! Go go!
This is great news - I have a question though; if you plan to use the DRM as it is in Linux, doesn’t that require studying GPL code and using it as a reference for an MIT licensed implementation? Is it worth maybe studying the dragonfly implementation instead to be safe? I’m specifically referring to the kernel portions, here.
Also, I remember there was an older document regarding an “accelerant” (kernel module) (as per how BeOS did things) - https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/
Maybe it’s just terminology, and DRM would mean the same thing - but how does this proposal fit into Rudolf Cornelissen’s original model explained on the linked page? (Not suggesting that it should, just asking)
My understanding is that the DRM code in Linux is actually dual-licensed under the MIT and GPL. And we aren’t reimplementing it, there’s too much to do that (~750K lines [!] per graphics card type, I think?) merely writing a compatibility layer against the Linux kernel APIs, like DragonflyBSD did.
It doesn’t much at all; the old model of accelerants would be mostly replaced with the DRM-based drivers from Linux.
This is very exciting news, I wish the student massive success, I also hope the dev team can really help and support this project with a maximum effort. Will be watching all summer. My only question is, if this is a compat layer, how will that work across various hardware vendors ? I think targeting Intel GPU is a very good decision, considering the widespread nature of the Intel GPU and the fact that Intel supports it very well. I just wonder how much work it would be from function wrapper for Intel to functioning wrapper for AMD ?
Wish you much success, good luck and we are all watching and pulling for you !
Interesting. I was never quite sure whether including dual-licensed code in a fully (almost) GPL project (Linux kernel), then using that GPL-covered version would result in the derived version (from that) being MIT-only again… I could be way off base here. Anyway, it should at least be fine to support the same interface and compile the original module against that, as you say. Probably just need to avoid copying code out of the Linux kernel itself. As far as I know, it’s a one-way street. ie: if Mesa is MIT licensed and that gets brought into Linux, then bringing in the original version into Haiku would create no requirement that Haiku become GPL
This is HUGE. Good luck!
philcostin don’t conflate the Mesa userland driver with the in kernel DRM, the DRM is dual licensed within the kernel… meaning you an copy it out and use it as either or both. Obviously Haiku would want to discard the GPL option as it is not compatible with the rest of the Haiku MIT code.
Technically you could write a non mesa driver on top of the kernel DRM… it’s a separate thing, basically just he kernel interface to the card.
Oh that’s fine then - I just thought that the copy of the DRM code in the Linux kernel became GPL at the point of its inclusion there, such that anything that is then copied out of that GPL work at a later date is then considered to be a derivative of that GPL work. Does the GPL not override the MIT license in these cases? (just being cautious)
Nope it always lives there its not written in another repo and included… type of thing as it is a kernel subsystem. And no that is the whole point of dual licensing… you can just completely ignore the GPL and use the MIT license if you want.
No, it doesn’t.
There is a lot of FUD and resulting misunderstanding about how the GPL works. The GPL is viral in the sense that it “propagates” to the work as a whole (in this case, the Linux kernel including the DRM code). But, it doesn’t backfire to the individual components. So if you extract a single file from the Linux kernel which has an header reading “this file is distributed under the MIT licence”, then this particular file is under that licence. The fact that it happens to be used in a GPL project, or even that you got a copy of it because of the GPL, does not change that.
This would be an extra idea, though do you think this will allow Haiku to run GLES2? If so, would that be an extra task of yours?
[quote]
The goal of my project is to port Direct Rendering Manager (DRM) Driver
for i915, from the Linux kernel to Haiku with the help of
DragonflyBSD’s Linux Compatibility layer,[/quote]
Where is the different between DragonflyBSD’s Linux Compatibility layer and FreeBSD’s Linuxulator?
Is it the same thing - because Dragonfly is a fork of FreeBSD 4.x and it is possible, that it merges some newer code of FreeBSD ?
Or are both two different things or will be evolve in different directions?
They are different things. What you refer in FreeBSD is support for running Linux userland binaries. What we need here is something to run Linux drivers and kernel modules. This is not the same thing at all: for userland binaries, everything (mostly) can be done by implementing the system calls. But drivers can poke at kernel internals, so we need to add all the internal APIs for that.