Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haiku OS ported and running on RISC-V

discuss.haiku-os.org

Post reply on HN
Print view View original

71–80 of 89 posts

Re: Haiku OS ported and running on RISC-V

#71

Post by rjsw »

zozbot234 wrote: post #33
swiley wrote: post #32

Earlier quoted context omitted.

IME: hardware accelerated UI toolkits are very slow on all but the largest/newest computers. Rendering a GUI can be done in real time on ancient CPUs. This has been true since the 1980s and continues to be true today. If your app has a performance issue then you should consider cutting down on the animations/special effects/abstractions.

> Rendering a GUI can be done in real time on ancient CPUs. That depends on the style of GUI. As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.

The Macintosh did drag-and-drop with no hardware acceleration in 1984.

Re: Haiku OS ported and running on RISC-V

#72

Post by codetrotter »

rjsw wrote: post #68
nix23 wrote: post #47

Earlier quoted context omitted.

That much: https://github.com/NetBSD/pkgsrc/tree/trunk/www/firefox/patc...

Some of those are for optional features like WebRTC, they are not all needed for a functional browser.

This thread is about fully featured browsers though. I think without WebRTC you can not call the browser fully featured.

Re: Haiku OS ported and running on RISC-V

#73

Post by brucehoult »

hestefisk wrote: post #2

Love this and love the idea of having a RISC based workstation as my daily driver. Any suggestions on where to buy it ?

The best performance this year will be SiFive's "HiFive Unmatched" with four cores more or less equivalent to an ARM A55. Raw speed should be a little quicker than a Raspberry Pi 3, but the user experience will be better because it has an M.2 slot for a modern SSD, a PCIe slot that Radeon graphics cards work in (they demonstrate it with an RX 580), and 16 GB RAM. Pricey at $665 for the Mini-ITX motherboard with CPU and RAM, but it will give the best user experience. Production version is due to ship at the end of this month.

Next is the BeagleV "StarLight". It uses the same SiFive cpu cores but in an SoC from a different company, and with a built in PowerVR GPU. It runs off SD card, but once booted can use USB3 disks. At $119 for 4 GB or $149 for 8 GB it's not a lot worse of a computer than the Unmatched. Due to ship September, I have a beta developer board now.

Allwinner have their D1 chip in mass production right now. It has a single core running at 1.0 GHz with a draft version 0.7.1 128 bit RISC-V Vector unit, which improves the speed often 2-3x. Sipeed and Pine64 have promised Linux boards using the chip in the next couple of months starting at $10 or $12. Probably with only 256 MB or 512 MB RAM at that price. That's very competitive against Raspberry Pi Zero. I've had access to an Allwinner Evaluation Board for a couple of weeks and it's very very nice is they can get boards out at those prices.

All the above are 64 bit and run Fedora, Debian, Ubuntu (I recommend Ubuntu as they have 21.04 images for RISC-V) and others coming.

If you want a full featured desktop experience with web browser loading heavy sites, watching YouTube etc then you'll want the Unmatched, but the BeagleV will be close. Note: such a web browser isn't available yet, but once developers have these boards themselves as daily drivers it will happen.

While the Unmatched / BeagleV CPU is similar to a Pi 3, with more RAM and better peripherals (especially in the Unmatched) I expect the overall experience to be like a Core 2 Duo from the mid 2000s, maybe better for many things with a decent video card. Think: original MacBook Air.

Re: Haiku OS ported and running on RISC-V

#74

Post by swiley »

slackfan wrote: post #67
zozbot234 wrote: post #33

Earlier quoted context omitted.

> Rendering a GUI can be done in real time on ancient CPUs. That depends on the style of GUI. As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.

Haiku does some amazingly impressive things software-only, drag & drop and scroll really don't need hardware acceleration. If they do, there's a problem with your code. Mind you, I can do real-time 1080p mp4 video scrubbing on haiku running on a thin client so...

I was thinking about it and the issue is really the "if there's no compatible hardware llvmpipe will just take care of it" attitude. If you watch these software rendered graphics carefully (or read the code) they make trade-offs that allow everything to work with low input latency and render in real time and sometimes that means "corrupt" looking graphics on the screen which the OpenGL style graphics won't generate (the frame is either done or it gets skipped.)

