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.
Linux / MacOS X â glx https://cgit.freedesktop.org/mesa/mesa/tree/src/glx
Haiku â OpenGL kit (I call it hgl sometimes in mesa) https://cgit.freedesktop.org/mesa/mesa/tree/src/hgl
Windows â d3d Direct3D
If you donât want to write 3 different sets of code to init OpenGL on each platform, things like libSDL and glew offer an abstraction layer.
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â.
Managed to get it all compiling so far but I canât run it. Something strange is missing:
resolve symbol â_ZN13BDirectWindowC1E5BRectPKc11window_look11window_feeljjâ returned: -2147478780
I used this code to create the window (according to API documentation):
pWindow = new BDirectWindow( BRect( 0.0f, 0.0f, ( float )pWidth, ( float )pHeight ),
âwindowâ, B_DOCUMENT_WINDOW_LOOK, B_NORMAL_WINDOW_FEEL, 0, B_CURRENT_WORKSPACE );
Something wrong here?
You may need to link in some extra libraries: libGL, and probably libgame for BDirectWindow.
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?
No ideas about this? Is there a special process involved in unloading modules that is not documented?
No, this should work as expected (just be sure to not call code from the add-on after unloading it, of course). But the feature may not be used very often so there could be bugs.
I did some more testing and step through the code around the unload process and there is nothing wrong with the code. I even reduced the process to just loading the image and then unloading it. With some modules unloading just plain out crashes in the very same location. From what Iâve seen there are only two possible reasons for the segfault:
- Compiler Bug in the GCC 5 64-bit used in the nightly builds. Would be not a bad idea up update the GCC with the latest official source code unless the changes made for Haiku are tremendous
- Haiku sources responsible for buildnig libmedia.so contain a bug in the unloading process. I canât load the sources into the debugger otherwise I might see better where the crash happens.
Personally I opt more for a bug in the Haiku sources than the GCC 5 compiler.
1 Like
While trying to figure out this problem I stumbled across another. Some library does not load and the error is just âMissing libraryâ. This is not informative. I went through the code in your repository and found the following in file src/system/runtime_loader/elf.cpp line 131:
gErrorMessage.AddString(âmissing libraryâ, name);
This would mean Haiku tries to load a library with an empty name. This sounds like a bug to me. I checked the library in question with readelf -d and there is no (NEEDED) library with an empty name in there. Something is wrong with the image loading there. Could it really be the compiler messes something up?
1 Like
This could be solved if you comiple you own debug enbaled libmedia and then use this debug lib for your porgramm
DEBUG=1 jam -q libmedia.so
LD_PRELOAD=/path/to/debug/libbe.so Debugger /path/to/crashingApp
This works on the 64-bit hybrid GCC nightly build? Special sources GIT for this target?
I compiled the libmedia.so and did some testing:
- run app as-is on nightly build: segfault on add-on unload
- run app with DEBUG=1 libmedia.so preloaded: no segfault, finishes correctly
- run app without DEBUG=1 libmedia.so preloaded: no segfault, finishes correctly.
I conclude from this the nightly build is broken since both debug and release build libmedia.so from GIT sources pulled today are working correctly.
While trying to figure out this problem I
stumbled across another. Some library does not load and the error is
just âMissing libraryâ. This is not informative. I went through the code
in your repository and found the following in file
src/system/runtime_loader/elf.cpp line 131:
gErrorMessage.AddString(âmissing libraryâ, name);
This would mean Haiku tries to load a library with an empty name.
This sounds like a bug to me. I checked the library in question with
readelf -d and there is no (NEEDED) library with an empty name in there.
Something is wrong with the image loading there. Could it really be the
compiler messes something up?
Interesting, I was building openjdk last night (with gcc 5) and had the exact same problem trying to run any of the resulting binaries. Doing âLIBRARY_PATH=/system/lib/x86:$LIBRARY_PATH {binary}â worked here (gcc2 hybrid), but this shouldnât be needed, so Iâm wondering if there is a recent regression somewhere (gcc5 issue, perhaps).
Iâve ported my employers OpenGL embedded app to Haiku (the more platforms the merrier, primarily for testing), Mesa 17.02, x86_64, LLVM4.0 sw pipe, however using the default BGLView constructor, I am stuck with the 3.0 compatibility profile. Does anyone know how I can set the Core profile, ideally > 4.1? Mesa3D supports it, so itâs just a question of configuring it. By default, itâs 3.0 compatibility
BTW - performance is suprisingly good with SW rendering on a 4(*2) core system
1 Like
Hi Zenja,
Did you try via MESA_GL_VERSION_OVERRIDE env variable :
export MESA_GL_VERSION_OVERRIDE="4.1" ?
Or â4.1FCâ, FC for Forward Compatible)
This seems to works fine:
MESA_GL_VERSION_OVERRIDE="4.1" GLInfo
You may have to override the GLSL version too, via MESA_GLSL_VERSION_OVERRIDE.
Give a look here for details:
https://www.mesa3d.org/envvars.html
If you could share with us some screenshot, that would be great.
2 Likes
Hi Philipe, thanks for the suggestion, it does report the core profile version, however it doesnât behave 100% as expected (eg. same 4.2 code base under Windows/Linux and 4.1 under MacOSX work fine, but Mesa has issues with GL_COMPRESSED_RGBA_BPTC_UNORM_ARB, since it reports it supported but doesnât). We use BPTC (BC7) for all our resources, and a fallback path for OSX (4.1) which at runtime coverts all BC7 resources to vanilla pixmaps, however it screws up video playback since the CPU cant keep up. Mesa reports that it supports GL_COMPRESSED_RGBA_BPTC_UNORM_ARB, however it doesnât convert BPTC images, so itâs best for us to define 3.3 profile (and 150 as shading languege) since GL_COMPRESSED_RGBA_BPTC_UNORM_ARB doesnât exist in this version, and our fallback will convert BC7 images to raw pixmaps. GLSL version 150 is sweet since the fragment shader knows the function texture(), while 140 and older require texture2d() - which would require our OpenGL ES2.0 codepath.
Anyhow, Mesa version 3.3 (150 for GLSL) is as good as we can expect for SW rendering.
Sorry Philipe, Iâm not at liberty of showing screenshots of company R&D projects, however a simple google search will show that I work for Atlas Gaming (http://www.atlasgaming.com.au/), and our home page has videos/pictures of some of our products, so just imagine a yellow title tab over our game screens This entire exercise was to port our stack to another platform, since more bugs are discovered this way.