What about bounty? 3D acceleration bounty?


#21

Nonsense… adding drivers is orthogonal to any R1 goals.

Rewriting the app server to be hardware accelerated would be something that would obviously delays things and that should be avoided.

Lack of hardware acceleration does mean less developer interest… it means no fewer game ports, limited media editing capabilities due to no acceleration, more and more applications require acceleration, web browsers for instance are a big one all recent browsers really need hardware acceleration especially on lower end hardware.

Attempting to corral developers into finishing R1 will fail, that isn’t how Haiku’s development process has ever worked and it would probably just implode.

If you want R1 faster… you have to make Haiku more interesting for developers, not make demands on the existing developers. Telling developers we already have that are interested in developing hardware acceleration not to do so… is self defeating.


#22

What is obvious and straightforward for you will take weeks for someone to familarize themselves with, add to that that the webkit package itself takes a long time to build and there you have it… low developer interest due to it being basically impossible to do drive by fixes on it.

If there were a couple paid Haiku developers this would probably be a completely different story.


#23

Have you tried it? My main development machine until last week (I was just donated a new laptop that was going to the trash by an Haiku user - thanks!) was a core i3 laptop from 2011, and even there, it only took about 45 minutes to build WebKit. Ok, it’s not done in a few seconds, but it’s quite a reasonable buildtime.

And, it does not take weeks to explore the codebase, there are only maybe two dozen files relevant to the Haiku port, conveniently stored in directories named “haiku”.

If people give up before even trying, of course it won’t happen…


#24

We are not a bunch of people developing random stuff as they see fit. We are a project with a goal we’re trying to reach. There is some room for extras and anticipation, but if we just let people work on whatever new exciting feature they want to, no one will do the bugfixing and no release will ever happen.

This may be done with “soft management” techniques because we can’t just tell people what to work on anyways - they are not getting paid, they just want to have fun hacking on things. So as soon as we start managing them directly, they will just leave and do something else. We can, however, set goals and milestones for the project and convince people they are worth working on. I think our developer most interested in 3D acceleration currently is waddlesplash, who instead decided to focus on wifi drivers updates, and then on helping as much as he could (which is a lot) to get beta1 out. I do believe these were both much more important than 3D acceleration.

Right now what I need in Haiku is not 3D acceleration at all. It’s sound support and a more stable web browser. Guess what I’m working on?


#25

The fact is you need 3d acceleration more than you seem willing to admit. Comparing 2 webkit browsers accelerated vs unaccelerated makes a huge difference on the same hardware…

Granted you can just offset this somewhat by using a faster CPU.

“no release will ever happen” frankly not sure that is even a bad thing… as long as there are at least semi yearly stabilization releases, formal R1 release is of dubious value.

3D acceleration has been on the want list for at least as long as I’ve been watching the Haiku project and posting bug reports which is some 10+ years. The only reason it was acceptable to delay it after R1 was that R1 was seen as happening relatively quickly but that’s delusional… its going to happen very gradually if at all, so may as well do 3d acceleration now and use that to attract more users and developers.


#26

By “no release” I mean not even betas. Did you not notice what happened between 2012 and 2018? Shipping a beta needs focus from most of the community. We just can’t do it if someone is in the middle of rewriting video drivers.

As for 3D acceleration, I mean what I said. I don’t see it as a high priority. As I mentionned, I need a stable web browser, and audio output first. I don’t care if the browser is fast and crashes every 3 clicks. I have to boot windows just to listen to some music or visit some complex website. This is annoying. Slow browser is not really annoying, I can live with it.

I understand that you have different priorities, but these are mine. Don’t try to convince me otherwise.

As for gaming, I’m not much of a gamer myself, and when I play something, it’s usually some 2D retro stuff anyways.

And my goal here is not to attract anyone at this point, it’s just keeping the OS usable for my own needs. That’s unfortunately already enough of a commitment.


#27

Having accelerated anything is putting the cart before the horse when the rest of the system hasn’t seen it’s first stable R1 release. Yes. We need hardware 3d acceleration. No. We don’t need it before everything else. Am I saying that nobody should be working on it right now? Absolutely not. I’m just being pragmatic and pointing out that doing so will divert our already stretched dev team, and delay R1 even further. If we could just attract some fresh, new devs who were already well versed in the whole Haiku system, then yeah, such a goal would be feasible. Until then, let’s keep focused on R1. Many potential devs are shy from Haiku due to the lack of releases, not lack of hardware acceleration. Reaching R1 will attract way more devs than hardware acceleration ever would.


#28

Doubtful… it will probably have a similar effect as Beta 1 a small spike in interest. You have to implement the features that developers require to attract them. The work on Paladin and Koder is a step in the right direction on that front I might add. Without the right features a developer checks it out says … oh it doesn’t have blah, and moves on.


#29

Reaching R1 will free up current devs to both work on new features such as acceleration drivers, and help new devs get acclimated with the system. The R1 milestone will have a bigger impact than you assume.


#30

