Raspberry Pi Forums

Posted: **Fri Jul 26, 2019 10:59 am**

OpenGL on a Pi4 needs X11?
Really do not want that for baremetal.

I need to reread all that info.
I thought DRM did not need X11.
Has anyone done OpenGL on a headless Pi4?

The open source driver is using the ARMs to directing poke the VC6 hardware.
No ThreedX RTOS getting in the way?

We could use that VC6 manual right about now

Posted: **Fri Jul 26, 2019 11:20 am**

I understood that it is possible to not use X see https://www.raspberrypi.org/forums/view ... 8&t=243707 using kmscube but the prospect of making all that C code usable from python or Rust isn't very appealing!

Posted: **Fri Jul 26, 2019 11:57 am**

but the prospect of making all that C code usable from python or Rust isn't very appealing!

Yikes, but at least this is better than trying to figure out DRM from source.
Nice find. I did not even know that was buried in mesa.

Perhaps for me start with this and the mesa demos and Circle?

Wonder if Barebox will work on a Pi4?
I need another Pi4, one to code on, one to test on.
Get Barebox working on a Pi3 first? Got some spare now

Free Pascal can convert C headers;)
Hopefully smarter people (pik33 etc) than me can figure that out.

Ah, that link with kmscube makes sense now.
Not enough though

Back to OpenGL on X11 for me, for now.
Or even playing with glTF
https://github.com/BeRo1985/pasgltf/tre ... src/viewer

Oh crap, Google found me again, I hate my slipping memory.
https://ultibo.org/forum/viewtopic.php? ... glTF#p8446
Me talking about 3D Battleships 6 month ago

No idea how back then, had to wait for a new Pi and more OpenGL/WebGL learning.

Posted: **Fri Jul 26, 2019 3:02 pm**

Free Pascal can convert C headers;)
Hopefully smarter people (pik33 etc) than me can figure that out.

These libraries are huge, having its own #include etc... I think the best method possible is to write a simple own library in C, that calls all this complex drm/gbm/mesa stuff, then compile it to .so for linux and .a for Ultibo, then use it in fpc. Converting C headers is a manual task: these conversion tools are not too good

Posted: **Fri Jul 26, 2019 3:13 pm**

Gavinmc42 wrote: ↑
Fri Jul 26, 2019 10:59 am
OpenGL on a Pi4 needs X11?
Really do not want that for baremetal.

But it's what everyone else has been waiting for. We can now run openGL and openGLES code in a window on the desktop

PeterO

Posted: **Sat Jul 27, 2019 12:03 am**

Yep, some of those Ultibo .a files are in here.
https://github.com/ultibohub/Examples/t ... IV/HelloPi

For baremetal stuff the full mesa might not be needed and simple libs would be nice.
But the baremetal i do is based on other libs that just work and all I do is write the application layer.
So libs are perfectly fine for my stuff.
And if some else writes those libs I know they will work better than anything I can write.

It is likely there will be many solutions as more gets figured out.
But while the HelloPi examples have linked .a files the OpenGLES and OpenVG examples don't.
So this has both methods.
https://github.com/ultibohub/Examples/t ... ideoCoreIV

Obviously C and C++ can link .a files but so can Rust and Pascal.

But it's what everyone else has been waiting for. We can now run openGL and openGLES code in a window on the desktop

On the X11 Desktop? Er the Lazarus/FPC stuff just worked for me.

Good for learning OpenGL but not a way to get rid of the Linux OS.
Making a GUI without needing X11 so it can run on lite Linux would be nice.
I typically use PiCore, it is a small, simple, reliable Linux OS if there is no X11.

Posted: **Tue Jan 21, 2020 11:16 pm**

Has anyone gotten point sprites working on the Pi4? I made a demo program showing my problem, it is a copy of GLXgears that loads a simple circle texture, and displays the texture both on a polygon behind the gears, and as a point sprite in front of the gears.

On the Pi3 the point sprite works, on the Pi4 it's corrupted. Any ideas?

Pi3:
https://raw.githubusercontent.com/Swap- ... s/pi3b.jpg

Pi4:
https://raw.githubusercontent.com/Swap- ... ts/pi4.jpg

Here is the sample program I threw together to showcase the problem:
https://github.com/Swap-File/pi4points/ ... ter/points

Posted: **Wed Jan 22, 2020 8:47 am**

Yes points certainly work using non-immediate mode drawing (glDrawElements/glDrawArrays) but I've not tried it using the glBegin etc (mainly because that would stop the code working on the legacy OpenGLES2.0 on old RPis, as I understand it). In your picture it looks like the point is being drawn but z clashing, what happens if you use a 3D vertex and tweak the z value?

