Oberon Community Platform Forum
December 07, 2019, 07:37:19 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: opengloberon  (Read 10416 times)
soren renner
Global Moderator
Full Member
*****
Posts: 216



« on: May 28, 2011, 04:04:38 PM »

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
Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #1 on: June 22, 2011, 10:36:09 PM »

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?


* Win32.MyWMGLWindow7b.Mod (9.02 KB - downloaded 315 times.)
« Last Edit: June 22, 2011, 10:38:58 PM by sage » Logged
fnecati
Jr. Member
**
Posts: 60


« Reply #2 on: June 23, 2011, 01:17:44 PM »

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)


Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #3 on: June 23, 2011, 01:49:25 PM »

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

* Win32.MyWMGLWindow7bb.Mod (9.35 KB - downloaded 313 times.)
« Last Edit: June 23, 2011, 07:21:06 PM by sage » Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #4 on: June 28, 2011, 06:22:38 PM »

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  Wink
2. Window's Init() called with alpha equal to FALSE;
3. Text output (FPS) done in Draw() method.
Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #5 on: July 03, 2011, 08:38:27 AM »

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?
Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #6 on: July 03, 2011, 03:27:00 PM »

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

Logged
sage
Full Member
***
Posts: 170



WWW
« Reply #7 on: July 05, 2011, 03:25:32 PM »

I'm not sure how correct it that decision, but it seems it works  Wink
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.
Logged
fnecati
Jr. Member
**
Posts: 60


« Reply #8 on: November 22, 2012, 09:36:40 AM »


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 ..
Logged
soren renner
Global Moderator
Full Member
*****
Posts: 216



« Reply #9 on: November 22, 2012, 06:58:50 PM »

The changes look very good. The WMGL window sometimes traps on resize if the contents are animated.
Logged
fnecati
Jr. Member
**
Posts: 60


« Reply #10 on: November 23, 2012, 04:56:44 PM »

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.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!