The graphics acceleration can of worms

Development
#1

I realize that nobody wants to work on this without some sort of background. I’ve come from the AmigaOS spin-offs and several of these operating systems have hardware acceleration. AROS has Mesa SoftPipe and has had it for a long time, allowing ancient nVidia GeForce graphics cards to do some good. AmigaOS 4.1 has a 3rd-party add-on called Warp3D Nova which adds full shader support and with another library, adds OpenGL-ES 2.0 compatibility as well. This leads to certain topics of what to look into.

Due to Haiku already being built with software based on Mesa, going it alone with a Warp3D Nova approach will be impractical. It should be noted that Warp3D Nova is built by one programmer named Hans and the OpenGL-ES 2.0 library that layers on top of it is written by a second programmer named Daniel. Two guys did it. Of further note, when I talked to Hans in person at an AmiWest convention, he said that Warp3D Nova is based on the SPIR-V standard. SPIR-V is the intermediate representation of shader languages of all graphics cards around today.

Mesa Softpipe has been deprecated for good reason and although old versions of Aros used it, LLVM-Pipe has replaced it. There is an HPKG file for LLVM in HaikuDepot so that’s a start. Aros didn’t even have that. The real issue is: “What does LLVM-Pipe have to interface with on the Haiku side?” The Mesa drivers may work if only LLVM-Pipe is ported but the issue is still valid. What does a 3D accelerant look like to the OS? Hopefully not X11 but maybe a Wayland derived compositor of some sort might be a reference point.

This is what has been done on other systems. Take it as you will. I look forward to seeing any progress made and questions asked.

3 Likes
#2

We are already using llvmpipe, not much point to a composer, we already have basically all the userspace stuff for opengl, we mostly need drivers for specific cards.

#3

In fact there was some collaboration with AROS on the Gallium3D port back in 2009-2010. You can see an overview here: http://revolf.free.fr/FOSDEM/2010/FOSDEM2010_ALTOS_007_Gallium3D.pdf

Why didn’t we go ahead with it in Haiku, then?

At the time Gallium3D was freshly announced. The selling point was “videocard drivers are now portable and independent from the OS”. But it turns out, this was not quite true. So, AROS went on with it anyway and got one driver working. It required a lot of work. And then it was not so easy to get newer versions of the driver. And indeed here is what you can find on AROS wiki as of today:

Supported graphics cards (gfx)

  • Nvidia 2D and 3D 2005-2011. Nouveau supports 2D from TNT through to fermi gtx5xx and 3D acceleration 5xxx to gtx4xx. It’s worth noting however that support isn’t guaranteed. Nor will potential power of a card reflect its performance under AROS.
  • Intel 2D and 3D 2006-2009. 2D for many old netbooks and motherboards. 3D for many early netbooks and motherboards
  • AMD/ATI 2D only. External monitor support only (ie little laptop internal support) for Radeon 7000 through to x600. Experimental 2D version for up to HD3xxx
  • VESA 2D fallback modes for all graphic cards (GPUs) and with screen dragging. Matrox implementation of VESA, based on testing of g200, g400, g450 and g550 typically results in slow performance.

Source: https://en.wikibooks.org/wiki/Aros/Platforms/x86_support

So, any newer devices are not supported. We were not happy with that, and so we did not go on with this project.

Now, it is a bit more clear what is needed, mainly because other, larger systems have done the work. Mainly FreeBSD and other BSD variants have found ways to import the Linux drivers. We can learn from their experience and do the same.

But on our side we have also been busy (this being a very wide “we” with many people inside and outside Haiku involved). We ported llvm to Haiku. We then updated our Mesa port to use it, and got the resulting work upstreamed in Mesa. We fixed many bugs with software rendering. We researched porting Linux drivers with various ways to approach it (porting directly from Linux, trying to plug FreeBSD’s work into our existing FreeBSD compatibility layer, writing our own drivers).

So, steps are being made, one at a time. It’s not like nothing is happening.

4 Likes
#4

@PulkoMandy

OK. That’s good to hear. I knew the old ABI v0 Aros drivers supported some old systems at least. It’s good that you’re getting done the right way instead of kludging it up. I had hoped that the sources were fairly POSIX compliant so that Haiku would have less trouble than Deadwood had on Aros.

#5

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: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-AMDGPU-Stats 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?

3 Likes
#6

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.

#7

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?

1 Like
#8

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.

#9

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. :thinking: Might not be worth it.

#10

See: https://github.com/haikuports/haikuports/pull/5792

Mesa 21.0 was tested on Haiku without any major issues.

There are devs working on a DRM-based Intel video driver port and testing the new Mesa LLVMpipe driver update…

2 Likes
#11

You will have to wait for mesa 21 a bit because there actually were major issues in testing :)

#12

If you want to test Mesa 21 you can add my repo - [http://haikuware.ru] and update packages: (http://haikuware.ru/package_list.php?repo=lote) (Haiku x86_64 only)
It very stable and usefull for me.

4 Likes
#13

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.

#14

There are also three versions of the blender in my repo, which work perfectly with the new version of mesa.

4 Likes
#15

Well… three issues :slight_smile: I added a list to https://github.com/haikuports/haikuports/pull/5792

1 Like
#16

Good day @3dEyes,

Nice work with Stellarium (though crashes on quit, -and the window is not resizeable :cry: -, is quite usable), you had this kept for yourself, huh? :crazy_face: :crazy_face:

screenshot12

This is something I was waiting for! Thanks a lot. :+1: :+1: :+1:

Regards,
RR

3 Likes
#17

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.

#18

I remember I got this (from him I think) and we ran it hardware accelerated on my nVidia driver, years and years ago… :wink:

3 Likes
#19

Simplified:
OpenGL ES -> SurfaceFlinger -> Hardware driver -> Hardware

Then, other pieces like: GrAlloc (graphic (virtual) memory allocation manager)…

1 Like
#20

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.