Haiku - add hardware-accelerated graphics stack

I’m not opposed to anyone doing the work improving GPU support; I just don’t like it when folks say it needs to be the highest priority for everyone because it’s necessary for everything anyone would use a computer for. :slight_smile:

4 Likes

Great, those are exactly the kinds of people I was talking about earlier. Just because you don’t need it, does that mean you think others don’t need it either?

I’m in the same boat with Haiku, and I’d like to be able to comfortably use software that has been taking advantage of GPU acceleration on other platforms for years, which makes it more responsive and simply faster.

Is it a sin if people today want to make the most of their computers’ capabilities?

No, I’m not saying we should drop everything and focus solely on the GPU. Without a stable system kernel that supports all servers, along with a solid ABI and API, GPU support alone won’t ensure system reliability when performing tasks.
I’m simply pointing out that we should stop downplaying the computational power of GPUs, which is needed for many tasks in programs running on the operating system.

It may be the case that there’s a user who, over the past few years, hasn’t decided to use Haiku as their daily driver because they didn’t want to keep running into a wall labeled “no GPU support” everywhere they went. But of course, someone who uses a notepad, plays 2D chess, or listens to MP3s won’t understand this and will write or say that hardware acceleration is unnecessary. Since they don’t need it, they’ll say others shouldn’t have it either.

I hope everyone has understood correctly why I’m bringing up this topic, which is so important to many people.
If, on the other hand, someone doesn’t need hardware-accelerated 3D, that’s great—it just means this thread isn’t for them. They’re welcome to start a thread titled: “I don’t need a GPU to run Notepad.” There, he’ll be able to sing the praises of how much he doesn’t need a GPU for Notepad.

1 Like

Never said highest priority, neither did anyone else. Don’t get why everything online needs to be black and white.

There will always be something that someone is missing so they can use Haiku. It used to be an office suite. Then a web browser. Now it’s GPU acceleration, accessibility (screenreaders), and security (apparently running all apps as the same user is scary). And when these issues get resolved, there will be other ones.

How Haiku makes progress is by people fixing the issues that personally annoy them the most. For me at the moment, it’s about improving the web browser and some drivers (i2c touchpads, I should get back into figuring out multiple displays, maybe also powersaving in the medium/longterm). And writing apps that I need. For other people it will be something else.

I don’t know who is downplaying that. It’s just one of the many things to do in a basically endless list.

4 Likes

Dunno, I read a statement that “the OS needs x in order to succeed” as necessarily implying that, since of course we all want the OS to succeed, the author’s desire is that priority be directed to x.

If I mis-characterized anyone’s intentions, I do apologize.

I think a more useful approach to getting increased developer focus onto gpu support, and one less likely to be misunderstood, could be:

  • find, or become, a developer interested in learning whatever’s necessary to improve gpu support
  • look at the Haiku-supported systems lists to find out what gpus are commonly present in or available for systems people run Haiku on
  • acquire the various systems or gpus identified and make them available to any developers interested in working on support for those gpus
  • profit!

Anything else just comes across (to me, at least) as telling other people that they should be working on your priorities instead of theirs since, if they shared your priorities, they’d already be working on gpu support.

3 Likes

to reply to this, a huge part of why ive been playing with amd stuff is because the pie-in-the-sky end goal is to get this working well enough:tm: to run on my laptop.

specifically, i have a strix point APU paired with a dedicated nvidia GPU. i don’t personally expect this to ever really work to be honest, it barely works in linux half the time if we are being honest, along with the obvious issues of developing for a bare-metal hardware target on the device that you use to develop it for, so to say, but its a nice thing to work towards, keeps the motivation up a tiny bit so to say.

aside from that, the list of things that hobbiyst OSes/kernels have been able to do as of late is genuinely impressive. im quite deep into the osdev community as a whole (including being a mod on the osdev discord), and i can say in the past few years we have come shockingly far. it was only like a couple of years ago where people inside osdev circles would have thought you insane for thinking you could even think of making a os that runs enough stuff to daily drive yourself (or with a small group of friends), nowadays, there are several different hobbyist kernels that can run webkitgtk, one that can run steam through wine, at least one linux-abi-compat kernel im aware of that can actually somewhat run games, and the nvidia-open driver was a huge thing in a way since it meant for the first time that it wasnt a stupid idea for someone to get actual 3d accel from their kernel on real hardware, although im not personally aware of any large project (other than haiku) having actually managed more than modesetting, at least at the moment.

i guess what im trying to say here is that what is needed is probably even more relative than you think: haiku, while being a OS that does technically stretch the definition of “hobbyist”, sure (with haiku inc and all that), is absolutely in a state that a surprising amount of computers can run it with basically everything working, along with a surprising amount of the things needed for lots of folks to be able to have everything they need. perhaps one could consider it sad, but many, perhaps most people, barely need more than a web browser and maybe a office suite to do their jobs. that alone makes haiku a project that is, and already has, gone down in the FOSS history books as a success, now would come the task of actually making it something people want to use, not can use.

