Aros/Developer/OpenGLDev

mesa.library - "old" library, publishes GL API, no longer per opener library base, now true per task GL context
glu.library - "new" library, publishes GLU API, previously this API was available via libGLU.a linklib (static linking)
vega.library - "new" library, publishes OpenVG API which is accelerate using Gallium3D, not available previously
egl.library - "new" library, publishes EGL API, not available previously, this is a "native" API for context creation and control

There are two new examples in Extras:Demos/Mesa

lion - EGL + OpenVG
eglgears - EGL + OpenGL

Note that the ABI (LVO's) of glu, vega and egl is NOT FINAL and might still change - treat this as ALPHA release. If you release now any applications using these libraries, be prepared to recompile at some point. These libraries will become "stable" after the port of Mesa 7.10.

GL Appliction wants to create a GL context
mesa.library calls gallium.library
gallium.library selects the driver, in this case softpipe.hidd
softpipe.hidd loads, but first gallium.hidd needs to be loaded (for base class)

Another topic would be that would be in the same line as the others is a StormMesa wrapper that could call the AROS 68k version of Mesa.library that has yet to be written (or the other way around). IMHO we should do simpler thing. We should convert mesa.library into StormMesa-compatible API. And that's all. Personally I think the main AROS mesa.library should be one with C argument passing so that we can get rid of the internal wrapper functions increasing the speed. For backwards compatibility on m68k then the proper wrapper libraries can be provided that then call this library. I remember i once checked the SDK. Just rename the library and change LVOs to match. Mesa is Mesa, functions are the same. You could also have MorphOS-compatible API. mesa.library already exists, it works with either Nouveau or software 3D driver. It just needs to be extended to support more hardware (this includes also hosted environments).

There is an idea not to extend Mesa with Gallium based Linux-hosted driver, but to provide the complete "GL library" replacement for Linux-hosted that just wraps the host OpenGL implementation. While I'm not really happy with having more than one OpenGL implementation due to maintenance overhead this will generate on my work, I do recognize that this is, from capabilities standpoint, much better solution than having Gallium driver that uses hosts OpenGL. If someone wishes the provide stormmesa or tinygl, then a wrapper is the only way I can see it for now. While all of the libraries implement the same OpenGL API they each also have specific context/buffer handling functions. Those functions are different as they are not covered in OpenGL standard. The different is not only on surface it is down to design level - for example StormMesa provides 3 or 4 public structures with public fields that in theory could be modified by some existing software. AROSMesa provides just 1 opaque pointer and hides all implementation details from client. And these implementation details changed already 3 times which would mean 3 times breaking applications if the fields were public or not being able to accept advancements in Mesa.

Personally I think a wrapper for Linux makes much sense. Although I am a big proponent of open source, the closed source Linux drivers of both NVidia and ATI/AMD typically support newer cards and perform better than the open source Gallium/X drivers. A wrapper for Linux can the host Linux version have better performance than the mesa/Gallium native version and support more hardware. If someone wants to write a host wrapper they need to provide the AROSMesa functions necessary for creating an AROS compatable GL context. This stuff isnt defined in OpenGL. Yes, that's exactly how I see the wrapper being created. It also needs to implement the same AROSXXX functions mesa.library has. The only thing we can change now with ABIV1 transaction is naming - instead of AROSMesaXXX we can call them AROSGLXXX to be more generic. This could also be done for Mac and Windows and even for (Win)UAE giving very good 3D performance for m68k emulated programs.

I would not rename it just for sake of m68k. I would rename it however if there is someone actually commits to working on Linux-hosted wrapper. Then it makes sense to have gl.library that might have different implementation/opening different implementation. Both "mesa" and "wrapper" libraries will have to have synchronized API and ABI and provide compatible SDK (headers + linklibs). Now each time I port Mesa I need to do a rather wide ranger of regression tests to make sure I didn't damage everything. With this wrapper, I will have to be doing "cross compilations" tests as well - for example compile with SDK of "wrapper" and then run with "mesa". I think the "wrapper" idea itself is valuable and will be much better for hosted environments than current softpipe in Mesa. I just want to make sure it is understood that there is a reoccurring cost associated with it.

Then I would go for least invasing, future looking approach now. Rename mesa.library -> gl.library. Rename all AROSMesaXXX to AROSGLXXX. If the virtual gl.library gets created at some point, it will replace "mesa" gl.library. Mesa will go into background. The API however will still be AROSGLXXX, the SDK will not change. OK, but I do foresee some more discussion on the AROSGLXXX functions and the SDK when writing the gl ABI reference for ABIV1. IMO it is always good the have an ABI looked at by different people before setting it in stone.

Personally we would switch the function calling to C argument passing and call the library mesa_c.library then. This switch would remove the need for stubs and wrapper functions in the library. Will this give me access to library based within Mesa functions? I would also have to validate that the stubs are no longer needed when using OpenGL Extensions (calling a library function from pointer to function acquired from AROSMesaGetProcAddress) Yes, this is handled by the relbase patches and the peropener support in genmodule. You should be able to get the libbase at any place in the library using AROS_GET_LIBBASE. Pointer to functions of the shared library are also handled; will need to be checked if it handles all corner cases for the gl.library. Hmm, peropener rigs a warning bell. The libbase cannot be peropener, because support libraries will not work with this. It was peropener at some point, but I had to change it to single to be able to have glu.library.

Additional challenge lies in fact that AROS is one process from host's POV and as such can only have one GL context bound at a time, however each 3D software run under AROS must have it's own GL context bound at the same time. For such an elegant hack as this, I think 'only one 3D window at a time' is acceptable for now. Unless, of course, you want to deal with some sort of compositing manager thing. It's more a problem of sending commands to host's GL than compositing the results of rendering. What I might need to do it to spaw a separate linux thread for each 3D AROS task. Separate linux thread will have its own linux GL context and AROS task will send commands via queue to this thread. This has however a high chance of killing the performance especially on machines which have just one core.

There was also some discussion about being able to switch between OpenGL implementations. That could be as simple as an environment variable or two (the second being the OpenGL version supported). Then the library opener routine could just check for the environment variables.

Personally I think it would be better to let the programs just link with -lgl (or some more fit name) that then open a virtual library, f.ex. name api/gl.library. The programs must link with -lGL - that's just how it should work.

The api/gl.library init function itself would then self look at the configuration and open mesa.library and return that libbase. This way we can change how the mechanism works without needing to recompile programs.

This mechanism looks acceptable at first glance, but a proof-of-concept is needed. There some areas, that ATM, I see as possible problems:

using pointers to functions - OpenGL Extensions
ELG.library, GLU.library, OpenVG.library - AROS 3D support is not just core OpenGL, but also supporting library - those need to continue working regardless of what GL.library is present
OpenGL ES/ES2 APIs - those are GL API's for "mobile targets". They are also provided by Mesa and I intend to make them available to 3rd party devs at some point. They also will have to be available regardless of what GL.library is present.

Issues

Maybe gallium.hidd is not loading on your system? Next thing to check is available memory - you need to run AROS with at least -m 256 for softpipe to work (it needs somewhere around 128 MB RAM for each GL context created)

Links

References