RPi4 Problem drawing GL_POINTS anyone?

[paddyg]

Has anyone either drawn points without any issues or run into problems with the same code that works OK on previous versions? If I put a buster SD card (which works fine in RPi3) into a RPi4 I'm missing the points. (If I switch to the legacy shader the rust code shows points but runs very slowly, the python code just does nothing)

[Gavinmc42]

Paddy, I'm still having problems compiling the mesa demos.
Was hoping to use them as a starting point for OpenGL coding.
Had no issues with Gentoo64 on the 3B+, but this Buster/Pi4 is a little different.

No luck yet with the Laz/FPC OpenGL examples either.
Been impressed with the WebGL performance in Chromium in the latest update.
So OpenGL should be usable if we can get it working.

[pik33]

No luck yet with the Laz/FPC OpenGL examples either.

I did a simplest working example in C, so the next step is to move it to Lazarus, but this needs translating these .h files included in it or at least fragments of these which are important to this example.

[Gavinmc42]

I had forgotten your test, really am getting old fast.
So much to learn on these new Pi4's.

Any clues here?
https://www.raspberrypi.org/forums/view ... dy#p331264

[paddyg]

gavin, pik, thanks. My code seems to work fine as far as I can see (After switching libbcm to libX11. All tests run, appearance is good and speed is a bit faster) but no points or lines. As I said, the same code works on previous RPis as well as linux and windows x86.

I suppose I'm specifically looking for some code (which either worked without alteration or with details of what needed to be fixed) on the RPi4 with a line in it like

Code: Select all