Re: Haiku OS ported and running on RISC-V

#76

Post by ianai »

waddlesplash wrote: post #64
rcarmo wrote: post #61

I'm actually quite sad that the Haiku community never managed to marshal the effort to do a Raspberry Pi port. It would have been a killer OS on it, but somehow it never panned out. (I remember some early discussions in the forums where at first the Pi was dissed in favor of the BeagleBone, and then because of Broadcom, and then, later on, because of "lack of openness", so I'm chalking it down to a mixture of bias an…

We were never opposed to a rpi port, but it was much more difficult in the days of rpi1/2, yes, and the BeagleBoard was the initial target instead. These days there is some rpi4 code in the tree, but nobody found the time or motivation to work on it seriously, I guess.

So how production ready is haiku? Targeting the rpi seems like a strong “user-grab”.

Re: Haiku OS ported and running on RISC-V

#78

Post by dleslie »

garaetjjte wrote: post #48
swiley wrote: post #45

Earlier quoted context omitted.

Sure and ImGUIs are extremely unpleasant to use in power/resource constrained environments. You should look at GTK+, motif, or TCL/Tk. They're very straightforward and don't turn people's devices into hand warmers.

GTK in resource constrained environment? Uh... Motif, along with X11 is just completely obsolete platform. (btw, this is what UHH thinks about it: "What Motif does is make Unix slow. Real slow.") There's some weird GPU hate in this thread that I don't quite understand. Try to render dragging content of 1080p window at 60fps on cheap mobile ARM core, and you will likely blow your whole time budget just on filling the…

Like on the PinePhone, using sxmo? Works great.

Ditching the _enormous_ Android stack is an easy win.

Re: Haiku OS ported and running on RISC-V

#79

Post by deathanatos »

colejohnson66 wrote: post #44
zozbot234 wrote: post #33

Earlier quoted context omitted.

> Rendering a GUI can be done in real time on ancient CPUs. That depends on the style of GUI. As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful.

> As soon as you introduce any amount of animation (even something as trivial as drag-and-drop, never mind touch-swipe or touch-zoom gestures), hardware acceleration can be quite useful. Didn’t Windows XP (and prior) not render the window as it was dragged, but just a dashed box? And when you release the window, it’d be redrawn in the new spot.

I believe Windows 95 had only that behavior… but everything after it could render in real time.

In Windows 98, it's under the Control Panel → Display → Effects → Show window contents while dragging

https://copy.sh/v86/?profile=windows98

(The VM here is slower than a machine of the era.)

(I also want to say Transport Tycoon Deluxe's windows were draggable without needing a frame / in real time, and that was in DOS?)

Re: Haiku OS ported and running on RISC-V

#80

Post by moshmosh »

f00zz wrote: post #60
dleslie wrote: post #29

Earlier quoted context omitted.

Honestly, as someone who uses Haiku casually I find the absence of a beastly browser to be a feature. There _is_ a browser, one featureful enough to read Wiki and such, but not featureful enough to blow away hours and hours on Javascript-heavy social web applications.

also, no Electron apps. all I see is upside

I ran minimalist Void Linux on a crappy dual-core Celeron Chromebox with 2GB (yes, two) of memory as a workstation for a few weeks last year.

It was impractical longer term, but really, as long as I didn't open more than a couple Surf (the Suckless browser, uses the Webkit engine) windows at a time it didn't feel slower than a tricked-out Mac or a beast of a Windows machine, for everything else. Amazing what running as little JS as possible can do. I had to run Docker and VMs elsewhere since they hog memory by design, but it was entirely fine as code-editing and command line workstation. A heavy IDE for, say, Java might have been painful if I'd needed that—which is kind of crazy, because those used to run just fine on well under 1GB of memory, too.

Using Void helped a lot because a bunch of the background garbage on something like Ubuntu, which is really getting out of control, wasn't hanging around eating memory and periodically waking up to burn cycles for unclear reasons. I imagine the benefits of Haiku are similar (big fan of BeOS back in the day, thing's UI responsiveness on mediocre hardware was downright magical)

Post reply on HN