3D Support for OS/2 - OpenGL - MesaGL - Etc

[David McKenna]

 There is a project: https://github.com/rswinkle/PortableGL that might be the easiest route to some kind of 3D library because it is designed to be portable and is being continuously worked on...

Regards,

[Dave Yeo]

It looks interesting and should just work for SDL2. Reading the readme, there is also https://github.com/keith2018/SoftGLRender which is C++ and uses simd so should be faster (and perhaps buggier on our platform), looks like more work to port though.

[Dave Yeo]

Well with some makefile editing and changing <SDL.h> to <SDL2/SLD.h> much of the examples compile. Seems Bitwise didn't compile in gomp into GCC so going to have to use one of Paul's GCC builds for some of the examples. Here's one that didn't need gomp. Needs SDL2, exit with ALT-F4 as it catches the mouse

[Roderick Klein]

We do have an old MesaGL which, even using software rendering, works fairly well. Unluckily as Roderick says, manpower.
SDL is another library that would benefit.

Software OpenGL in some form could be done. But for OpenGL to work on hardware requires per chipset a pretty decent amount of work. Based on the fact that we have not gotten new chipsets added to SNAP for 2D acceleration should be good enough of an indicator how scarce our community resources are (manpower). But more about that in my Warpstock presentation in Phoenix Arizona.

Roderick

[mike]

We do have an old MesaGL which, even using software rendering, works fairly well. Unluckily as Roderick says, manpower.
SDL is another library that would benefit.

Doesn't SNAP had OpenGL software rendering included? The OpenGL feature level might not be the same to have at least the OpenGL ES compatibility. On the other hand Vulkan is the replacement for OpenGL today.

[Roderick Klein]

We do have an old MesaGL which, even using software rendering, works fairly well. Unluckily as Roderick says, manpower.
SDL is another library that would benefit.

Doesn't SNAP had OpenGL software rendering included? The OpenGL feature level might not be the same to have at least the OpenGL ES compatibility. On the other hand Vulkan is the replacement for OpenGL today.

It has software OpenGL but its very old. I do not know what it would take to update to a new version of sofrware openGL in SNAP. Let alone what the performance impact of more recent version of OpenGL without 3D hardware acceleration.

Roderick

[David McKenna]

 Dave!

  Thanks for giving PortableGL a try... the example you posted works well here - very smooth render. Hope you can get a gomp version working too...can't believe you got something so fast!

Regards,

[Martin Iturbide]

Hello.

I split this topic, since I believe it is interesting enough to be discussed on its own thread.

Dave, I tried your sample, in my case it did not broke the mouse at first, I was able to move the camera but it was not smooth. After some while it broke the mouse pointer, I was not able to find it, so Alt+F4 was needed.

There is the need of running 3D with hardware support, and as Roderick says, some driver would need to be created so the 3D is generated directly by the graphics card. The question should be, in order to construct the driver, what resources are available online? are there standards on the 3D support for graphics cards? or does every video card has it's own standard and it will be required a driver for every brand?

For what I hear Vulkan is today the preferred open 3D API that a lot of video card (GPU) brands support.
- AMD: There is an open source Vulkan driver for AMD (Radeon) here: https://github.com/GPUOpen-Drivers/AMDVLK https://github.com/GPUOpen-Drivers/pal
- Intel: Open sourced his Vulkan driver too on 2016. - https://github.com/intel/gvk

Regards

[Jan-Erik Lärka]

MesaGL for OS/2 look nice in BilliardGL for example, try it out if you haven't.

There is even comparison applications provided as what it can do better than OpenGL v.1.0 and OpenGL v1.1 Gold.

Even the "old" MesaGL we have should cover most of what one would need as most later additions should take care of nifty things (yet not always important) and possibly performance improvements.

Regards

[Dave Yeo]

Dave!

  Thanks for giving PortableGL a try... the example you posted works well here - very smooth render. Hope you can get a gomp version working too...can't believe you got something so fast!

Regards,

Well it seems gomp is not completely implemented in any of our recent GCC builds, old 4.4.6 does have gomp.dll but is to old to compile the code. Have to get Paul involved.
I ran into another weird problem. The first examples I built, including what I posted, were debug builds and most gave me 10-15 frames a second. I tried the optimized build, which basically added -O3 to the CFLAGS, and it slowed down to 0.1 to 0.15 frames a second, the sphereworld never finished drawing before I gave up. Trying other optimizations such as -O2 or -Os had the same results, -Og (optimize and keep debugging working) did result in perhaps a 50% speedup.
The work in progress is at https://github.com/dryeo/PortableGL-OS2
Even at the best, it is C and C++ code which is going to be limited compared to using simd instructions and perhaps assembly code. Linux actually uses LLVM to create a JIT (just in time) compiler for software 3D for old video cards using the VBE driver. It is still slow for a 3D desktop.
Still adding software OpenGL/Vulkan support to SNAP or Panorama would likely be much more doable then writing drivers for different cards

[David McKenna]

 Dave,

 That's too bad about gomp. I get 21-25 fps on the example you posted. Weird about the optimizations...

Regards,