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.
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.”