glDrawElements(GL_POINTS,... # or
glDrawElements(GL_LINES,.. # or
glDrawArrays(GL_POINTS, etc.

[Gavinmc42]

A grep does not find that combo in the mesa examples.

A google finds the docs with minimal examples, but you probably know that already.
http://docs.gl/gl2/glDrawElements

[paddyg]

Thanks. The GL_POINTS drawing works pretty well apart from on the RPi4, though I did have to add a couple of tweaks to get the rust code to draw points (that were bigger than 1px). Basically had to glEnable(GL_PROGRAM_POINT_SIZE) and glEnable(GL_POINT_SPRITE) also I had to specify #version 120 in the shader code. So I'm wondering if it's something along those lines. At the moment I specify eglCreateContex with EGL_CONTEXT_CLIENT_VERSION, 2 as I want everything to work without hacks on previous versions and with the bcm driver.

@Brian_Beuken posted a screen shot of line rendering on RPi4 here (using OpenGLES2.0) So it looks like it can be done, but unsure of the details behind the screen shot!

[paddyg]

Update: here's some minimal code to show the problem https://github.com/paddywwoof/test_rpi4 and here's a video of it running on different machines https://youtu.be/eyDMb4VVIgk It's probably something obvious but I can't spot it!

[Gavinmc42]

Picture is worth a thousand words.
Your video clearly shows the issue.

Wonder if that screenshot of Brian's was a 3B+ one and not a Pi4?
I'm not sure if OpenGLES2 is working on Pi4, if it is, only Brian or yourself knows how?

I will give it a go with OpenGL in Laz/Free Pascal this weekend.
Still have not got the mesa demos working
Will try again now I have done a dist-upgrade.

[Gavinmc42]

Paddy, did you set the point size?
If I don't set it I don't see anything.

Free Pascal but it's very similar.

Code: Select all

glPointSize(3.0);
  glBegin(GL_POINTS); 
  glVertex3f(10.0,15.0,0.0);
  glEnd();

GL_POINTS, GL_LINES and GL_TRIANGLES tested and working on a Pi4.

[paddyg]

Gavin, thanks for testing this, it narrows the problem down to something to do with the way I'm rendering!

glPointSize isn't available in OpenGLES so I glEnable(GL_PROGRAM_POINT_SIZE) to avoid having conditional bits of code depending on the machine it's running on. However If I load the OpenGL driver and call glPointSize() [pushed revised code to github as above] I still don't see points or lines.

Did you get the points and lines to render using fixed or programmable pipeline? Is your code available in a repo somewhere I can have a look at?

Paddy

PS also tried option to render with glDrawArrays() but doesn't make any difference

[Gavinmc42]

My code is just a hack of the Lazarus example.
My OpenGL coding experience with Laz/fpc is about one day old
I might try this in Gentoo64 on a 3B+ as that is an OpenGL based desktop too.

Anyway I don't think your issue is a driver problem, just an OpenGL/ES code issue.
And there is such wonderful error debugging on this Khronos stuff, not
Piglit is on my list to figure out.

Big points are square.
One thing I did learn is porting simple OpenGL C code to fpc is very easy.

Code: Select all

Program opengl;

uses
  SysUtils,
  ctypes,
  gl,
  Glut;

procedure paint; cdecl;
begin
  glClearColor(0.3,0.3,0.3,0.0);
  glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

  glShadeModel(GL_SMOOTH);

  glLoadIdentity();
  glTranslatef(-15.0, -15.0, 0.0);

  glBegin(GL_TRIANGLES);
  glColor3f(1.0, 0.0, 0.0);
  glVertex2f(0.0, 0.0);
  glColor3f(0.0, 1.0, 0.0);
  glVertex2f(30.0, 0.0);
  glColor3f(0.0, 0.0, 1.0);
  glVertex2f(0.0, 30.0);
  glEnd();

  glBegin(GL_LINES);
  glVertex3f(0.0, 0.0, 0.0);
  glVertex3f(10.0, 10.0, 10.0);
  glEnd();

  glPointSize(13.0);
  glBegin(GL_POINTS);
  glVertex3f(10.0,15.0,0.0);
  glEnd();


  glFlush();
end;

procedure reshape(width, height: cint); cdecl;
begin
  glViewport(0, 0, width, height);
  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();
  glOrtho(-30.0, 30.0, -30.0, 30.0, -30.0, 30.0);
  glMatrixMode(GL_MODELVIEW);
end;

begin
  glutInit(@argc, @argv);
  glutInitWindowSize(500, 500);
  glutCreateWindow('Demo');

  glutDisplayFunc(@paint);
  glutReshapeFunc(@reshape);

  glutMainLoop();
end.

              

[paddyg]

Gavin, thanks for that. I've also narrowed the problem down to something I've caused. I've tested using the PyOpenGL module and see that points and lines render fine (see my github). I now have to work my way through and see where the fault is - probably a type that's wrong, or defaults to something unexpected inside python. It is odd that it works OK (obviously just by chance) on other setups apart from the RPi4 and that the Rust translation of the pi3d code behaves the same way (probably means the error is inside an unsafe { } so that narrows it down a bit...).

[Gavinmc42]

I've also narrowed the problem down to something I've caused.

I know that feeling, thought I had broken Lazarus, uninstall, reinstall - same problem.
Somehow I had included x86 code
I know the buttons for save, compile and run, will try to avoid the other fancy stuff.

Anyway, trying to make an OpenGL version of Battleships.
Goal is two player two screen two keyboard/mouse version for the Pi4

Now have a blue square with 10 x 10 matrix of white lines.
Next add another 10 x 10 next to it.
Start with simple 2D with game play pinched from PP4S .

Increase the visual complexity as I learn things like skybox, water texture, lighting etc.
Add explosions, sound effects, fog, smoke, particles...
Should take me two years or so of learning.

[paddyg]

Hi, found the problem. It was the line

Code: Select all

glCullFace(GL_FRONT)

which I set as standard at the start of pi3d but which seems to stop rendering points and lines only on Raspberry Pi 4 - not sure if it's a feature!
Phew.. now I need to update pi3d and push out the next version.

Paddy

[Arkiruthis]

I have noticed some quirks porting my Pi3 code to Pi4 that other GLES implementations (including Broadcom's Pi2/Pi3 driver) seem to tolerate. I had 2 texture units in a vertex shader (one for heightfield lookup, the other unused) and bound 2 active textures (to GL_TEXTURE0 and GL_TEXTURE1) .cpp file. It seems to have optimised out the unneeded texture (as Google ANGLE in Win/Mac and GLES on iPhone did), but it bound the TEXTURE1 to the 0 texture unit, causing some initial confusion when I ran my code on the Pi 4.

The unused texture unit was entirely my fault for not removing it manually, but I think I need to be more careful writing GLES shaders on this implementation than with ANGLE and other implementations.

[Paeryn]

Hi, found the problem. It was the line

Code: Select all

glCullFace(GL_FRONT)

which I set as standard at the start of pi3d but which seems to stop rendering points and lines only on Raspberry Pi 4 - not sure if it's a feature!
Phew.. now I need to update pi3d and push out the next version.

Paddy

OpenGL considers points and lines to be always front facing, though points and lines shouldn't be affected by face culling, they are supposed to be rendered regardless. It sounds like the fragment shader is set to kill fragments that have gl_FrontFacing == true, but if the same code works on an RPi3...

Just out of curiosity, why do you set culling to front by default? If it's because you want to have clockwise triangles shown and not anti-clockwise then setting the front face winding order to clockwise would be more appropriate (by default it is GL_CCW)

Code: Select all

glFrontFace(GL_CW)

[paddyg]

Yes that's exactly the reason (CW triangles as opposed to CCW). At some point in the past (I like to think before I was involved) the meshes in pi3d got defined as clockwise => forward but with matching normal vectors so was self consistent. At a later stage, the (probably my) hack to improve rendering performance by culling faces was to cull the front faces. As you say the correct approach would have been to define front as CW, and this is the change I've actually made, and it works fine on RPi4. It's not really a bug as it's strange to cull front faces - but I think I've read in the khronos stuff somewhere that lines and points should render whether culling is front or back or both.

[Gavinmc42]

I don't like C dependencies.
Turns out a missing freeglut install fixed the mesa demos.
Can now compare working C examples against Pascal OpenGL code.

And once Paddy has his new Pi3D going, Rust versions.

I wonder if we can get a a new OpenGL subsection now.
Not sure if this should be buried in the OpeGLES section?

The Terrain demo runs at 60fps full screen, love these Pi4's.

[PeterO]

I hope the rust openGLES documentation is better than the GTK+ documentation which merrily proclaimed everything was implemented when in fact largechunks were not. "We just translated the C documentation" was their excuse.
PeterO

[paddyg]

Gavin, I pushed the revised Rust version to github last night. Seems to whiz along on the RPi4. Also added the missing assets from my version of Tim Skillmans ship_demo.

PeterO, I'm not sure about the documentation in the gl crate or how much hasn't been implemented, as I really just took the pi3d cytpes based code and changed gl.glCullFace(GL_FRONT) to gl::CullFace(gl::FRONT) etc and it just worked... or didn't in the same way. However I have found that the Rust run-time and compilation errors are generally more useful so it's often quicker to try an alteration in Rust to see why it doesn't work in python

[Gavinmc42]

Seems to whiz along on the RPi4

Wonder if we can slow the Pi4 down by using two HDMI and doing stereo 3D.
DIY VR helmet with two 4" HDMI screens?

Will be interesting to see what Tim can do with Pi4's
Have you got his spaceship running on a Pi4 yet?

[paddyg]

I think Tim has. It will probably run as is without recompiling as it hangs off SDL2 and loads the GL drivers at start. Certainly my Rust version "just worked" (there is no point or line rendering in that demo!). I will check out the FPS later. It might make more difference to Tim's version as it has all the collision mesh checking CPU side. On Rust and python it's a bit faster than on the RPi3+ but not dramatically - maybe 15%. I need to do some more accurate bench marks. I also need to benchmark GL verses GLES. Subjectively there didn't seem any difference but maybe that's because I have restricted pi3d to ES compatible functions

[Gavinmc42]

I also need to benchmark GL verses GLES. Subjectively there didn't seem any difference but maybe that's because I have restricted pi3d to ES compatible functions

I'm pretty sure the VC6 hardware is OpenGLES not OpenGL which is emulated.
But the OpenGLES is 3.0 at least, not sure if that makes a difference, Pi3B+ ES2.0 and Pi4 ES3.0.

OpenGL had Quads, OpenGLES only Triangles?
What else is different?

Optimise for OpenGLES 3.0 for fastest speed?

[paddyg]

fps_pivot.jpg (60.35 KiB) Viewed 4265 times

Here are some comparisons. The RPi4 is always faster (apart from PictureFrame_new from the desktop - TODO check why!?) and generally on the older RPis it's a bit, or much, faster to use the old bcm driver and not run X11 if that's possible.

However I've not tried setting up a system to make a display surface without using X11 and I've not done the GL v GLES tests yet.