glcanon: rewrite the G-code preview on OpenGL 3.3 core - #4293
Conversation
Why rewrite?
Performance
Code RefactoringCode is also reviewed and refactored for eaiser maintenance .
Hardware supportThis rewrite targets the OpenGL 3.3 standard, released in 2010 and widely supported. In case of hardware problems, or if drivers don't support the necessary features, the env var Verification
Performance testing resultsBenchmarked against stock master on AXIS end-to-end (4 reps, real GUI,
|
| master | rewrite | ||
|---|---|---|---|
| peak RSS | 1674 MB | 748 MB | 2.24× lower |
| ⤷ minus idle baseline (194 MB both) | 1480 MB | 554 MB | 2.67× lower |
| steady redraw frame | 0.32 s | 0.12 s | 2.7× faster |
open_file_guts (open→drawn) |
7.6 s (6.8–8.5) | 7.1 s (7.1–7.4) | a wash |
⤷ load_preview alone |
3.00 s | 2.96 s | a wash |
Both screenshots confirm the file actually drew — this isn't one branch skipping work.
Phase harness (3 reps, EGL, isolates parse / extents / GPU build)
| phase | master | rewrite |
|---|---|---|
gcode.parse |
1.66 s, +575 MB | 2.76 s, +28 MB |
calc_extents |
0.86 s, +432 MB | 0.00002 s, +0 |
| GPU build | 0.28 s (glNewList), +31 MB |
bake 0.027 s + upload 0.002 s |
| GL payload | not queryable | 24,003,600 B VBO (counted at glBufferData) |
| load total | 2.82 s | 2.80 s |
| peak RSS | 1122 MB | 276 MB |
| first click in preview | +0.75 s, +276 MB (selection lists) | none |
What the numbers say
- Memory is the headline. 2.2× lower peak in the real GUI, and the gap widens on first click: master compiles a second, per-line-named copy of the program into selection display lists (+276 MB); the rewrite's picker reads the buffers already uploaded.
- Load time is unchanged, but for a non-obvious reason. The rewrite's raw parse is ~1.1 s slower — it transforms and fills arrays on the move path. That's fully paid back by
calc_extents/unrotate_previewdropping from 0.86 s to zero, since the rewrite accumulates extents during the fill. If you want load time to actually drop, the parse hot path is where the remaining 1.1 s lives. - Frame time is 2.7× better and the GPU build is 10× cheaper (0.03 s vs 0.28 s).
Two caveats worth stating: llvmpipe puts display lists and VBOs in process RSS, so the RSS deltas are the only cross-branch-comparable "GPU memory" figure — a display list has no queryable size, so master gets no exact byte count. And I noticed that at the same view master's preview saturates to white where the rewrite renders mid-grey; that's a blend difference on densely overlapping geometry which I did not investigate.
|
Good work. Functional touch screen support is rather important to keep working. Breaking a touch interface would probably make quite a few users pulling hairs and may even require baldness treatments when it persists. Some cases that should function: running on RPi4, Rpi5 and running with remote X (also ssh tunneled)? |
I've just verified and touchscreen works exactly as in master branch, so no problems with it. Unfortunately I have no RPi to test on it but I'd not expect any problems, this OpenGL API is not exotic. I'd say previous immediate mode API is less compatible. Regarding remote X11 via SSH, my googling shows it may be a problem, but it is easy to solve by switching to software GL rendering with LIBGL_ALWAYS_SOFTWARE=1. |
|
Tried on my laptop, seems to work great - colors seem a bit darker. Very nice job! |
|
Seems some changes are necessary to make it RPi4B compatible. it seems to be easy. And even more important, it seems we can do much further with this and loading 1M+ points program can be handled well even on weak hardware. I'll work it out and submit here. |
|
Gave this a go with the QtPlasmaC screen. All looks well except two things:
Deleted: Added Deleted: Added Otherwise it seems to work as expected! |
|
Hi!
That is already fixed and I will submit this with updated PR. There was alpha blending set different. Now it pixel-to-pixel matches previous results.
Thank you, I will include this for sure. |
cfb284d to
f78ed6f
Compare
|
I've updated the code, I think that is now works as it should. I've added the following:
Final result: 5M move file is loading much faster. P.S. During development I found surprising results - regardless of all my optimizations, big ngc file load was still slow and memory eager. I found the reason - AXIS code is not well optimised, and while parsing it eats ~500 bytes per every source code line, it is all with dynamic memory allocation. So if want to directly compare the gremlin/glcanon speed, use qtaxis it seems to be better optimized around this. If you, like me, do not have big .ngc files to try it out, I put some to Dropbox: https://www.dropbox.com/scl/fo/sp3njw8t2hlujo65ql4ma/AMGK-jRiwfUF3G1QJ-4aY8U?rlkey=ewxjww93bbobqd0sb5nxbk289&st=3lribdca&dl=0 |
Some Benchmark resultsTested in AXIS with small patch that disables source code parsing [ by AXIS code ].
Load: 1.23x faster at 1M, 1.46x at 5M. Click-to-line: 8.5x faster at 1M, 33x at 5M — and only the rewrite actually selects anything. Master's first click is dominated by building the selection display lists (0.849 s at 1M, 10.35 s at 5M), then it discards the result: its 100-entry |
be39bbe to
00bedfd
Compare
|
This is great work! I have a few comments... The line weight is still not 1:1 from before the rewrite. I am not sure if that's intended, but it seems for feed, rapid, and manually controlled moves (in green, blue, and orange respectively in my preview), the line weight is different. Before rewrite: After rewrite: Also, I know many of these are not your doing, but here are many generic print statements all over these files. I feel like a lot of this should be moved to the logs for debugging, and do not need to be displayed in the terminal. Specifically I noticed the addition of: For at least glcanon.py, I think we should make effort to move some of this to logging. I think the exception would be when a dependency is missing, etc. Those are helpful to have in the terminal (and really should also be in a log file somewhere). Otherwise, let me know when you are happy with this and I am happy to commit it for you! -Greg |
|
Greg, thanks for checking this!
I will additionally check it!
I reworked logging, hope that is better now.
Need to resolve line width and would be good to get at least one test on RPi and I think that is ready to go.
|
|
I absolutely love this, can't wait to see this merged! FlexGUI looks a bit wonky with the GL3 port. Vanilla LinuxCNC: 
GL3: 
|
Happy to help! I thought you had a command you wanted me to run and post the output of, but I do not see it now? |
|
In your rewrite, do you think there is case to increase #define MAX_POINTS (100000) in emcmodule.cc? I've bumped this up 3 years ago (8264698), previous to my increase, it was set at 10000 since 2009. Honestly these days with memory sizes/graphics cards being what they are, I wonder if this is still applicable to limit it at all. Have you any thoughts on the matter? |
|
IMO LinuxCNC should still function on 32-bit processors with 4GB of RAM and plenty of room to spare. Aside from that, I have no opinion on MAX_POINTS. |
It'd be helpful if you send output of "glxinfo -B" , "cat /etc/debian_version" and also the .ngc file you used for testing. So I can repeat it exactly. |
It is much better optimized now, now it incrementally converts vector[9] to xyz only for new values arriving and following work is done inside OpenGL on array with that raw xyz data that builds backplot line strip. however that downside is in existing emcmodule.cc:3128 — Logger_get_points does PyBytes_FromStringAndSize(s->p, npts * 32): a copy of the entire buffer, under the sampler mutex, on every frame, even though glcanon_scene.py:1593 then throws away everything before first_point and typically uses one point. At 100 k that's 3.2 MB/frame (~190 MB/s at 60 fps) plus lock contention with the sampler thread. So we can increase this buffer probably 10x or even 100x but only after implementing something like I did for program moves [ gcodemodule.cc:class MoveBatch ] - CC code and Python code will share pointer to static buffer of floats - native to CC, and easy to access in Python via numpy. it can be made optional [ CC code will be checking calling Python side if it understands new protocol ]. I could implement it too [ or someone else if have time ] but may be in another PR - that one is really too big already. |
The last 32-bit PC processors were made decades ago. Distros have been purging 32-bit processor support for years now. There is no point in supporting it as we can't even compile it on newer distros. The 4GB point should be no problem. It can run on a RPi with 1GB RAM. The real problem will be the graphics memory. That limit is usually the graphics card. However, a system with 4GB graphics shared RAM may be very adequate for reasonably large display lists. If I may make a guess... In 1GB graphics, if each line segment takes 256 bytes, then you can have 4 million lines. I don't think the problem is memory, but probably the bandwidth needed if the processor gets involved. But, this still needs to be tested on both RPi4 and RPi5. They do have limits and we should get an idea where that limit is. |
To be exact: for backplot, VBO [ GPU ] memory usage is as follows:
on the CC code side, it is ~ n points * sizeof(double) * 9 [xyzabcuvw] I think max capacity here will be limited not by memory but by CPU usage because rendering still need to be calculated and that is good if GPU doing it without taking CPU resources but no warranty here. Better to check it on real hardware... |
Yes, I completely agree, I didn't intend for it to be part of this PR, just wanted to bring it up since it's definitely related. I was doing some testing on some large preview files, which reminded me of the backplot "going away", and I wanted to bring it up before it left my brain. Also, I can confirm that the new preview is definitely much faster than the old one! Also, I do intend to dig out a RPi4 and give this a check. It aligns with another project I have cooking as well, so it's double motivation to move it along. Thank you again for taking this on. Edit: I will get you the output of "glxinfo -B" , "cat /etc/debian_version", and will get you the .ngc file I showed above after work today. |
|
What about this breaking FlexGUI's plotter? The screenshots I posted above? |
|
Flexgui will need to fix the code on their end that causes the trouble. |
OK, just wondering. Thanks! |
Exactly. That is because they are calling OpenGL directly with old API. However, to make possible for 3rd party authors to write code that works with both 2.9 and 2.10 it is possible to add new variable somewhere to glcanon like self._GLCANON_VERSION = 2 . Please advise if that is good idea. |
I do have a BM running Debian 13 I could try it on as well.
I would vote no on this. I think we've clung onto the old ways for long enough and if we are moving forward, it's time to move forward. |
|
For the record, this is the same on MX Linux 25 (Based on Debian 13): 
Results of stanzas below: name of display: :0.0 OpenGL version string: 4.6.0 NVIDIA 580.173.02 OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 580.173.02 13.6 |
|
I found reason for that problem - QT OpenGL set different flags for GL Context during creation, so it is one line fix to get backplot back 3px width. However, I have a question I cannot make decision myself. Docs say v3d on RPi really set limit to line width to 1. So to draw 3px wide line you have to calculate and draw a square [ and pass 4 instead of 2 vertex to GPU for each line]. Of course it comes at cost when rendered. My question is - is it really imporant to keep 3px line width for backplot on RPi and pay performance costs for it? I know it is not most powerful machine to run LinuxCNC on, so may be we can simply set more bright colors for backplot instead ? For reference - program lines are 1px wide, and backplot lines are 3px. |
|
I pushed fixes now, only Q for now is live testing on RPi with their native OpenGL driver. With software rendering [libvmpipe] I'd not expect results other than anywhere else. |
|
A remote X-session over ssh into a RPi5 runs axis without a problem (using bookworm). |
I would say no. I pulled out a pi4 and loaded the linuxcnc iso (Trixie) and built master for it. Overall I would say the Pi4 experience is a bit lack-luster (for all screens). So anything done to gain here is probably a good thing. Perhaps the Pi5 is a different experience. I also applied your patch, everything seemed to work for the screens I tested (QtPlasmaC and Axis). I will note that the backplot was 3px wide in both cases. Perhaps to be expected. If we think this is tested enough between what I did this weekend for the Pi4, and what Bertho did for the Pi5, I will commit this as soon as I get your concurrence. |
It still needs to be tested on a RPi5 with a local session and monitor attached. As I mentioned, I do not have a spare monitor available (that is, not one that takes HDMI). I will try to see if I can borrow something, but it may still take a while. |
I apologize, I took the monitor testing as “nice to have”. We can wait. Although I might argue it as a “nice to have” when compared to the value of getting this into the wild for testing on the master branch. I suspect that the number of RPi5’s running Master is probably minimal/non-existent. |
|
The RPi5 works with local monitor (1920x1080). It is quite slow when you load the 1M file and have the preview on. It runs, but cannot keep up with the frame updates. There may be optimizations possible which are not being used that are better for the platform. That could be investigated separately. RT runs normal, but the screen lags/skips lines in the updates, but that is still fine. Without the preview it is all working as expected and does keep up. The touched path indication is of limited size and is fine too (don't know how many; gets pruned in batches). The CPU usage for the axis process is apparently proportional with the number of lines handled and is about 100% (split over two cores) at just over tracing two and a half levels of the Hilbert curve and axis is holding just over 100% for the rest. The system is still interactive without problems and the screen pans/zooms without a hitch. There may be some code or algorithmic tweaks to make this faster so the CPU has less to do. This should be investigated by someone at home in the the RPi CPU/GPU world (could also benefit other architectures). FWIW, Python may not scale well for all architectures. Otherwise, RPi5 is a go. |
Thank you very much for detailed test! A few questions if you allow: 2 - most important is what OpenGL driver used and if GPU is used at all. Can you please check
and output of |
|
No data/info in linuxcnc_debug.txt. Other info: |
|
Does this duplicate / replace #3547 ? |
glxinfo -B shows software rendering enabled (libvmpipe). Probably V3D GPU drivers are not installed or disabled. I just got another report from customer using RPI 5B. From video he sent me I cannot see any performance problems. It looks very responsive. |
I did not see 3547 before, but that is definitely a replacement. |
/me embarrassed. Goes down the room facing down a corner to contemplate the existence of the universe... Interesting, my image doesn't even have /boot/firmware yet. The v3d driver was masked under the And, yes, it works a lot better with the 3D driver actually enabled... Reading the 1M file works without a problem after some time and it is interactively very responsive indeed. Now the load running axis is just 10% and follows cleanly. Much better. |
|
Now I think it is ready to go and merge [ if accepted ] . May be it is better to merge all commits into one to keep linuxcnc git history clean? I can do it from my side - just tell me a word. |
I see no further objections.
Yes, that would be very nice if you did that. |
Replaces the fixed-function preview shared by AXIS, the GTK screens and QtVCP with a shader/VBO renderer: a baked trajectory buffer, an offscreen ID-buffer pass for picking, and a glyph atlas for overlay text. The GL matrix stack, display lists, immediate mode and GL_SELECT are gone. Added optional optimised MoveBatch protocol to g-code parser. Rendering code decomposed to a Scene object containing Parts (each can be replaced or disabled).
b0a473c to
6aa48da
Compare
Done |
6 participants
Replaces the fixed-function preview shared by AXIS, the GTK screens and QtVCP with a shader/VBO renderer: a baked trajectory buffer, an offscreen ID-buffer pass for picking, and a glyph atlas for overlay text. The GL matrix stack, display lists, immediate mode and GL_SELECT are gone.