opengloberon

[soren renner]

GPU OpenGL in an X11 window from LinuxAos. Works from the command line as well as from LinuxAos window. Cannot explain further -- must code!


http://code.google.com/p/opengloberon/source/checkout

[sage]

I've finally investigated a main reason of poor performance in OpenGl
The reason is in WMWindowManager.Window.Invalidate method
In following example Win32.MyWMGLWindow7b.Mod, with following code FPS is about 300 frames per second (rendering of one frame takes about 3 ms), probably it's real OpenGl performance:

Code:

PROCEDURE UpdateImage;
VAR
t: HUGEINT;
str: ARRAY 30 OF CHAR;
textWidth, textHeight: LONGINT;
BEGIN {EXCLUSIVE}
t := GetTicks();
context.MakeCurrent();
Display;
context.RenderInto(img);
context.DeActivate();
Strings.FloatToStr(fpsCounter.GetAverageFPS(), 0, 1, 0, str);
Strings.Concat("FPS:", str, str);
font.GetStringSize(str, textWidth, textHeight);
canvas.DrawString(4, textHeight, str);
fpsCounter.AddTimeMeasure(GetTime(GetTicks() - t));
Invalidate(WMRectangles.MakeRect(0, 0, GetWidth(), GetHeight()));
END UpdateImage;

If to get time measurement after calling Invalidate, by placing fpsCounter.AddTimeMeasure(GetTime(GetTicks() - t)); after Invalidate(WMRectangles.MakeRect(0, 0, GetWidth(), GetHeight())); the FPS is about 21 frames per second (about 48 ms for rendering a frame and invalidating a form both), it's evidently OpenGl + Invalidate performance. It means that invalidating a 512x512 form under WinAos takes 45 ms. Why it so slow?

[fnecati]

I tested these two opengloberon demos with latest WinAos (FoxCompiler)  and old WinAos (SVN-3022, PACO compiler). Here are the results:

*********************************************
Latest WinAos (SVN:4200) with FoxCompiler:

Win32.MyWMGLWindow7b: FPS = 430-490 without Invalidate, FPS = 75-77 including Invalidate.
MyWMGLWindow7: FPS = 45.


WinAos with PACO compiler, SVN version 3022 :   

Win32.MyWMGLWindow7b:  FPS = 430-490 without Invalidate,  FPS = 420 -480 including Invalidate.
MyWMGLWindow7: FPS = 206 - 208

*********************************************

I do not know what happened in latest SVN versions, but, SetFCR/DelFCR are not required in this latest WinAos version when using OpenGL, demo modules seem to work without them!. But in LinuxAos they are required, what could be the problem there?.

There are problems also while using FFTW module (double precision, FFTWTest.Mod)  with the latest WinAos FoxCompiler. If I use MathOberon Array types in FFTW I get some NaN numbers. However, if this module changed for normal Oberon arrays usage I get correct values. Singe precision FFTWf module seems ok. Everything is ok with old WinAos (PACO)

[sage]

Another representation of results (in s) and another testing machine (more powerful but with Win7). Last WinAos from repository.
Rendering takes 0.007701 s that corresponds to 129.85 FPS
Rendering + invalidation takes 0.018707 s that corresponds to 53.45 FPS
Anyway, invalidation takes up to 60 % of time.

On machine with WinXP (Pentium 4 3,4 GHz, GeForce 7800 GT) results are following:
Rendering takes 0.004094 s that corresponds to 244.26 FPS
Rendering + invalidation takes 0.057218 s that corresponds to 17.47 FPS
Invalidation takes 93 % of time

[sage]

Finally, problems with performance has gone. On (Pentium 4 3,4 GHz, GeForce 7800 GT, WinXP, latest WinAos) Win32.MyWMGLWindow7b.Mod shows up to 280 FPS.
Main changes are:
1. I've replaced Invalidate() method call to that code:

Code:

rect := WMRectangles.MakeRect(0, 0, GetWidth(), GetHeight());
WMRectangles.MoveRel(rect, bounds.l, bounds.t);
WMRectangles.ClipRect(rect, bounds);
manager.AddDirty(rect);

I'm not sure how correct it that decision, but it seems it works 
2. Window's Init() called with alpha equal to FALSE;
3. Text output (FPS) done in Draw() method.

[sage]

Hi guys,
Thanks to fnecati we has now OpenGL bindings for Win/UnixAos. That's fine.
But for building of any serious OpenGL project some stuff like model loaders and so, needed.
Do we has something like this http://www.xmission.com/~nate/smooth.html written on Oberon language?

[soren renner]

Sage: fnecati and I were hoping that you could do for aos on windows what he did for aos on linux (X11): code a module that creates a native OS window for opengl.



 http://code.google.com/p/opengloberon/source/browse/MyXGear2.Mod

[sage]

I'm not sure how correct it that decision, but it seems it works 

It seems that desision to use manager.AddDirty(rect) is wrong (on not very powerful system with Celeron 1 GHz) it may lead to system freezing. Invalidate(rect) (Invalidate internally calls manager.AddVisibleDirty(SELF, rect)) preferably to be used instead.

[fnecati]

opengloberon for WinAos and LinuxAos are revised and available at

   http://code.google.com/p/opengloberon/source/checkout

Main changes are mainly for easy code writing and visual esthetics:

- updated to opengl 4.3

- Basic opengl type names are changed; GL.GLfloat --> GL.Float, GL.GLuint -> GL.Uint, etc.

- gl prefix is removed from function names; GL.glViewport --> GL.Viewport.

- GLU part is seperated from OpenGL module, GLU.Mod is added,
      GL.gluPerspective --> GLU.Perspective

- For problematic opengl projection and transformation functions that produce NaN
  values, wrapper procedures are added which uses SetFCR inside.
  So, in the client modules, use of GL.SetFCR() and GL.DelFCR() functions are not required.

- For some commonly used opengl functions that require vector parameters, wrapper procedures
  are added that use mathoberon arrays as parameter. For example;

   GL.glVertex3fv(SYSTEM.ADR(x[0])) --> GL.Vertex3fv(x),
 
  where x: ARRAY [3] OF REAL;

- For some opengl functions that use string parameter as input, warapper procedures are added
  for DarwinAos compatibility.

- Dynamic library names for Unix.GLU and Unix.XF86VMode are changed from
  libXX.so --> libXX.so.1 in these modules, since they are in the search path of LinuxAos.
  For Unix.OpenGL, it is not changed; you need to make a symbolic link to libGL.so
  in the search path path of linuxaos if it is not available.

- In WMGLWindow object, context variable is made hidden and MakeCurrent, DeActivate
  methods are added. context.RenderInto(backImg) is replaced with SwapGLBuffer() method

- Finally, the demo modules are adapted to these changes.

 Waiting for your contributions, comments and ideas ..

[soren renner]

The changes look very good. The WMGL window sometimes traps on resize if the contents are animated.

[fnecati]

There are some synchronisation problems with A2-WM that I did not look at as detailed.
But it can solved, A2-WM designers or someone who knows A-WM well may solve easily,
... help needed ...

I am also thinking, instead of using slow WMGLWindow in A2-WM, may be an opengl enabled Display
may be much faster. Could this feasible? An opengl context field will be added to Win32.Display / Unix.XDisplay object,
and no glReadpixel, may be no flipping of image is required. So, hardware accelerated rendering will be in A2-WM Display
space and name it as GLDisplay object.