GLM library alternative?

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Ryan Joseph

> On May 29, 2017, at 12:58 PM, Anthony Walter <[hidden email]> wrote:
>
> I'm curious, what's the problem with fpc and loops? Also, from my OpenGL experience the limiting factor in speed (frames per second) is usually the pixel complexity and not whatever method is used to feed vertex data or shader uniforms.
>

It’s buried now but look at the “FPC Graphics options” thread from a few days ago and spanning back weeks I think. After all that I still failed to get a clear answer I could understand well but some poor loop optimization and floating point division was causing a ray caster example written in Java to get low single digit frame rates where the same code ran 40+fps in Java and C. There seems to be some changes in FPC 3.1.1 but I’m not sure what changed. Some one else may correct what I said but feel free to take a loop. Bottom line for me is I’m nervous about loops in highly optimized low level code now but that may be unfounded.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Mattias Gaertner
On Mon, 29 May 2017 15:29:24 +0700
Ryan Joseph <[hidden email]> wrote:

> > On May 29, 2017, at 12:58 PM, Anthony Walter <[hidden email]> wrote:
>[...]
> It’s buried now but look at the “FPC Graphics options” thread from a few days ago and spanning back weeks I think. After all that I still failed to get a clear answer I could understand well but some poor loop optimization and floating point division was causing a ray caster example written in Java to get low single digit frame rates where the same code ran 40+fps in Java and C. There seems to be some changes in FPC 3.1.1 but I’m not sure what changed. Some one else may correct what I said but feel free to take a loop. Bottom line for me is I’m nervous about loops in highly optimized low level code now but that may be unfounded.

I will try to summarize the thread:

Jonas told that the benchmark program contains a number of bugs/wrong
translation from the C code:
1) casting a floating point number to an int in C does not round
2) The usage of floor in the test program is wrong.
3) The Pascal version uses longword instead of int32...getting evaluated as 64 bit on 32 bit
4) frac() is only used to get a monotonous increasing value...

C compilers know what "floor" is doing and optimizes it.

FPC default config does not use optimal settings for todays machines.
Java does, C libs do. I didn't find what Graeme used for his C version.

Some pointed out that the Math unit misses some SSE and double
versions of functions.

Florian improved FPC 3.1.1 boosting the speed from 8 to 23FPS.

Martin used MSELang with LLVM backend, fixed some bugs in the code and
used some optimization flags to get 41 FPS, which looks similar to
Graeme's numbers for the C and Java version.

There were various suggestions for optimizations, which C compilers are
doing and could be added to FPC, but they would be specific to these
benchmarks. Including some loop optimizations.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Reimar Grabowski
In reply to this post by Ryan Joseph
On Sat, 27 May 2017 16:52:21 +0700
Ryan Joseph <[hidden email]> wrote:

> Not having glm::perspective or glm::lookAt is enough to really stop you in your tracks and running off to Google for hours.

Then perhaps you have to improve your google skills. ^^

https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluPerspective.xml
https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml

Has all the info you need to implement them.

Unoptimized pascal versions (but fast enough for general use):

function TCamera.LookAt(Eye, Center, Up: TVector3): TMatrix4x4;
var
  View, Right: TVector3;
  TransMatrix: TMatrix4x4;
begin
  View:=Normalized(fCoV-Position);
  Right:=Normalized(CrossProduct(View, Up));
  Up:=CrossProduct(Right, View);

  Result[0][0]:=Right.X;
  Result[1][0]:=Right.Y;
  Result[2][0]:=Right.Z;
  Result[3][0]:=0;

  Result[0][1]:=Up.X;
  Result[1][1]:=Up.Y;
  Result[2][1]:=Up.Z;
  Result[3][1]:=0;

  Result[0][2]:=-View.X;
  Result[1][2]:=-View.Y;
  Result[2][2]:=-View.Z;
  Result[3][2]:=0;

  Result[0][3]:=0;
  Result[1][3]:=0;
  Result[2][3]:=0;
  Result[3][3]:=1;

  Result:=MultglMatrix(IdentityMatrix4x4, Result);
  TransMatrix:=IdentityMatrix4x4;
  TransMatrix[3][0]:=-Eye.X;
  TransMatrix[3][1]:=-Eye.Y;
  TransMatrix[3][2]:=-Eye.Z;
  Result:=MultglMatrix(Result, TransMatrix);
