Gremlin rewrite for OpenGL ES and possible optimization
- alex_sar
- Offline
- New Member
Less
More
- Posts: 11
- Thank you received: 7
21 Jun 2024 16:09 #303498
by alex_sar
Gremlin rewrite for OpenGL ES and possible optimization was created by alex_sar
Hi All,
I tried to rewrite Gremlin - make new widget based on existing code and contribute it. It made with using of recent OpenGL ES API (shaders/vertex buffers/etc.). The code is not ready to show yet, but I got all parts working and it is possible to make it handling bigger g-code files and do it fast enough. Currently big files simply excluded from preview. At first look, the problem is large Python trajectory arrays that filled one-by-one and then handled in Python again with lot of iterations. I rewrote it to use number of continous memory buffers (fixed size each) and it made a big change immediately. That is not the question, I hope I can show results soon. Just want to ask if anyone have interest in this new widget?
Another big deal is number of calls between C++ code and Python code. I did not measure it yet, but gcodemodule.cc does calls like this for any point in trajectory:
When it repeated n*thousand times, it becomes a bottleneck for sure. My idea is to modify methodand add an optional parameter for this to accept C method pointers for "straight_feed", "traverse", etc. So when this parameter passed, it will call C callbacks instead of python methods and do not do all this Python variable conversion back and forth. Something like thisI believe this may be a huge performance win and I hope it does not violate any LinuxCNC development guidelines.
My question is to project maintainers. If I make this change and submit to Github to merge, will it be accepted?
I tried to rewrite Gremlin - make new widget based on existing code and contribute it. It made with using of recent OpenGL ES API (shaders/vertex buffers/etc.). The code is not ready to show yet, but I got all parts working and it is possible to make it handling bigger g-code files and do it fast enough. Currently big files simply excluded from preview. At first look, the problem is large Python trajectory arrays that filled one-by-one and then handled in Python again with lot of iterations. I rewrote it to use number of continous memory buffers (fixed size each) and it made a big change immediately. That is not the question, I hope I can show results soon. Just want to ask if anyone have interest in this new widget?
Another big deal is number of calls between C++ code and Python code. I did not measure it yet, but gcodemodule.cc does calls like this for any point in trajectory:
PyObject *result =
callmethod(callback, "straight_feed", "fffffffff", x, y, z, a, b, c, u, v, w); // gcodemodule.cc:340
When it repeated n*thousand times, it becomes a bottleneck for sure. My idea is to modify method
static PyObject *parse_file(PyObject *self, PyObject *args) {
if (straight_feed_callback) {
(*straight_feed_callback)(x, y, z, a, b, c, u, v, w);
} else {
PyObject *result =
callmethod(callback, "straight_feed", "fffffffff",
x, y, z, a, b, c, u, v, w);
if(result == NULL) interp_error ++;
Py_XDECREF(result);
}
My question is to project maintainers. If I make this change and submit to Github to merge, will it be accepted?
The following user(s) said Thank You: MennilTossFlykune, JT
Please Log in or Create an account to join the conversation.
- PCW
- Offline
- Moderator
Less
More
- Posts: 17908
- Thank you received: 4794
21 Jun 2024 16:26 #303499
by PCW
Replied by PCW on topic Gremlin rewrite for OpenGL ES and possible optimization
Not a developer but sounds great especially
for complex gcode or slower machines.
Probably best in a separate branch initially.
for complex gcode or slower machines.
Probably best in a separate branch initially.
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
Less
More
- Posts: 19430
- Thank you received: 6508
21 Jun 2024 16:29 #303500
by tommylight
Replied by tommylight on topic Gremlin rewrite for OpenGL ES and possible optimization
If you do not try, you will never know.If I make this change and submit to Github to merge, will it be accepted?
Please Log in or Create an account to join the conversation.
- alex_sar
- Offline
- New Member
Less
More
- Posts: 11
- Thank you received: 7
21 Jun 2024 18:03 #303506
by alex_sar
Replied by alex_sar on topic Gremlin rewrite for OpenGL ES and possible optimization
got it
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- MennilTossFlykune
- Offline
- Junior Member
Less
More
- Posts: 35
- Thank you received: 25
21 Jun 2024 22:03 #303516
by MennilTossFlykune
Replied by MennilTossFlykune on topic Gremlin rewrite for OpenGL ES and possible optimization
I am very interested in seeing it. Is it a drop-in replacement for glcanon.py?
Please Log in or Create an account to join the conversation.
- alex_sar
- Offline
- New Member
Less
More
- Posts: 11
- Thank you received: 7
22 Jun 2024 07:49 #303537
by alex_sar
Replied by alex_sar on topic Gremlin rewrite for OpenGL ES and possible optimization
Yes, that is the goal.
One thing that is still 100% unclear for me is foam cutter visualization. There is some magic code in Gremlin for this. I never worked with such kind of machines. Is there any LinuxCNC documentation regarding foam cutter setup? Or may be one can explain in short?
One thing that is still 100% unclear for me is foam cutter visualization. There is some magic code in Gremlin for this. I never worked with such kind of machines. Is there any LinuxCNC documentation regarding foam cutter setup? Or may be one can explain in short?
Please Log in or Create an account to join the conversation.
- Aciera
- Offline
- Administrator
Less
More
- Posts: 3981
- Thank you received: 1723
22 Jun 2024 08:01 - 22 Jun 2024 08:51 #303538
by Aciera
Replied by Aciera on topic Gremlin rewrite for OpenGL ES and possible optimization
Have a look at the foam simulation config 'configs/sim/axis/foam/axis_foam.ini'.
Basically it produces two separate previews, one for XY and one for UV
[edit]
Note that the Z,W height comes from the gcode lines (there are no actual Z or W axes)
(AXIS,XY_Z_POS,5)
(AXIS,UV_Z_POS,30)
[edit2]
The idea is that the two cones represent the end of a hot wire cutting through styrofoam
Basically it produces two separate previews, one for XY and one for UV
[edit]
Note that the Z,W height comes from the gcode lines (there are no actual Z or W axes)
(AXIS,XY_Z_POS,5)
(AXIS,UV_Z_POS,30)
[edit2]
The idea is that the two cones represent the end of a hot wire cutting through styrofoam
Attachments:
Last edit: 22 Jun 2024 08:51 by Aciera.
The following user(s) said Thank You: alex_sar
Please Log in or Create an account to join the conversation.
- alex_sar
- Offline
- New Member
Less
More
- Posts: 11
- Thank you received: 7
22 Jun 2024 09:03 #303543
by alex_sar
Replied by alex_sar on topic Gremlin rewrite for OpenGL ES and possible optimization
Thank you, that is clear now!
Please Log in or Create an account to join the conversation.
Time to create page: 0.123 seconds