(also maybe i shouldnt be writing forum comments at 4 in the morning lol)

1 Like

I agree with you completely.

And as for the things you’re writing about.

Office Suite - It’s very good to have an office suite that supports today’s standards right on your hard drive.

Web browser - Let me put it this way: if Firefox hadn’t been released for Haiku—thanks to the hard work of our developers—I’d probably still just be testing Haiku (as I have for many years) rather than trying to use it as my daily operating system. WebPositive unfortunately, its ease of use and reliability—such as the fact that it sometimes loads certain pages and other times doesn’t—leave much to be desired, despite its long development history. As an everyday browser, its performance is unacceptable to me. If someone from outside comes in, starts using the browser for a while—and sees the same thing I do—it certainly won’t make a good first impression when it comes to the operating system and such a basic and multifunctional application as a web browser today. And I understand that for some people, Webpositive is enough, and its “work in progress” issues won’t be a problem. And it’s the same as with GPU support. For some, the basic VESA mode is sufficient, while others would like to be able to use high-performance GPUs in 2026 to make applications run faster and more efficiently.

Security - Now, I—and many others—would probably be happy with a simple login screen that requires a password to access the system, so that not every uninvited guest who gains access to the computer can log in. Something I’ve already experienced in Zeta 1.5

But I’ve already mentioned both on the forum and on IRC that we could set up bounties for certain tasks, and anyone interested in a particular task could support the developer who’s willing to take it on. But for some reason, no one is stepping up to the plate on this. Of course, anyone can say they can’t afford it, but not everyone should say they can’t afford it. I’m not a millionaire, but once a quarter I can spend $50 on my hobby, which is Haiku.

And this is where the economies of scale come into play: the more of us there are, the more opportunities we have—the more developers, testers, and users. For example, if we had 1,000 active users, there’s already a good chance that, say, 100 of them would be interested enough in GPUs or whatever else that they wouldn’t mind spending a few dozen dollars a month to support a developer who could provide them with concrete functionality within the system. But here, too, we come full circle: to cater to the masses rather than just individual users, we need to provide them with a stable system featuring a modern and reliable web browser (fortunately, we already have Firefox) and password-protected system login so that a kid doesn’t accidentally start messing around with someone else’s hard work. Or even something as trivial as a keyboard shortcut that quickly activates the password-protected screensaver. But even here there’s a problem.

So either Haiku will start reaching out to people eager to learn about a new operating system, giving them some of the basic capabilities needed today, or those people won’t exist—because not everyone is a programmer who can write a program or a system component as needed. And if there aren’t enough people, there won’t be a relatively smooth development path leading to R1 by 2031—perhaps in time for the project’s 30th anniversary;)

I can answer that, personally but I think the situation is similar for other Haiku developers.

I already have a full time job, a stable one with a fixed payment every month.

If you want me to work more on Haiku, I don’t need extra money, I need extra time. Which means quitting or at least reducing the time I spend on my day job. Since I recently bought a new flat for myself (but it was already the case to some extent before that), I am not willing to put myself at risk of defaulting payments because I didn’t reach a planned bounty target, or, even worse, because someone else completed a bounty faster than me, and got the money before I did.

So that’s why we have the current setup: donations to Haiku inc, which shields the developers from such stress and guarantees them a stable income. And the focus has been on hiring one developer almost full time, rather than making small donations to several developpers, as it seems a more efficient way to spend that money. Smaller donations would have developers say “thank you”, and maybe go spend it at a restaurant or buying shiny computer gadgets, or maybe donate it back to another bounty, but, most likely, they would not leave their jobs to become software bounty hunters.

We already have some users, including the developers themselves.

So, the question is, what other topics that the current developers are working on should we give up? And that’s even assuming that the developers working on such topics are 1) knowledgeable in other domains and 2) willing to work there. So, which are the tasks we should cancel to work on that GPU support?

Yes, if you offer me the same guarantees as my current job, even at a lower pay (to some degree), I would happily work on GPU support instead of whatever I’m doing. But at the moment, Haiku is a hobby for me as it is for you. I can contribute a few hours every month, and my goal with these hours is, roughly in that priority order:

  1. to have fun and relax from a day at work
  2. to fix issues I’m hitting myself (porting software I need, fixing drivers for my hardware)
  3. keeping the project running in general (writing documentation, replying on the forum to help people with technical issues, triaging bugs, reviewing pending merge requests so that people don’t leave because their changes get ignored, …)
  4. Fixing issues reported by existing users
  5. Fixing and improving things that may bring in new users

If you disagree and think taking care of other user’s problem should be done first, you are very welcome to help. If you agree that one of the 4 other things is higher priority, you are also welcome to help, because anything there that gets done by someone else is one more thing that I won’t have to do, and one more chance that I get to priority number 5. And if you think the priority is something else, your help is also welcome. As long as it’s not just asking other people why they aren’t doing it for you. There is no central strategic committee to decide of priorities here, it’s a “roll up your sleeves and start helping” type of project. And that’s not just about development. There is a lot to do all over the place. In the last few weeks I prepared the design for the beta 6 DVDs and it looks like I’m going to be the one ordering and then shipping them. There’s localization. There’s documentation (both for users and for developers). There’s forum moderation (I recently resigned from that). There’s joining the HSA or Haiku Inc. There’s organizing the conferences and coding sprints (I never organized a conference but I did my faire share of organizing coding sprints). There’s porting and testing applications. There’s triaging bugs and trying to reproduce them. And so on. Probably some things that I didn’t even notice.