end;


function TScene.BuildPerspectiveMatrix(FoV, AspectRatio, NearPlane,
  FarPlane: GLfloat): TMatrix4x4;
var
  XYMax, XMin, YMin, Width, Height, Depth: GLfloat;

begin
  XYMax:=NearPlane*tan(FoV*pi/360);
  YMin:=-XYMax;
  XMin:=-XYMax;
  Width:=XYMax-XMin;
  Height:=XYMax-YMin;
  Depth:=FarPlane-NearPlane;

  Result[0][0]:=(2*NearPlane/Width)/AspectRatio;
  Result[0][1]:=0;
  Result[0][2]:=0;
  Result[0][3]:=0;

  Result[1][0]:=0;
  Result[1][1]:=2*NearPlane/Height;
  Result[1][2]:=0;
  Result[1][3]:=0;

  Result[2][0]:=0;
  Result[2][1]:=0;
  Result[2][2]:=-(NearPlane+FarPlane)/Depth;
  Result[2][3]:=-1;

  Result[3][0]:=0;
  Result[3][1]:=0;
  Result[3][2]:=-2*(FarPlane*NearPlane)/Depth;
  Result[3][3]:=0;
end;

R.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Anthony Walter-3
Thanks for posting those LookAt and Perspective routines. They're kind of needed with OpenGL ES 2.0, as it no longer has matrix modes. You need to build your own perspective and model view matrices and pass them to your vertex shaders as uniforms.

uniform mat4 modelview; // modelview matrix uniform
uniform mat4 projection; // projection matrix uniform

attribute vec3 xyz; // vertex position attribute 
attribute vec2 uv; // uv texture coordinate attribute
 
varying vec2 texcoord; // varying texture coordinate
 
void main()
{
    vec4 vertex = modelview * vec4(xyz, 1.0); // transform vertex with modelview matrix uniform
    gl_Position = projection * vertex; // project the transformed vertex and write it to gl_Position
    texcoord = uv; // assign the uv texture coordinate to the varying
}

By the way, what's stopping you guys from using OpenGL ES 2.0? It works on most all Windows, Mac, and Linux systems, and it's the only 3D graphics API on Raspberry Pi and most smart phones/tablets.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Marco van de Voort
In reply to this post by Ryan Joseph
In our previous episode, Ryan Joseph said:

> > On May 28, 2017, at 10:33 PM, Ryan Joseph <[hidden email]> wrote:
> >
> > projTransform := TMatrix4x4.CreatePerspective(60.0, 500 / 500, 0.1, 10.0);
> > modelTransform := TMatrix4x4.CreateTranslation(0, 0, -3.0) * TMat4.CreateRotateX(54);
>
> I found out the problem. I was expecting the multiply to work like with GLM where you could do:
>
> translation * rotation
>
> but with the operator overloads I need to do protation * translation.
> Anthony?s multiply matrix 4 operators did this in the order I expected and
> how I figured it out.  Not sure why and it?s probably not safe to swap the
> parameters because it would likely break other parts of the unit.

For the 2Ders, in old GL I used glortho2d a lot. In newer ones I missed that, but I found
an equivalent on stackoverflow:

// http://stackoverflow.com/questions/21323743/modern-equivalent-of-gluortho2d
procedure MyOrtho2D(var mat : TGLMatrixf4;left,right,bottom,top:single);
var inv_y,inv_x : single;
begin
      inv_y := 1.0 / (top - bottom);
      inv_x := 1.0 / (right - left);

    // this is basically from
    // http://en.wikipedia.org/wiki/Orthographic_projection_(geometry)

    //first column
    mat[0][0] := (2.0*inv_x);
    mat[0][1] := (0.0);
    mat[0][2] := (0.0);
    mat[0][3] := (0.0);

    //second
    mat[1][0] := (0.0);
    mat[1][1] := (2.0*inv_y);
    mat[1][2] := (0.0);
    mat[1][3] := (0.0);

    //third
    mat[2][0] :=  (0.0);
    mat[2][1] :=  (0.0);
    mat[2][2] :=  (-2.0*inv_z);
    mat[2][3] :=  (0.0);

    //fourth
    mat[3][0] :=  (-(right + left)*inv_x);
    mat[3][1] :=  (-(top + bottom)*inv_y);
    mat[3][2] :=  (-(zFar + zNear)*inv_z);
    mat[3][3] :=  (1.0);
