It has been a while since the last Report. So here I go. Firstly, I would like to thank all the Haiku mentors and developers for the first GSoC evaluation, thank you for believing in me. Now coming to the report.
i love to see this soon <3
Don’t hold your breath, because his progress has stopped AFAICT.
Yes, this student was unfortunately failed at the second evaluation.
What happened is a combination of the mentor disappearing without warning anyone, and the student failing to notify us of this. He tried to continue the work on his own where he should have asked for a replacement mentor (we have a team of mentors ready to step in). Unfortunately we noticed this too late and it was not possible to get the project back on track.
We will still see what can be recovered from the work done, but there will not be usable results out of it.
Es decepcionante.
This is important i feel sad
Maybe this show that porting DRM from Linux is not the best approach.
After all, what we needs to be able to port 3D HW DRI-and-DRM-based drivers is the DRM public API, not necessarily the Linux implementation of this API, which, no surprise, highly depends on Linux kernel internals.
I was the backup mentor and noticed the primary mentor’s absence around the first review point.
The 3D hardware acceleration project had a huge scope of work. The plan drafted by the student was extremely ambitious (and showed a lot of promise). Things started to go wrong when we made it through the first review period and the only work was about two dozen (complex) commits towards the linux compatibility libraries. (most of which were stock linux headers)
I passed the student with the warning that more time and work was needed around getting the DRM libraries compiling to keep up with the project plan. The second review period came and 100% of the work was still on these compatibility libraries (and only a handful of additional commits were made towards these headers. The student had a lot of questions around basic C types and macros as can be seen from the mailing lists)
The chances of any level of success (including getting a basic DRM port before the end of GSOC) seemed low. With this, I decided to fail the student after speaking with other mentors.
Vivek was a pleasure to work with, and i’m saddened the project ended this way. I’ve grabbed a copy of Vivek’s code in-case it might be of some use to us going forward.
since we’ve got upstream mesa support, wouldn’t the last thing be a generic interface for their drivers?
then you say maybe all this headers what vivek made can help eventually for the implementation or just was a loose of time? i hope no …
Most of the work he did was copying files from Linux and FreeBSD and trying to get them to compile. Wether it is a waste of time depends on how the next attempt at doing this goes.
If we decide to continue that way importing Linux code (ignoring the problem that some of it is under the GPL licence), then we can reuse this work, but it doesn’t bring us this much closer to getting things working.
If, however, we go with writing our own implementation of DRM as phoudoin suggests, then this work is useless.
I never looked at the DRM code myself, but is there so much difference between the *BSD implementation and the Linux one? If so, can’t we just implement a FreeBSD compatibility layer like the one which is used for network interfaces? I mean maintaining an own implementation for all those GFX cards sounds like too much work for me…
Very sad i was thinking we were using 3d godot and blender befor xecember 
i am very sad really
The problem is similar with the FreeBSD code (at least it solves the licencing problem I think).
The main problem is this is a lot of code and is tightly coupled with many parts of the OS (memory allocation, device drivers, etc). Thus, the compatibility layer may be large and require invasive changes. I don’t know how much of FreeBSD code is also using their own compatibility layer with Linux, and how much of it they wrote themselves. During the project the DragonflyBSD code was also investigated, as this one seemed to be more free of Linux code.
However, note that the drivers are not the complex part in this stack. The point of DRM is to move as much of the complexity as possible in Mesa/Gallium3D, and outside the kernel. The drivers are then reduced to low-level primitives which are reasonable to implement ourselves. Also note how this is similar to the architecture BeOS and Haiku are already using, with the driver/accelerant separation for our graphic drivers. So the way I see it, we could just extend the driver<->accelerant interface to provide some DRM functionality, and then plug Mesa/Gallium on top of that. There is still some low level work in the drivers to do (queueing commands to the card, etc), but it does look more reasonable than trying to port a complete driver from Linux or FreeBSD kernel to me (looking at their drivers and using a similar structure, but using our own kernel facilities is a way to achieve this).
@cosmogatokat: I think there was a lot of hype around the project, but clearly, if getting 3D accel to work was just 3 month worth of work, it would have been completed a long time ago already. The goal of the project was just to lay the bases for it.
ouch thats hurts.
If, however, we go with writing our own implementation of DRM as phoudoin suggests, then this work is useless.
Call me Mr Half Full but… no failure is totally useless if it helps to find success someday…
Hi!
I’ve been watching Haiku OS development (OpenBeOS previously) for as long as I can remember, and I will put below some of what I have concluded, and this gonna be a little bit lengthy. (and you are free to correct me)
PRAGMATISM ALERT!
This development has been going on forever (20 years?), but at least we have now an almost stable BeOS clone, a pleasing to look at desktop, basic file management, still running in a virtual machine, good to run some built in demos and clones of incredibly out-dated FPS games.
I hate to see this great effort turning to another Amiga nostalgia-good-for-nothing-OS, or something like FreeBSD world of Linux compatibility layers to patch some important OS areas like sound or 3D acceleration because developers possibly went lazy and stop researching something unique and started copying the readily working good old neighbor open-source OS (and I don’t mean Haiku devs are lazy, this is just a warning, you guys rock!), the thing is FreeBSD never got any real benefit from doing that, they haven’t taken any share of users or support from the Linux world despite being compatible, this approach does not work.
What I believe works is to start researching new methods and stop looking at Linux code and not try hard to let DRM compile or work efficiently! It’s just a huge waste of time! And you’ll end up with the same bloat of code that Linux currently has.
Haiku OS inherited the good Kits approach with a minimal micro kernel, and I think the best way to to extend and modernize those Kits adding more Kits on the way if needed.
Again please correct me if I’m wrong, I’m not trying to troll, just describe what I feel around all this situation.
I want this to succeed!
Best!
market share isn’t a goal, reimplementing beos as a modern system is. similarly, market share isn’t a goal of freebsd or linux. the reason for compatibility layers is nobody’s writing haiku hardware drivers for the video cards they‘re releasing (and the reason for linux video drivers is specifically vfx industry support from the ‘90s). video card drivers are not a task for an os dev team typically and it’s a lot to ask of this team.
That might be true, but back when BeOS was going pretty well, one of the main reasons that it didn’t go anywhere was due to the fact that there was no real hardware acceleration… (3dfx wrapper aside) I remember seeing a few screens from NWN that was supposed to get a BeOS release and that never happened because we had no 3d hardware acceleration.
After all this time, there still pretty much being zero hardware acceleration is quite frustrating to see.
I am also quite concerned at the amount of Linux influence to the project at this stage of the development. It does seem that we are forking towards Linux more and more rather than persuing our own derivatives. Sure we can use Linux to see how the drivers are written, but instead of using the Linux oriented rivers, we should be reverse engineering our own.
Anyways, that once again isn’t the Devs problems, though I was very sad to see Axel leave the project, I hope that we do have an outlook for getting hardware acceleration implemented, as vesa is terrible on a good day and we really should get this sorted before we start adding a lot of frosting to the cake. 3d and 2d acceleration is a basic requirement. It needs to get sorted. If we can’t do that than we surely are doomed to go no further than r5 ever did.
Hope that didn’t sound to harsh, but 15 years later we are no further than we were in the days before Be Inc went bust.
It seems to me you don’t have any ideas what developing an OS is. If there were hardware acceleration, the next complaint would be that your hardware isn’t supported anyway. Or does that sound too harsh?