Other developers will have different priorities. For example, some of them don’t even use Haiku as their main OS themselves, and so, they are less affected by number 2.

I’m happy with R1 not happening, actually. I have no interest in the big plans and grand schemes for R2. I would rather have an OS that works, allows me to use my computer, and spend my time on other projects. Haiku works great for that. And the current plans make R2 be something similar to GNOME 3 vs GNOME 2 or Python 3 vs Python 2. So, if R1 happens, I would be happier if the focus remains on R1.1 and subsequent point releases.

5 Likes

I just tested this on hrev60102, and it seemed fine?

I used Shortcuts to map ctrl-p to “/bin/screen_blanker -l”; when I hit ctrl-p the screensaver starts and I can’t get back to the desktop till I type the screensaver password.

Maybe you didn’t have a screensaver password set when you tried it?

Right now, I’m not interested in R2 or R3—just a stable, production-ready R1. But if you keep sabotaging R1, we’ll actually end up with Beta 25 or Release Candidate 12 in 2044 ;D

But back to the topic at hand. Let’s leave the GPU aside for now, because fortunately, things are moving forward in that area, and there are people developing GPU drivers. So far, only a small fraction of the hardware is supported, but that’s much better than nothing. It’s good that there’s at least something the software can use. Maybe someday the system itself will use it, and I’ll be able to set the windows to 25% transparency— because why not?

So maybe let’s focus on smaller things, like the system login screen with a password—a small but useful detail that’s nice to have. Maybe tell us how much you’d charge to take a look at this in your spare time—maybe we’ll set up a fundraiser and get another little thing taken care of. That is, of course, if there are people willing to chip in, because while there are plenty of people interested in the login screen, I’m not sure if they’d be willing to chip in a few dollars. I’ll put up $25 to start with—who else is in?

This one is probably a bad example because there’s already an effective way to do this.

The method described in

for starting the screensaver at boot time does work (though @nipos reports that is is unreliable on their system).

This gives the effect of a login screen, without needing any developer time (other than maybe tracking down whatever’s happening to @nipos).

It’d be nice to have “start at boot time” as an option in the preferences, but unless someone’s starting the project of actual multi-user support this workaround is surely good enough?

Do you seriously think that?

I will avoid contributing to Haiku then. Apparently you know better.

I believe you have not read what I wrote above. I do not need money. I am free to work on whatever I want. I intend for things to stay that way. Otherwise, it’s not my free time anymore, and in that case you are talking about hiring me, and I already explained what I need: a stable job that will last for a few years. Which, writing a login screen isn’t.

Also, we already have a login screen app: https://git.haiku-os.org/haiku/tree/src/apps/login . It’s been available since 2008.

You can donate the $25 to Haiku inc and I’m sure they will make good use of it.

3 Likes

Neat; I had totally not noticed that. :slight_smile:

Is that actually part of the system install, though?

There’s no file on my laptop whose name contains “Login”, and “/bin/login” is definitely not that.

(I’m interested in trying to get the GUI running as a non-root user, possibly interested enough to re-learn all my forgotten C++, so I’ve been reading the sources with that in mind for a while.)

Did you see “;D” ?

Then how I can use this?

No, it’s not by default. You have to add it to the Jamfile and build a custom image if you want it. And I’m not sure if the integration with launch daemon to run it before the desktop has been done yet.

Some other changes will be needed, such as removing the “restart the desktop” from TeamMonitor, and probably many other ways to start a desktop session without knowing the password. I think tha’ts why it’s still disabled by default: we don’t want to create a false sense of security.

1 Like

I used “/bin/screen_blanker”, with “/bin/screen_blanker -l” working good.

So we don’t have that working in the system. It’s great that there’s a version in the tree that hasn’t worked so far. You’re joking now by telling me this, right? :slight_smile:

Seriously, do we have to figure everything out like this?

I don’t think the edge-of-trolling humor is really working out very well.

3 Likes

Yes?

There are two options in this particular situation:

  • use the workaround, and focus your limited time on other things
  • code a better solution, like adding a checkbox to the screensaver prefs that makes it start at boot

But giving volunteers grief that they’re not doing the thing that you’re also not doing is kinda rude.

Back to GPU support: it’s reasonable to make a case that you think x is more important than y for z reasons; hell, it’s totally reasonable to try to get other folks to go in with you to hire someone to do x if the existing devs would rather be doing y.

But I think we’re pushing the envelope of “reasonably trying to convince” here in this thread.

It’s really important to remember that in projects like this things only get done when someone volunteers to do them, but on the flip side there’s no one to stop you doing the thing you want done.

3 Likes