end;

I have a TGLvector for zoom (X/Y) and one for pan (offset, also in X and Y
direction).

// calcs a matrix for the shader. pass the matrix as an uniform and multiply  in vertex or geometry shader

procedure myorthohelp(var mat : TGLMatrixf4;const
aoffs,azoom:TGLVectorf2;topdown:boolean=false);
begin
  myOrtho2D(mat,aoffs[0], 1.0 / (aZoom[0]) + (aoffs[0]), 1.0 / (aZoom[1]) + (aoffs[1]), aoffs[1])
end;

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Marco van de Voort
In reply to this post by Anthony Walter-3
In our previous episode, Anthony Walter said:
> By the way, what's stopping you guys from using OpenGL ES 2.0? It works on
> most all Windows, Mac, and Linux systems, and it's the only 3D graphics API
> on Raspberry Pi and most smart phones/tablets.

IIRC I went for opengl 3.3-4 because one could find more about it and
because opengl ES afaik has no geometry shader support.

The GL stuff is only for Windows PC (and very maybe Linux PC) anyway.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Anthony Walter-3
In reply to this post by Marco van de Voort
Marco,

Regarding 2D animation, what I've far far more effective than an orthographic projection is to draw 2D billboard sprite at a distance and size to align exactly with your screen's resolution. That is each width and height of "1" gl world equals "1" screen pixel, and coordinate (0, 0) equals the top left corner of your screen.

This type of 2D setup in OpenGL allows for allows you to freely mix in both 2D and 3D effects. Here's are two examples of how 2D in a 3D world can work:

Animation of vector graphics: https://www.youtube.com/watch?v=P1cd-kWBz0E

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Marco van de Voort
In our previous episode, Anthony Walter said:
>
> This type of 2D setup in OpenGL allows for allows you to freely mix in both
> 2D and 3D effects. Here's are two examples of how 2D in a 3D world can work:

If you check the myorthohelp function that called it, you'll already see it
is normalized to [0..1] coordinates.

But there are some special cases (e.g. sometimes zoomx<>zoomy to get square
pixels), vertical inversion etc where not everything is 0..1,0..1

I don't need 3D effects, this is a business app. For an (older) demo based
on the code see

http://forum.lazarus.freepascal.org/index.php/topic,30556.msg194484.html#msg194484


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Reimar Grabowski
In reply to this post by Anthony Walter-3
On Mon, 29 May 2017 14:07:40 -0400
Anthony Walter <[hidden email]> wrote:

> By the way, what's stopping you guys from using OpenGL ES 2.0?
It's ten years old, the current ES version is 3.2.
It has less functionality than "standard GL" as it's meant for embedded systems (hence ES).

R.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Ingemar Ragnemalm
In reply to this post by Ryan Joseph

Den 2017-05-30 kl. 12:00, skrev Marco van de Voort:
> For the 2Ders, in old GL I used glortho2d a lot. In newer ones I missed that, but I found
> an equivalent on stackoverflow:

My FPC vector unit has overloading and many other functions
(determinant, rotation around arbitrary axis...). Some functions like
lookAt, frustum, ortho, matrix inverse etc are only in my C version so
far. Not hard to port.

mat4 ortho(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top,
GLfloat near, GLfloat far)
{
         float a = 2.0f / (right - left);
         float b = 2.0f / (top - bottom);
         float c = -2.0f / (far - near);

         float tx = - (right + left)/(right - left);
         float ty = - (top + bottom)/(top - bottom);
         float tz = - (far + near)/(far - near);

         mat4 o = SetMat4(
             a, 0, 0, tx,
             0, b, 0, ty,
             0, 0, c, tz,
             0, 0, 0, 1);
         return o;
}

