Good day @3dEyes,
Nice work with Stellarium (though crashes on quit, -and the window is not resizeable 
-, is quite usable), you had this kept for yourself, huh? 
This is something I was waiting for! Thanks a lot. 
Regards,
RR
7 Likes
Before I let the matter drop, how do Android-style binary blobs map into Mesa? Of course the AArch64 ARM chips are a tier-2 architecture after Intel x86 and AMD64, but Android doesn’t use the same graphics pipeline as Linux desktop does. No X-server nor Wayland might mean a more streamlined architecture if somebody could at least figure out how the binary blobs are supposed to map in.
I’ve got a Cubox i4Pro that could do with a more efficient OS than Linux since SolidRun and Motorola seem incapable of supplying non-Linux OS architectures for the iMX.6 SoC and every SoC has the same GPU core as any other model machine with the same SoC.
Correction: After some searching online I found that the Etnaviv driver for Mesa has already been upstreamed and is open-source. No need for binary blobs here!
Comment: Holy Monkeys! These things have appreciated in value! I got mine for $30 less several years ago.
I remember I got this (from him I think) and we ran it hardware accelerated on my nVidia driver, years and years ago… 
3 Likes
Simplified:
OpenGL ES → SurfaceFlinger → Hardware driver → Hardware
Then, other pieces like: GrAlloc (graphic (virtual) memory allocation manager)…
1 Like
Thanks!
I hope this situation gets ironed out. I don’t expect miracles but the RasPi 4 has delivered on so many levels and other SoC machines have reverse-engineered drivers as I’ve discovered my Cubox has and my PineBookPro has. If discrete graphics cards play hard-to-get as far as drivers go, maybe ramping up the development of AArch64 might be an option.
1 Like
I’m just a Haiku user, however looks like AMD is trying to refactor Mesa interaction with the Linux Kernel:
https://lists.freedesktop.org/archives/dri-devel/2021-April/303671.html
The discussion is intense and touch: performance, security, why only Wayland approach (BSD, android excluded), VR headsets, browsers, why relay on Linux’s ABI api and so on.
Very complex and a good reference point when a new user makes a complaint about why Haiku lacks GPU acceleration.
Even with all the money and resources, Amd & Intel developers have a difficult task making their drivers faster on Mesa.
1 Like
It’s mesa package from my LOTE repo?
“mesa package from my LOTE repo”
I am using x86_64 hrev55306 -
If I load your repository the mesa package does not show up (others do), and if I download the hpkg it won’t install if I open the file in the installer (nothing happens when I click “install”. Are there any prerequesites that I may be missing?
This is a bug in HaikuDepot app. Once you added the repo you can install mesa using pkgman.
3 Likes
I, for one, would still very much like to see support for certain NVIDIA cards. I have a laptop with a Quadro FX 3700M (G92-series core), which is only supported by VESA under Haiku, and consequentially doesn’t perform nearly as well under Haiku as it does under Windows or Linux. At this point, that’s the only major issue preventing me from using Haiku more regularly.
design by committee often leass to issues like this.
To quote Marcus Aurelius
waste no more time arguing what a good man ought to be, be one.
much of the performance issue, is that, well, imho, linux graphics subsystems ate full of multiuser multi terminal kludges, before the code path optimization issues arise in discussion.b
haiku needs a bare metal approach, remove all abstraction and flow changes except those that are absolutely helpful and required.
i studied many graphics driver design docs, the amount of obviously duplicated work in translation, jit, ir, rendering pipeline, just ridiculous.v
the goal should be to build the eimplest pipeline from application to hardware.
7 Likes
You meant *nix, as all this true for every unix too.
And maybe limit it to 640x480x16 colors, as god intended?
It seems nobody cares about that at*nix front. What do you think what can be the reason?
Somehow people always comes up with problems where the simplest solution fails. Any idea to solve them?
1 Like
TempleOS tried to be the most open OS that has ever been and the author lived to regret the 640×480 comments when he found out that VESA modes went higher within standardized mechanisms. I’m not going to criticize his motives though. We may live to regret having depended on communist Chinese to supply our equipment before too long. That’s a can of worms for another thread, however.
Vulkan seems to solve many issues when used in conjunction with other backward compatibility mechanisms. It’s just a matter of getting to that point.
2 Likes
being as haiku and beos never had any aaa games etc, I say pick the cleanest, most elegant, simple performant api, probably vulkan,and support just that, If people want open gl and the wankery of wayland etc, let them deal with that on their end.
K.I.S.S.
2 Likes
ANGLE plus the Magma subsystem of Google’s Fuchsia OS will get us OpenGL-ES on top of Vulkan. Getting OpenGL on top of OpenGL-ES can be done using GL4ES. The only thing heavy about it is that Magma isn’t done yet (nor is Fuchsia), and GL4ES (as well as Fuchsia) is geared toward handheld devices like the OpenPandora and single-board computers like the Raspberry Pi and others. That will make it simple and small with a minimal number of function calls to implement from the Zircon kernel, (100 function calls, ballpark range, for a complete Zircon kernel emulation layer), will hopefully be easier to implement than Linux drivers, hopefully. Might be a tougher call but at least it avoids X11 server and Wayland.
It’s simple but it isn’t finished yet so it’s hard to judge. Now does that all make sense? It’s where I was coming from if you missed my posts on the Fuchsia off-topic thread.
Since the licenses are generally compatible between them all, we just need everything else set up so we’re ready for it once the Magma code drops on AArch64 devices. Unfortunately, I haven’t looked at the code for some of those links and a lot can happen between now and then.
The idea that BeOS never had “aaa” games is not true, there were a few ported. The issue was more that BeOS was always 3 - 5 years behind the curve, because no one wanted to port anything to it because the user base was so small it was not financially viable - certain ports never saw the light of day because of this. I think Haiku will suffer the same fate for the same reasons.
I don’t play games, and when I do I tend to play retro games, so what Haiku can offer me is fine really. If I want to play something a little more modern, I probably go to my Xbox 360. For me, the modern graphics subsystem and 3D only matter for practical operations.
3-5 years BEHIND the curve? You forgot that the gaming industry didn’t write multithreaded code for 5-10 years AFTER the BeBox.
Well no. You have things like Unreal Tournament and Quake, I think neither came out at the time, and you had Corum 3 which did, and Worms Armageddon that I certainly played but I don’t know if it was released. But most of the time, there was no incentive, and these games were 3 or more years after original release.
Worms came out first on Amiga and was originally written in Blitz Basic. It had to be rewritten in C++ before it could be ported to other platforms.