Posted: **Wed Jan 22, 2020 2:10 pm**

I've tried it with GL_DEPTH_TEST on and off (generally I leave it off so the points are always visible), and I've tried glVertex3f with various z values that should work with no changes. It always works on my Pi3 but not on my Pi4.

Previously I was using glDrawArrays(GL_POINTS,..... ) and ran into the same problems on my Pi4. Maybe I have an issue with my OpenGL setup code that doesn't get exposed on the Pi3 but does on the Pi4. I'm not an OpenGL expert by any means, I'll poke around some more tonight.

I can get the points to work as expected on the Pi3 and Pi4 if I turn off texturing, but then I get a square block moving around. From my understanding untextured points are supposed to be square, so that's good and works, but It's not really what I want to do.

Posted: **Wed Jan 22, 2020 2:32 pm**

Swap_File wrote: ↑
Wed Jan 22, 2020 2:10 pm
I've tried it with GL_DEPTH_TEST on and off (generally I leave it off so the points are always visible), and I've tried glVertex3f with various z values that should work with no changes. It always works on my Pi3 but not on my Pi4.

Previously I was using glDrawArrays(GL_POINTS,..... ) and ran into the same problems on my Pi4. Maybe I have an issue with my OpenGL setup code that doesn't get exposed on the Pi3 but does on the Pi4. I'm not an OpenGL expert by any means, I'll poke around some more tonight.

I can get the points to work as expected on the Pi3 and Pi4 if I turn off texturing, but then I get a square block moving around. From my understanding untextured points are supposed to be square, so that's good and works, but It's not really what I want to do.

You may have found a bug. Since the development focus will be on ES, rather than Desktop GL, I’d switch to using GLES if you haven’t already - I don’t know what kind of overlap there is in the code bases for the different variants of the APIs - I wouldn’t want to count on fixes for desktop GL. There should be a big driver update soon with support for GLES 3.1 - I’d give that a try, when available, as there may be a fix for you.

If all that fails, it may be time to post a bug report. I haven’t had the pleasure - if you end up going that route please update here as it would be nice to get a preview of the process!

Posted: **Wed Jan 22, 2020 2:54 pm**

I had a quick look last night at your code, the only thing that I could see that was wrong is that in your draw_points() you have on line 267 :-

Code: Select all

glEnable(GL_TEXTURE0);

Which is invalid. Also glActivateTexture(GL_TEXTURE0); should really be before glEnable(GL_TEXTURE_2D); but since you are only using the first texture unit it doesn't matter.

It looks to be that the texture unit isnt being set properly for the point sprite, I commented out the call to draw_gears() which shows it better, it's definitely drawing a texture but it looks like it's incorrectly getting the image data from somewhere other than your texture.

Posted: **Thu Jan 23, 2020 1:21 am**

Thanks for your input, I tried those changes and had the same output. I think I'll start transitioning to GLES, It's probably better long term.

I'll check back in on the Desktop GL textured points situation once the new driver is released. If there are still issues I'll look into filing a bug report.

Posted: **Thu Jan 23, 2020 1:28 am**

I'll check back in on the Desktop GL textured points situation once the new driver is released

Check your mesa version, Pi stuff is getting added all the time, 19.3.2 is now out.
I'm using 19.2.4 so would have to read all the releases between that and 19.3.2 to see if any Pi stuff got fixed or changed.

Edit - 19.3.0 has a some v3d stuff including compute shaders.
Actually it has a lot of changes - the benefits of external help --- Iago Toral Quiroga (13):

Code: Select all

3d: Explicitly expose OpenGL ES Shading Language 3.1

Nice one to know.

If you have less than 19.3.0 then any bugs might be fixed in the latest releases.
Wonder how long before someone has a OS with 19.3+?

Posted: **Sun Feb 09, 2020 5:18 pm**

In case anyone else runs into problems with points, I'd like to mention that the problems I had with points under desktop GL in immediate mode continue with the recently released Mesa 19.3.2 that included OpenGL ES 3.1 support.

I moved my program from using X11 + GLX + OpenGL 2.x to KMS & DRM + EGL + GLES3.1 (using shaders now), so the problem no longer affects me.

The KMScube demo was very useful, along with the "OpenGL ES 3.0 Programming Guide" & wikibooks sample code:

https://gitlab.freedesktop.org/mesa/kmscube/

https://github.com/danginsburg/opengles3-book/

https://en.wikibooks.org/wiki/OpenGL_Programming

I also used ShaderToy for experimentation:

www.shadertoy.com

Raspberry Pi Forums

RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?

Re: RPi4 Problem drawing GL_POINTS anyone?