So I have a pile of code on the topic, much of it for FPC. But shouldn't
there really be a good OpenGL support package for FPC that was some kind
of "standard"?

BTW, when I ported my OpenGL demos to FPC, I found that the FPC glext.pp
had some fatal bugs. (Easy to fix, but I never figured out who would
want the corrections, so I hope someone else noted that it crashed for
modern OpenGL.)

/Ingemar

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Graeme Geldenhuys-6
On 2017-05-30 14:52, Ingemar Ragnemalm wrote:
> so I hope someone else noted that it crashed for
> modern OpenGL.)

Huh? I've been using it for 4 months with "modern OpenGL 4.x" (non-fixed
rendering pipeline) and it hasn't crashed on me.

Next time it crashes, please supply a small code example if you can, or
at least a backtrace so we can see where the error originated.


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Graeme Geldenhuys-6
In reply to this post by Mattias Gaertner
On 2017-05-29 12:24, Mattias Gaertner wrote:
> Jonas told that the benchmark program contains a number of bugs/wrong
> translation from the C code:

And all of those recommendations were applied by Jon Foster and yielded
only a 0.6% increase in speed.

"I ended up with an hour of extra time so I went over Jonas' suggestions
again. I made tweaks fixing integer types, using trunc() instead of
round, ... The over all  improvement is only +0.6%, as I predicted
nowhere near the 10x+ needed to compete with the other languages."

   -- Jon Foster (in the MSEide+MSEgui mailing list dated 2017-05-24)


So the major speed problem still seems to be the FPC optimisation with
looping and not using SSEx when it is available.

I personally haven't tested with the latest FPC 3.1.1 yet.


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

codz
tested with the fpc trunk , got only 3 fps increased .
but even with this result fpc does great job , compared with gcc7  ,
gcc is faster only about 45% . so when compared with a compiler like
gcc which get tens of patches par day from from around the world
including big companies like sumsung . and you get only 45% deference
in speed , no doubt fpc is great compiler .
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Anthony Walter-3
In reply to this post by Graeme Geldenhuys-6
I've done a bit of assembly programming for IA-32, none recently and zero compiler development other than simple parsers, but from what I know optimizing with newer instructions like SSEx is only part of there story. There's also optimizing for out of order instruction execution (OoOIE), or instruction reordering. Even on a single core, when optimized done properly it can yield 4x or more increase in processing speed, avoiding CPU stalls, which is likely happening a lot given the descriptions people have provided in this thread.

Obviously properly using SSEx instructions and optimizing for OoOIE is a non trivial undertaking. I think probably the best way to test FPC out is to stop writing speed tests against other languages, and to view the CPU instructions generated for a few different loop types, including trunc()/floor() functions. Next rewrite those parts in assembler, include SSE whatever instructions and pepper in OoOIE, and finally test the speed difference.

My instincts tell me if the compiler could then generate both SSEx and OoOIE properly it could automatically applied in many places, resulting in a huge speed up for FPC programs. But for me, the main advantage of Free Pascal is that it generates native language, leading to easier reuse of C style APIs such as Cairo/GTK/SDL, and also allowing for the PME (properties, methods, events) plus all the other nice features Free Pascal offers. Most of the time my programs are either idle waiting for user input, or idle waiting for other APIs or in the case of OpenGL the graphics hardware to complete. As such the execution speed of the pascal portion of my programs isn't as important.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: GLM library alternative?

Marco van de Voort
In reply to this post by Ingemar Ragnemalm
In our previous episode, Ingemar Ragnemalm said:
> BTW, when I ported my OpenGL demos to FPC, I found that the FPC glext.pp
> had some fatal bugs. (Easy to fix, but I never figured out who would
> want the corrections, so I hope someone else noted that it crashed for
> modern OpenGL.)

Well, actually I don't use FPC opengl but dglopengl :-)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12