First, thank you for the work of getting the radeon_hd driver into as good a shape as it is. My Haiku X64 works much better with it!
Can you also post links to where in the Haiku source the Radeon driver and accelerant are?
It looks like the accelerant is in /src/add-ons/accelerants/radeon_hd, just want to be sure.
I didn’t see a specific radeon_hd driver.
Also, I see the older documentation on making your own video driver, but is there more documentation that better describes the boot loading of the video driver and how the app server /BGL Window use the driver?
Speaking of BDirectWindow… I’m missing the Haiku counterparts of glXSwapBuffer, glXMakeCurrent and other vital OpenGL functions. I grep-ed all over the headers but found nothing of use. OpenGL requires a current context to draw anything so I’m at a loss where it get’s it from.
That’s not so bad. To deal with Android I had put in EGL support already. But I prefer pure OpenGL if I have the choice. EGL is somewhat “different” than OpenGL… not always in the nicest ways possible.
Concerning BGLView that’s the only way to get it, right? Just so I get this right, important is only BGLView not BDirectWindow? So I could produce a BGLView and place it into any BWindow? That would be kinda neat
Thank you! I would like to better understand the screen rendering flow. It seems that Mesa is an extra layer behind a layer. My understanding is Vulkan should remove these layers, and put more on the application developer.
I’m really curious if the accelerant can implement Vulkan and the app server use it directly (or what ever context window). Then OpenGL could be written using the Vulkan driver as the layer and bypass Mesa altogether. It seems the Linux Radeon Vulkan driver is not in Mesa, though the Linux Intel driver is.
Yes, BGLView can work both in “direct” and “indirect” modes. For example, the ScreenSaver preview uses “indirect” rendering, while the screensaver running fullscreen uses direct rendering.
The direct rendering is supposedly faster as it allows to completely bypass app_server and its double buffered rendering, but I’m not sure if that’s the case with the current implementation.
Well, the main problem is the OpenGL API was originally developped in the 1990s. Video cards have changed quite a lot since then and several parts of the OpenGL API are either not appropriate for modern hardware, or not what most apps expect from it anymore. It turns out Mesa (and other GL implementations) have to do a lot of work to keep these old parts working, but they are not used by modern apps anymore.
OpenGL-ES removed some of the old parts, and Vulkan drops everything and starts from scratch.
It would be a lot of work to reimplement OpenGL on top of Vulkan so we are probably not going to do it. Maybe the Mesa guys will do so? Or maybe they will plug Vulkan above their stack, like they do for OpenGL and can also do to some extent with DirectX (yes, Mesa can also provide some DirectX APIs to apps).
For us Haiku developers, it make sense to plug to the backend side of Mesa, and do just that. Then, Mesa can implement whatever API is the current hype above that, and we don’t have to rewrite all our drivers and accelerants each time they change their mind about that.
I’m asking because I support two usage modes: hosted and not hosted. In not-hosted mode my renderer produces a window to do full-screen or whatever with it. In that case I would produce a BDirectWindow and attach a BGLView to it. Hosted mode is though interesting since it allows to “inject” high-end rendering into regular applications. Hosted here means the renderer puts his render window into a provided host window. Under Linux it simply creates an accelerated window as child of the hosted window and be done with it. So here I can only create a BGLView and put it into the provided BWindow. But I can not be sure it is a BDirectWindow. That would be responsibility of the user to create the right top level window. A well enough solution for me.
EDIT: “Hype” is a good word. Vulkan has it’s uses but the benefits are over-hyped. Badly written game engines (I’m looking here at certain AAA developers) do benefit from it but more due to the original design being so butt-hurt it just hurts. For a well developed engine the benefits are marginal.
For OS designers though it’s something else. You can put a Vulkan backend up and running way faster than a full blown OpenGL backend since you are set free of all management hassles. This is then the job of the Vulkan users. To be honest I would not put my money on MESA in terms of Vulkan. MESA is quite the mixed bag… and you never know what kind of explosive sweets are hidden in that bag.
Just a heads up, and have been mentioned before in a previous post, though nvidia did make C++ interface for the Vulkan API which should make it much easier situation when we would want to bring Vulkan to Haiku.
Found Here: https://github.com/KhronosGroup/Vulkan-Hpp
glX * are linux centric GL functions. We don’t use glx, so we’ll never have glX* functions
Anything glX* should be done through our OpenGL kit. Every platform has their own way to initialize OpenGL contexts… after contexts are initialized you begin to use the standard GL functions.
Everything I read about nvidia, amd or Intel drivers for Windows, Linux or Mac say the driver contains the exposed functions for accelerated open gl. The open gl library (whether Mesa, Apple , whoever) is able to query the driver to know what functions are available and do the rest in software for a given API version.
I don’t see how you get around that. It seems to me Mesa gives Haiku a open gl state machine and the associated sw renderer and headers.
No, thanks, SDL and GLEW are a pain in the rear (been there, hate that). I’m fine with some #ifdef here and there and it works. I just need to know “how” a platform does go about it. I’ll see how it works. Having to stick only to BGLView seems less troublesome than successfully injecting handling XWindows… especially hosted ones. If I get this right you can not alter a GL context while being created. glXCreateContext provides a couple of options required to get the desired behavior. I assume BGLView just creates an “all mighty” context with everything available it can get it’s hands on? Core profile or Compatibility Profile?
I think profiles didn’t even exist when the API was defined (in BeOS days). If there isn’t anything in the main OpenGL API to do it, we could extend the BGLView API to add these things.
Profiles came into OpenGL somewhere around 3.x if I’m not mistaken. It had been introduced to deal with the problem of new specifications “removing” functions and symbols instead of adding them. Basically you’ve got Core-Profile and Compatibility-Profile. Core is the default and simply means “OpenGL according to specification X”. Compatibility exists for users to allow transition between specifications without risking breaking. Basically if you create a GL context you say what core version you want or compatibility which means give me all you can. For Haiku this would mean if you create BGLView you would have to say I want Core version “4.0” for example and then only functions and functionality of Core Spec 4.0 are available and working. Everything else would give an error. I think MESA does this already so you have only to transmit that choice somehow to MESA and let it do it’s thing. Compatibility is definitely easier for you since it means “give me all you have”.
That did the trick. Compiles and loads now but segfaults… but that’s to be expected for a first time run.
EDIT: That’s interesting. It’s crashing in BPrivate::media::PortPool::~PortPool while doing unload_add_on. Is unloading an add-on not allowed/supported in Haiku yet?
