The userland side of things, yes. We have Mesa running and adding that part to the driver should not be too much of a problem.
In the kernel side, unfortunately, POSIX says nothing about what to do. And so the drivers heavily rely on Linux internals. And these internals keep changing at every Linux versions, and the drivers are very complex. If you look at things like this: The AMD Radeon Graphics Driver Makes Up Roughly 10.5% Of The Linux Kernel - Phoronix you get an idea how large it is.
For a while now the AMDGPU kernel graphics driver has been around 2+ million lines of code making it the largest in-tree kernel driver.
With all of Haiku git repository being currently less than 6 million lines of code, this gives you an idea of the scale of these drivers.
This is somewhat nuanced by this:
Though as reported previously, much of the AMDGPU driver code base is so large because of auto-generated header files for GPU registers, etc. In fact, 1.79 million lines as of Linux 5.9 for AMDGPU is simply header files that are predominantly auto-generated. It’s 366k lines of the 2.71 million lines of code that is actual C code.
However, I think we would still not be happy to increase Haiku sourcecode size by more than 33% for a single driver. And the other drivers in Linux are a lot smaller, fortunately, at a few hundred lines of code each. But the fact that Linux even allows 2 million lines of generated code to be included in their repository has me a bit worried about the overall quality of their code. Sure, they get things working, but is the price worth paying?
Generated code is not “wrong”. GPU drivers are performance critical so using generated code certainly helps to get the performance you need. But I can understand the reason on not wanting that many code lines in a repo. That said we have two major players in the field: AMD and nVidia, wenn we look at the free driver side. So this makes two potentially line-count heavy drivers to include. In my opinion that’s acceptable if you can support with this the large majority of GPUs out in the wield.
Generating code is not wrong, but storing the generated code in the Linux kernel instead of the sources and tools to generate it would have been better. I am not even sure if the way it is done complies with the GPL?
GPU drivers and GPL has always been a problem. To get GPU support you somehow had to give a hand to GPU vendors by closing an eye here and there. I’m not happy about that either but truth is today an OS is expected to have GPU HW support, meaning, shadersand/or opencl.
If open-source drivers are unavailable for a lightweight architecture such as Haiku, perhaps adapting the AmigaOS4 enhancer pack drivers for Warp3D Nova to work from Mesa would be mutually beneficial. They are owned by A-Eon Technologies but are low-level PPC code for AmigaOS 4.1FE2 and are closed-source. Might not be worth it.
Your mileage can vary though. That last package I could test still did not work properly and caused apps like Blender to segfault. Not sure what causes the problems. Hopefully the final package magically starts working here.
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 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.
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.
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?
Might not be worth it.
I added a list to 
-, is quite usable), you had this kept for yourself, huh? 
