[HN Gopher] Haiku Now Has Experimental 3D Acceleration
___________________________________________________________________
Haiku Now Has Experimental 3D Acceleration
Author : DeathArrow
Score : 192 points
Date : 2021-11-30 10:22 UTC (12 hours ago)
(HTM) web link (discuss.haiku-os.org)
(TXT) w3m dump (discuss.haiku-os.org)
| bitigchi wrote:
| For more context, this effort is mostly lead by X512, the
| wunderkid, who ported Haiku to RISC-V platform singlehandedly,
| and a long time Haiku contributor already. The patches are not
| upstreamed yet, and it currently only supports Radeon Southern
| Islands cards, planned to be expanded for Intel and other AMD
| cards in the future.
|
| If you would like to contribute, feel free to drop by the forums,
| and say hi!
| WesolyKubeczek wrote:
| Southern Islands? Like on those Sandy Bridge Macbook Pros?
| pb82 wrote:
| It refers to their HD 7000 series, the predecessor of Polaris
| (RX 4xx and 5xx):
| https://en.wikipedia.org/wiki/Radeon_HD_7000_series
| spijdar wrote:
| The RX/R designation doesn't actually say much about the
| underlying architecture, Polaris is GCN 4, while HD 7000 is
| ... a mixture. Most HD 7000 cards are first gen GCN, though
| some are TeraScale 1/2, which would required very different
| driver support.
|
| I guess it doesn't "matter" to consumers buying a product,
| but it is unfortunate how confusing the naming schemes are
| versus the underlying architecture. The R9/R8 cards were
| similarly a mixture of GCN 1, 2, 3, and even TeraScale.
|
| (similarly, the RX 5xx/4xx series has GCN 1 and GCN 3 cards
| mixed in, in addition to the actual GCN 4 chips)
| pb82 wrote:
| Thanks for the clarification, much appreciated! So it is
| the same mess just as with their CPU names.
| spijdar wrote:
| It's really annoying because what you said is correct
| most of the time, and broadly speaking "HD 7000 is
| southern isles".
|
| Except for the ones that aren't. And it's not even
| chronological -- the HD 7510 with a TeraScale 2 chip was
| released after some southern isles cards.
|
| And there's the Radeon HD 7790, which has a GCN 2 sea
| isles chip.
|
| I became aware of this because my "R9 280x" turned out to
| essentially be an upclocked HD 7970, using a
| Tahiti/southern isles chip. GPU was fine, it's just a
| nuisance to sift through what's what...
| WesolyKubeczek wrote:
| Thanks, I'm really dabbling in the AMD nomenclature.
|
| Trying to discern if my gpu is better supported by radeon
| or amdgpu gives me headaches.
| freemint wrote:
| https://en.wikipedia.org/wiki/Radeon_HD_7000_series
| floatboth wrote:
| Those (https://www.techpowerup.com/gpu-specs/amd-
| whistler.g103) are Northern Islands (GFX4), really old stuff.
| DeathArrow wrote:
| Haiku would be an OS I would enjoy running every day if there
| were drivers for modern hardware and it ran the software I need.
| I stil hope it will get to that point one day. :)
| hyperman1 wrote:
| Could it be possible to shove the linux kernel under the Haiku
| userland? This would give access to all drivers available in
| linux. You could sacrifice compatibility with the linux or
| POSIX userland. A bit the same thing as WSL1, but from Linux tu
| Haiku.
| AshamedCaptain wrote:
| This is why I dislike Linux. Some of the policies regarding
| drivers may make sense, but the net result is that rather
| than having a lively ecosystem of free operating systems with
| all of them sharing decent hardware support, we have a Linux
| monoculture with it being the only operating system with any
| type of hardware support and the rest being terrible compared
| to it (even Windows is bad).
|
| In part I guess it's because there is no Linus-enforced
| requirement to have sane specifications, rather than only
| code. In fact, they seem to encourage having Linux-specific
| drivers to the detriment of other OSes. Having non-upstream
| "generic" drivers is not only heavily frowned upon but also
| rather hard due to the constant breaking API changes. And for
| upstreamed drivers, you basically have to make your kernel
| code all but Linux-specific in order to have any chance;
| generic code or code that doesn't use all the specific Linux
| infrastructure is basically forbidden everywhere except
| staging/.
|
| The lack of stable API/ABI should in theory prevent "write-
| once-and-forget" drivers, as well as discourage proprietary
| ones, but in practice we have both of these. I would really
| like to see how the world would look like if there was one
| stable, open, popular API for drivers.
| MisterTea wrote:
| This issue is not the fault of Linux but manufactures who
| REFUSE to release datasheets and programming manuals.
| Instead these manufactures "embrace" Linux (Which to them
| == open source) by writing undocumented drivers for
| undocumented hardware. So OS devs play reverse engineer and
| cargo cult the undocumented Linux driver bit twiddling
| dance routines into their driver code and pray it works.
| vanviegen wrote:
| The alternative would be to have drivers that work against
| a fixed common ABI (or API, if you just want source level
| compatibility). Good lucking trying to get operating
| systems to agree on this ABI.
|
| Linux is constantly breaking these internal APIs for a
| reason: to keep adding new (hardware) features, while
| preventing each driver from implementing large amounts of
| would-be-common code each in their own non-standard and
| slightly broken way.
|
| That's why some types of drivers tend to be huge on
| Windows: they're offering functionality that the
| (relatively stable) driver API doesn't support. This
| approach requires drivers with user interfaces. Good luck
| doing that cross-platform.
|
| What you're asking for is highly impractical.
| kitsunesoba wrote:
| I think that perhaps pushing for drivers in userspace
| wherever possible would improve this situation
| significantly. Userspace drivers for Linux would still be
| built with various Linuxisms, but at least you get all the
| kernel specific bits disentangled which improves
| portability a lot and makes writing compatibility layers
| for other operating systems more feasible.
| phendrenad2 wrote:
| You're 100% correct. I'll add to that the fact that GPL
| drivers can't be used as-is in non-GPL kernels. It's a one-
| way street leading to Linux.
| rodgerd wrote:
| > Could it be possible to shove the linux kernel under the
| Haiku userland?
|
| One of the joys of the BeOS kernel is that it is optimised to
| be extremely responsive to interactive, graphical workloads.
|
| The Linux kernel is not.
| somewhatbetter wrote:
| Why linux advocates are like "Oh, here is a nice alternative
| OS, lets tamper it with linux, because everything is better
| with linux!"? Stop wishing others to change, start change
| linux instead. And yes, you can use Haiku kernel with gnu
| userland, so there is no big roadblock there. Good luck.
| MisterTea wrote:
| There is a defunct project which did exactly that called
| BlueEyedOS. http://blueeyedos.com/
| snvzz wrote:
| I have to wonder how supporting RISC-V and amdgpu does not
| count as modern hardware.
| dusted wrote:
| In that case you better start lobbying your software vendors
| for Haiku supports.
| oweiler wrote:
| BeOS is older than Win 95 so I have my doubts.
| somewhatbetter wrote:
| Which is relevant because?
| themodelplumber wrote:
| So you'd be OK with no login password on your daily driver?
| Personally that gave me a little bit of pause when trying it
| out. Still haven't decided what I think about it.
| nix23 wrote:
| It's a single user system...just like dos.
| themodelplumber wrote:
| So I guess just like I did with DOS, I should design my own
| "FBI" faux login screen in Lazarus, or some other RAD
| equivalent of QuickBasic? :-)
| bitigchi wrote:
| You could help integrating full disk encryption, and a
| login screen. :)
| themodelplumber wrote:
| I'm curious, is a native login screen desired by project
| developers? I was under the impression that it wasn't, so
| much.
| bitigchi wrote:
| It's just that no one got around to that yet, also a
| login screen without disk encryption does not mean much.
| For reference, there's a drive encryption[1]
| implementation on alpha status, but it needs to be merged
| and reworked into the system.
|
| [1] https://github.com/axeld/driveencryption
| yjftsjthsd-h wrote:
| You can want a lock screen (optionally paired with data
| encryption) even on a single user machine for privacy
| reasons.
| AnIdiotOnTheNet wrote:
| Yeah, I think I would too. At the very least I would love to
| tell Windows to shove it and have an option that wasn't as
| horrifically terrible as Linux Desktop.
|
| The latter issue (software) would be mitigated significantly in
| my case if it had a good hypervisor and a WINE port, but the
| former issue seems nigh-insurmountable given the amount of
| hardware around today. It's really sad because it's a big
| reason that we don't have more experimentation in the Desktop
| OS space.
| shrimp_emoji wrote:
| >as horrifically terrible as Linux Desktop.
|
| Obligatory defense: I refuse to believe this snipe extends to
| KDE on a rolling distro (e.g., Arch or Manjaro), where it's
| objectively a better UX than Windows.
|
| (I stress rolling since new versions of DEs seem
| paradoxically better than old versions, so the versions point
| release distros like Ubuntu use are always crashier and
| buggier.)
| nyanpasu64 wrote:
| Haiku has less of a software problem than I expected, since
| Qt has been ported to it, and it has some (not the majority
| of) Qt apps, as well as the Qt Creator IDE. I'm not sure if
| Qt apps are as light and responsive as native Haiku apps
| though.
|
| Unfortunately I never did find supported hardware and clear
| out enough hard drive space to install it (despite shuffling
| my disks around and losing my last copy of important files).
| Perhaps I could try running it in a VM, but why not use the
| outside OS at that point?
| badsectoracula wrote:
| The thing that i always found puzzling with Qt, Java, etc
| on Haiku is that if you are going to rely on those instead
| of taking advantage of Haiku's uniqueness and integrated UI
| approach, then why not just run Linux with a BeOS-like
| theme?
| AnIdiotOnTheNet wrote:
| As usual it's a matter of what you're trying to do and how
| closely it matches the things the devs are trying to do. My
| only real attempt to use it lately was on an old eeePC I
| only really wanted to use for remoting into my home Windows
| PC and I ran into a bunch of issues with the only working
| RDP client (commandline-run FreeRDP). Waddlesplash even had
| to pick up on a post of mine here on HN and take it upon
| themselves to update FreeRDP to get to that point. It
| functions, but is seemingly unable to resize or even go
| fullscreen despite specifying the relevant commandline
| arguments, which on the tiny monitor is a problem because
| it leaves me forcing it to run in a less-than-fullscreen
| resolution that accommodates the title tab and moving it to
| the top-left corner.
|
| Personally, I am not a fan of the reliance on ported-from-
| unix packages. Especially considering that there is
| currently no autoremove for the mountains of dependencies
| that they bring with them. If Haiku had containerization
| this could be more easily mitigated, but as far as I'm
| aware it doesn't.
|
| > Perhaps I could try running it in a VM, but why not use
| the outside OS at that point?
|
| My feeling as well.
| smallstepforman wrote:
| Talking about supported hardware, I always select hardware
| that will run the software I want, not the other way
| around. When I build my desktop PC last year, it was all
| AMD hardware. Haiku works great on it, and with X512's
| vulkan driver, I'll even have 3D acceleration. I'm buying a
| laptop in 2 months, again, it will be all AMD hardware. And
| Haiku will run great on it. As will Linux.
| morganvachon wrote:
| Agreed, I was a huge BeOS evangelist back when Be, Inc. was
| still around and a while after they were bought out. I ran it
| as my main OS for several years and to this day I prefer its
| interface, multimedia back-end, and file system to anything
| modern. Haiku would scratch that itch if only, as you said, it
| supported modern hardware and current necessary software. This
| announcement is one step closer to the former becoming a
| reality, and I'm so there for it! I feel like once it's stable
| enough for use as a daily driver hardware-wise, the software
| porting side will begin to catch up.
| mdp2021 wrote:
| > _drivers for modern hardware_
|
| How well does Haiku work on bare iron nowadays? Any tested
| laptops - better, any repository of tested brand/models, or of
| tested hardware in general?
| yjftsjthsd-h wrote:
| I ran it briefly on a laptop (thinkpad) and it worked
| remarkably well; the only real issue was that Haiku really
| needs mouse and that model's inputs were kind of awful
| morganvachon wrote:
| I've had the best luck with older "office PCs" like HP
| EliteDesk/ProDesk series and Dell Optiplex machines. They
| tend to standardize around the most common denominator
| components like Intel or Realtek Ethernet NICs and Intel
| iGPUs and nothing too esoteric. Laptop support has gotten
| better recently, with many Thinkpad models from the past
| decade working more or less 100% out of the box in my
| experience.
|
| My biggest issue running Haiku bare metal has persisted
| across hardware and form factors though: Stability. I can't
| seem to keep a machine running for more than a few days
| without a kernel panic or a frozen GUI. I haven't tried the
| latest snapshot on my "newest" acquisition, a Haswell era HP
| EliteDesk castoff from work, it's my project for this coming
| weekend and I'm looking forward to seeing how long I can keep
| it running.
| waddlesplash wrote:
| If you can so consistently reproduce kernel panics, it
| would be good to open a ticket. However, that has been less
| and less of a problem in recent years, and a lot more
| panics were squashed in the past few months, especially USB
| related ones. So you might try a nightly build and see if
| things are improved; if not, please do open a ticket.
| morganvachon wrote:
| It was indeed on older official releases on those older
| machines, I never got into the nightly builds that much.
| I will try both the latest release and latest build this
| weekend when I work on the new hardware, and I'll report
| any showstopping bugs.
|
| Now that I think about it, it definitely could be USB
| related on those other machines too. I've used the same
| cheap USB KVM for years and it has polling issues in
| Windows 10, I didn't even consider that might be the
| source of my issues elsewhere. I'll try it without the
| KVM and see what happens. Thanks!
| mrweasel wrote:
| I tested R1/beta3 on an old NUC. I can't remember if
| BlueTooth worked, but everything else was supported,
| including the wireless NIC.
|
| Note that the wireless only works if you do an install, the
| live-cd won't be able to use the wireless driver for some
| reason.
| cardanome wrote:
| Anecdotally, when I tested it on an old ThinkPad last year,
| it worked fine. I was really impressed.
| rcarmo wrote:
| Still no Raspberry Pi images, though. Massive missed opportunity,
| I think.
| II2II wrote:
| I wonder if a Raspberry Pi port would be a "low effort" way to
| attract more developers.
|
| I'm not claiming that such a port would be easy, but that the
| Raspberry Pi represents a relatively stable platform. Rather
| than having people turn away when they discover that component
| X of their PC is unsupported, they have a path where they can
| boot the image, try it out, and learn how to develop software
| for it. While this probably wouldn't address the issue of
| kernel/driver development, it may help to address application
| development.
| bitigchi wrote:
| Current ARM porting effort can be tracked from this forum
| thread: https://discuss.haiku-os.org/t/my-haiku-arm-uefi-
| port-progre...
| snvzz wrote:
| They're smarter by focusing on RISC-V imho.
|
| The future, rather than the past.
| dusted wrote:
| It's opensource though, I'm certain they would accept your
| contribution if you port it.
| MisterTea wrote:
| Don't complain. Send patches.
| AnIdiotOnTheNet wrote:
| I don't interpret parent's post as a complaint so much as an
| observation: Raspberry Pis are incredibly affordable little
| computers that are seemingly a good fit for Haiku since they
| have relatively little diversity of hardware to deal with
| (outside USB devices of course), would benefit from a less
| bloated Desktop, and little otherwise is expected of them.
| Lots of people have various Pi models laying around in want
| of something to do with them, and lots of people would like
| to play with Haiku outside of a VM, so I agree with parent
| that it seems like a missed opportunity.
| morganvachon wrote:
| As both a Haiku and RPi fan, I agree they would be a great
| combination. RiscOS has run on the Pi since the first
| model, and if that combination's performance is anything to
| go by, Haiku would likely run circles around Linux on Pis.
|
| The problem, as others have said, is the lack of dedicated
| manpower. This is one of those situations where I wish I
| was a developer, I'd dive right in and try to get Haiku to
| daily-driver stability on the platform. There is work being
| done on porting to ARM already, and my hope is that as the
| X86/64 platform matures, focus can shift to ARM and the Pi
| specifically.
| MisterTea wrote:
| I think its very disingenuous to call the lack of hardware
| support a "missed opportunity". There is a Pi port in
| progress but the Pi as a platform outside of Linux is a
| mess. Its not a well documented SoC and does weird stuff
| like boot via the GPU using a binary blob and other
| proprietary crap. It also has a different DMA architecture
| so drivers developed originally for PC hardware need to be
| modified. Ironically its a not very open source friendly
| SoC.
| [deleted]
| ranger_danger wrote:
| Not everyone is a programmer.
| bitigchi wrote:
| While I understand the disappointment regarding new platforms
| and hardware support, current number of Haiku contributors is
| relatively small considering the list of things to attend to.
| Please consider contributing, every small bit counts:
| https://www.haiku-os.org/community/getting-involved/
___________________________________________________________________
(page generated 2021-11-30 23:01 UTC)