Well there is already a radeon_hd accelerant, but that’s only the 2D part of the driver… and as far as I know it doesn’t even initialize the 3d engine. Haiku’s native radeon_hd 2D driver was written mostly by kaliisti5 in recent years.
I’m not sure if haiku implemented what Mesa needs to run it would end up being called an accelerant (technically the same) but would probably more resemble or actually be a Linux DRM driver (direct rendering manager nothing to do with rights management) Regardless of what that part looks like end users should only care about the features the drivers provide such as APIs, and functionality HDMI , HDMI audio etc…
waddlesplash could comment on that more accurately I imagine… also he had a sort of layout as to what it would look like planned out, what we aren’t sure about yet, is what the best way to go about writing the kernel portion is from a maintanability perspective, as well as with ease of keeping up with driver updates.
The BSD’s have wrappers for Linux drivers, but they are all have one issue or anohter, such as being ugly or missing features, or being out of date. There is also a partial native Haiku to Linux wrapper that hasn’t been finished written by hamish.
Hopefully you can infer my bleary, red eyes as I say that.
Maybe kaliisti5 can comment further on the work it takes to implement a driver in Haiku. If I wanted to pursue this idea, would it be better to buy a Radeon card for my desktop or hack away on my Thinkpad X230 or X220?
As for the BSDs, I couldn’t find much through Google about their graphics wrapper. Is it possible to do something similar in Haiku, but convert the driver before compile time? Meaning, can we simply translate the driver’s Linux facing interface (DRI think) into something for Haiku? I’m wary of slowing down the system with a real-time wrapper.
That’s what the BSD wrapper is mostly, there are some things that happen in the runtime but most of it is done at compile time where it can be at least.
I would suggest looking at updating our current software mesa implementation to 18.x to familiarize yourself with that aspect of it first if you want to help. There are some changes to the winsys stuff in 18.x that have broken it…
Your best bet graphics card wise is a recent GCN graphics card or Intel gen9 (skylake) as they have the broadest driver coverage currently, on the Intel side it’s the first chip from them to have an official gallium3d driver (Iris). I would suggest familiarizing yourself with the mesa code first though as suggested above before bothering to buy anything though.
Yes agreed. I’ve been digging through older recipes to see what changes to get an idea how things tick. That and just because it compiles doesn’t mean it will work. Godot engine for instance compiles for Haiku, but is currently broken at runtime
Although you see this: GalliumContext: CreateScreen: Using llvmpipe (LLVM 5.0, 128 bits) driver. Using GLES3 video driver OpenGL ES 3.0 Renderer: Gallium 0.4 on llvmpipe (LLVM 5.0, 128 bits)
Realize that there is some expectation on OpenGL 4.x driver feature capability. Knowing this, Mesa 17.1.10 can handle Godot 3.0.6 just fine - you have a specific 3D driver feature limitation, henceforth ‘llvmpipe (swpipe)’.
This status did not change in Mesa 18.3.1 (current). There is no need to update Mesa for Haiku. This will
not change anything on this matter - by just updating to a recent Mesa.release, Going down that path may make the gods angry… or cause you to react in disgust…
Best route is to use Linux/BSD/other for now (aka best tool for the job) - until the Mesa 3D driver acceleration issue(s) can get resolved for Haiku. Do what works for Haiku for now. Just a suggestion here.
This makes sure no progress is made. If someone is interested in fixing the problem and your answer is “nah, just run Linux and wait for someone else to do it” we will not get anywhere.
I already mentionned hamishm work on a Linus compatibility layer in this thread. It’s available as a patch series on Gerrit. I suggest starting from that, and trying to use it to get one of Linux drivers to build. Hamish work shows the kind of things that needs to be done, but the Linux kernel has a lot of internal APIs and we need to implement most of them to get graphics driver working.
Or, we may wait a little to see if Android gets somewhere with providing a stable API between kernel and drivers. This could reduce our work to implementing just that API.
In the name of progress, I have been using Godot in Linux as a working reference for what should happen in Haiku. I have yet to get Godot compiling in FreeBSD or OpenBSD. I’d use those for this because I find Linux to be abominable. But, I’ll use what works for the purpose of a working reference. I’ve even run into problems in Godot on Windows which prevents me from using that as a reference. Linux is only slightly less abominable than Windows. I’ve been learning alot. My only wish is that there were InRealLife::more_hours_in_a_day(). Is there anybody available with the know-how to implement this functionality?
I have no qualms with angering the gods. It has been my life-long mission and birthright to do so. My biggest reaction of disgust is towards secretiveness in an otherwise open project. Can you articulate a practical reason for why you are saying what you are saying? You seem to be dancing around the topic and protecting your claimed works from having more eyes on the issue. Why is that?
I have made a very simple diagram describing my current understanding of the components of the graphics stack that are interchangeable between Linux and Haiku. As you can see, for certain cards which exploit the Gallium design architecture, it may be possible for a few dedicated individuals to port an accelerated driver from Linux to Haiku.
From what I understand, Hamish (the kiddo working on the GSoC project?) was working on writing the “Hardware agnostic, OS specific code” in the hexagon second from bottom in the above diagram.
(Laugh if you want, but please give feedback)
EDIT: it should be possible to write a converter that translates Linux’s system calls to Haiku’s system calls that is performed at compile time, which means that there is theoretically no performance penalty. It would be a Haiku native driver.
Also, there is the issue of interfacing that driver with Haiku. How? Can we rewrite the app_server to take advantage of the new driver or is that stupid?
Something like your drawing is very good. I look at it like this for Haiku: Hardware → Kernel (DRM) → Driver (ICD) → Accelerant → app_server
You can review video driver breakdown architectures from X.org point of view and AMDgpu-pro development, as well as the Haiku version for video driver development on the wiki (I think it was based from the BeOS book version). You can add a layer of breakout for the kernel-side (like DRM) versus userland-side to help the visual on where things lay out moreso for development purposes and better collaboration.
Again, I think the wiki has this recent info.
Note:
The Matrox driver was used as an example in the wiki.
With Mesa 17.1.10 on Haiku, implementing " export MESA_GL_VERSION_OVERRIDE=4.5COMPAT" will promote the OpenGL 4.5/GLSL 3.30 compatibility-mode features of Mesa. Normally, it defaults to OpenGL 3.0/GLSL 1.30 under Haiku x86 (gcc7) and Haiku x86_64. You can test OpenGL 4.5/GLSL 4.50, but with expectations that not everything (certain GL 4.x extensions will work properly or successfully). Check with the Mesa matrix website on what extensions are expected to work with a driver.
System calls are for userland applications. Drivers run in the kernel. We need to implement the Linux API in some way, we can’t just “translate system calls.”
Thanks for the reply, Waddlesplash, I was unaware of the difference. However my idea was to implement the driver as a userspace program. This would hopefully make porting X and Wayland applications by only copying what is absolutely necessary to get accelerated graphics, while the app_server (or some hypothetical acceleration server) does what DRM does, which I believe is to structure safe, direct access to graphics hardware without the possibility of crashing because of attempted simultaneous execution of code in the command que.
Thinking about it in retrospect, it seems kind of dumb.
Mesa already largely is a userland driver, everything in the kernel is there for a reason, be it performance security, or flicker free boot etc… doing that stuff in a different way than Linux just means your hypothetical driver would likely see very few updates in the future by other developers expecially those outside of the Haiku project.
You really should get a better understanding of how all this works before proceeding. A lot of what you are saying has holes in it. This is probably a good place to start for understanding Linux’s graphics drivers https://dri.freedesktop.org/docs/drm/gpu/index.html
This is more or less what graphics looks like on Linux today. libdrm and the kenrel DRM side of things is mostly what is missing from Haiku. It’s also worth noting that there is no such thing as a 2D accelerator in a modern graphics card, so making something like Glamor on Haiku for the App server might be useful then again maybe not as Haiku’s API may not lend itself to that.
The GSoC student was Vivek Roy, and unfortunately you can mostly forget about his work. His mentor disappeared after about 1 month, and all he did was copypasting some header files from Linux without much clue of where he was going. Also this was not archived properly so we don’t even have this work as a patch we can apply.
Hamish was also a GSoC student, he worked on porting Java to Haiku back in 2012, but also contributed to other things in Haiku, including what I think is currently the most advanced effort for porting 3D drivers to Haiku.
This is not true. The userland side of things is just the OpenGL state machine and shader compiler. The kernel-land side of things does memory management, ring buffer / command queue control, DMA, etc. … it’s why the kernel drivers are pretty large.
Yeah it is true… its described this way everywhere it is documented. And as I said the parts that need to be in the kernel for performance are. Mesa is self described as a userland driver.
Not sure what you are on about the state trackers and compiler part of it not being part of the driver… they literally only target the GPU hardware… as part of userland side of the driver. Without the userland side of mesa you certainly don’t have a 3d driver at all.
