https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/
1 Like
That link documentation is glorious until you want to read the chapter 6 
Thanks PulkoMandy. How relevant is this in the modern era?
Nothing changed since then.
3 Likes
I’m planning to dissect the internals because random hoard crashes are really annoying to me. That’s why I revived the unit tests. I even have a fairly reliable reproducer (#14376). However, I want to release Koder 1.0 (really soon™) before that.
Agreed. Another important thing is available tooling. If Haiku had something akin to Visual Studio in terms of productivity, lack of 3D acceleration would not be a problem.
4 Likes
15 posts were merged into an existing topic: Koder - new native code editor
I wonder if polls were sent out to various Linux, Mac, and Windows tech communities, in regards to why they find the idea of a “new” OS so unappealing. Or more precicely, it would probably be best to adress such a poll to a tech community that is known to be composed of members who use more than one OS on a regular basis, and by choice at that.
I freaking LOVe what I am seeing in Haiku right now, and can not say enough about the organization and progress of those involved…
… who I am just now getting to now afte years apart from BeOS.
That said, I could compile a list of reasons why I would find the current state of Haiku off putting, if I were not a semi-religous zelot when it comes to the OS my self. There is lots to complain about, and lots to scare people away, and I don’t see it at all unlogical for people to be scared off by the lack of hardware acceleration just as much as they would be by Web Positive. After all, they unlike many of us, have nothing to compare Web Positive with accept more mature alternatives, so they’ve not way to guage how far it has progressed since BeOS days, not to mention Haiku itself.
Anyhow, that’s my rant, stick a spoon in me.
I am quite a noob when it comes to C++ programming. I am fooling around with Launch box and may contribute a TINY patch over the winter break while I’m not writing my dissertation and initiating a pharma startup.
Would it be A) possible and B) smart to write a multithreaded acceleration server as part of the Haiku kernel? No DRM, no abstraction, no compatibility layers. We already have MESA with the OpenGL 3.3 standard, which means we also have Vulkan. This means graphics drivers will be easier to write (and port). Rather than porting complicated drivers, we can port simpler drivers made to use Vulkan. This solution follows the “BeOS way” and I would call it elegant.
Anyway, that’s a crazy idea, someone with experience please come laugh at me and tell me what a better way would be.
2 Likes
No it doesn’t mean we have vulkan as there is no vulkan software renderer… other than some partial proof of concept ones out there.
Also porting any of the hardware Vulkan drivers in Mesa, also means porting 99% of what it takes to get all the other stuff Mesa can do working also. Effectively Vulkan is a is not a driver, it is just an API just like OpenGL, Mesa implements the drivers that provide these APIs, in the case that you have a recent Radeon Graphics card, there are state trackers implemented on top of the lower level Gallium3d that are called radv (Radeon Vulkan) and opengl that provide those APIs, among others. The platform specific stuff is also broken out into the winsys layer in Mesa so it doesn’t have to be implemented separately for each state tracker or driver.
Also note there is usually some variation in which features each state tracker implements on top of each gallium3d driver. Also the internals of how all this generally stays the same but it has been evolving a bit over time with different intermediate formats and such internally etc…
Also there are trade offs with hardware acceleration, simple applications or pathological benchmarks of 2D applications may see a slight drop in performance tue to round trip latency to the GPU from the CPU, while more complex applications will benefit very noticeably from hardware acceleration (browsers, graphics applications, media applications, games etc… ).
Also as an asside, Vulkan is perhaps a thinner API, meaning it’s state tracker in Mesa is simpler, but it is lower level meaning applications that using it is more complex, another design tradeoff… I woudn’t call Vulkan less complex as it just moves the complexity to a potentially more appropriate place.
Thanks cb88, I wasn’t aware of the other components inside Mesa. I’m also slowly learning what the graphics stack actually is, because every time I read something new I have to parse what the author means. I’m convinced that about 1-5% of the documentation I’ve read online is written by authors that actually understand graphics. The rest are written by authors that have somehow written graphics software that doesn’t immediately fail at compile time, and their knowledge propagates forward due to this partial success. There’s a lot of techno-babble.
What I mean is that we are able to implement a Vulkan hardware renderer, because Haiku supports Mesa 17.X, which implements Vulkan and OpenGL 3.1+. Is this statement incorrect?
Also, to respond to your aside, I sympathise with this concern. It will be possible to get off the ground a little faster than with OpenGL hardware acceleration, but at the cost of rewriting applications to accomodate the shift in complexity.
It’s possible but not easy, Haiku does not yet have the kernel driver part that Mesa needs for hardware drivers to work.
Please explain this. By kernel driver, do you mean the driver that gives the accelerant access to the hardware?
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.
All the more reason to work on 3D drivers!
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.
1 Like
I think cocobean said he had 18.x compiling on haiku.
Ah maybe so, still checking out what patches needed to be made to get mesa working on Haiku is a good place to start also.
1 Like
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.
1 Like