Well … What is the main goal of Haiku? Re-creation BeOS and binary compatibility. We already reached it long time ago …
Here is a confirmation, 18 years old app compilled and runs on Haiku: https://twitter.com/diegolagoglez/status/1070042052451160065
But this goals a bit outdated … This goals were great 10-15 years ago, not now. There is no any BeOS-app without which we cant? Can you list the vital BeOS-apps? There is no such apps … They all outdated.
For now we have more than BeOS. We implemented such things as LocaleKit, LayoutAPI, Stack&Tile, own Debugger, ServicesKit, Notification API, modern Package Managment system and other stuff which are inherent to the modern system. Dreams and thoughts about R1 just in our heads… It’s like an unachievable goal. But let’s see the reality! Right now we already far ahead from BeOS!
So why do we spend time on supporting GCC2 and other legacy things?
Haiku is modern system. Modern system should have modern browser, which requires 2D/3D HW acceleration… That is why I created this thread here.


#31

I also follow the banter of devs from many communities. Lack of releases is cited far more often as a disinterest in Haiku than our lack of hardware acceleration.


#32

Minor correction. The current main goal of Haiku is reaching R1 by squashing bugs and polishing the UX. Implementation of new features is a bonus, but just the icing on the cake.


#33

That doesn’t actually seem to be happening at a faster rate than before… so we reach that goal when? Frankly Haiku is a large enough project that you could continue doing that indefinitely especially as some of the bugs are not low hanging fruit.

Reaching R1 and 3D acceleration are separate issues… that’s just the fact of the matter.


#34

Going off some of what I’ve heard, there is a tentative goal for an R1B2 by mid year 2019, with a possibility of reaching R1rc by end of 2019. If Haiku can remain focused enough right now to at least meet a mid 2019 R1B2, then the rest of the world might start seeing it as a serious project again. But this will only be delayed by distracting current devs with a focus shift.


#35

R1, Beta or what have you has nothing to do with the lost confidence in outside developers… honestly annual or biannual releases with say 2 weeks of stabilization, then branching with maintenance until the next release would satisfy most people.

The problem was no releases whatsoever other than nighties which provide no sense of stability.


#36

Like I said before, by listening to devs around other projects, Haiku’s lack of a solid release schedule has been a major deterrent to attracting new devs. Hardware acceleration and other lacking features rarely gets mentioned, even in discussion related to those issues. The primary deterrent is currently lack of release schedule. So we just made B1 happen after more than 6 years at A4. Nobody cares. They want to see Beta2 or RC1 or R1 before they start taking a serious interest. You want hardware acceleration? We need devs. You want more devs so we can get hardware acceleration? I know I do. We need to keep the schedule moving in a timely manner. Having just reached R1B1 honestly is just a start in that direction.


#37

Maybe I can offer some insight from the perspective of someone who follows AROS. AROS has hardware acceleration for some older nVidia cards and Intel GMA. Only those and still falls back to VESA on anything else.

Now AROS has only a small handful of developers and drivers may never be written for other graphics chips. Drivers are a time vortex that soak up developers with boring, thankless work. Trying to pursue hardware drivers has almost killed AROS.

AROS, whose motto is “No Schedule and Rocking”, has been reduced to following two main platforms with fixed hardware: Raspberry Pi 2 and 3 series, and classic Amiga. Most of the driver abstraction will not be needed there.

That would be like sending development back to the PPC because the BeBox provides fixed targets. I would rather get a stable release on anything than go back down that road.


#38

I have heard from plenty of users / potential users the lack of a solid release schedule is annoying, but I’ve not heard from other developers that this is the case. Can you please give some examples here?


#39

I wish I could. It’s more of a mental note I make when I see haiku mentioned among devs in other projects. Many times this is in forums such as Stack Overflow, or in comments on YouTube. Often the conversation has come to a close months before I get around to reading them. I see lack of releases mentioned far more than lack of features. It gets mentioned that this a reason for not taking the project seriously. I probably should have kept a log of these discussions. I’m bound to run into it again. I’ll let you know when I do.

I can see their point. Going six years without an official release gives the appearance of a dead project to an outsider. Many would see that and not give a second glance, even if there are daily commits and internally visible progress. If I hadn’t started lurking the forums, I’d have thought Haiku was dead until beta was released. That’s including the fact Haiku has been on my radar since Be Inc folded. I took a total break from computers for half a decade. I came back to find Haiku flourishing and active, yet quite silent to the outside world. I would have overlooked it if I had no previous active interest in it. A total outsider would be apt to look at 6 years without a major milestone announcement and think the project to be abandoned and move on to other endeavors. I’m not saying this was the wrong course for Haiku to take. I actually appreciate the tight knit dev community. I like how Haiku has done it’s own thing, it’s own way and has stayed true to the essence of BeOS.

But now that things in Haiku have shaped up to an excellent core, I think it would be prudent to keep a more active release schedule. If for no other reason, this should be done to build credibility and attract devs who have been overlooking it. Even if the release doesn’t include much in the way of new features, make a release that is mostly bug fixes, especially now that the beta milestone has been reached. In my opinion, it’s going to take another timely release or two to get the attention of many who are overlooking it. The world won’t know that Haiku is advancing unless this news is released to them. Beta has stirred up quite an excitement. Imagine what Beta 2 will do.


#40

They chose to support undocumented hardware… so what do you expect. The open nvidia driver has always been nothing more than a time sink. Not quite so bad on the GMA driver but it never performed well enough to run much of anything serious.

The state of open source drivers has advanced quite a lot since then. And both Intel’s Iris and AMD’s radeonsi drivers are good targets…and the hardware is actually documented.