OpenSCAD on Raspberry PI
On 6/16/2020 7:32 AM, Rogier Wolff wrote:
But Moore's law says that transistors keep getting cheaper, ...
Moore's law is an observation, not a law of physics. There's nothing
that says that it will continue.
On 16.06.20 05:35, MichaelAtOz wrote:
Does this overcome OpenGL ES
No, it just uses the fact that Debian decided to stay
with Qt5+OpenGL as default on ARM64 and provide Qt5+GLES
as additional package. (Thanks!)
Unfortunately ARM32 continues to be GLES only so it
needs building a separate Qt5. This is possible, but
making that happen as automatic build eats too much
time I don't have anyway. So I'm not sure if it will
happen at some point. Right now, I tend to think it's
not worth the effort.
It's probably more useful to think about how to move
forward into direction of Vulkan.
ciao,
Torsten.
On Tue, Jun 16, 2020 at 6:44 AM nop head nop.head@gmail.com wrote:
Yes I was wondering the same thing. My PC is a few years old now but
OpenSCAD is the only program I wish it was faster for. I do have a faster
Linux machine but I develop using a database on Google Drive and Google
don't do a Linux version.
A bit off-topic, but yeah it's really disappointing that Google still
refuses to support Drive for linux. But there are options! I use a 3rd
party app called insync ( https://www.insynchq.com/ ) which syncs up my
Google Drive to Linux Desktop. It's not free, but worth the price IMO.
On Tue, Jun 16, 2020, at 3:32 PM, Torsten Paul wrote:
On 16.06.20 05:35, MichaelAtOz wrote:
Does this overcome OpenGL ES
No, it just uses the fact that Debian decided to stay
with Qt5+OpenGL as default on ARM64 and provide Qt5+GLES
as additional package. (Thanks!)
Unfortunately ARM32 continues to be GLES only so it
needs building a separate Qt5. This is possible, but
making that happen as automatic build eats too much
time I don't have anyway. So I'm not sure if it will
happen at some point. Right now, I tend to think it's
not worth the effort.
It's probably more useful to think about how to move
forward into direction of Vulkan.
There was a status update on the Raspberry Pi 4 Vulkan port last week:
https://www.raspberrypi.org/blog/vulkan-update-now-with-added-source-code/
That's good progress after 5 months of work.
There won't be a Pi 3 Vulkan driver, so a Vulkan version of OpenSCAD will only run on Pi 4.
Torsten also wrote:
What would be awesome:
Fast multi-threaded algorithm with GPU support :-)
The GPU on the Pi 4 has 8 cores, each core is 4-way SIMD (compared to 4 CPU cores). So, rendering on the GPU would probably give the best performance.
You can set them up to boot off a TFPT server and run diskless with no
SD card and then they can only work in their own scratch area on a
shared disk. and the Pis boot a clean image each time they are powered on.
Only downside is that they need to be on a hardwired network.
Small SD cards are very cheap and you can supply a class with 4Gb cards
for less than the cost of a softdrink each.
Once the WiFi sets up during the boot, you can share a file server with
read-only areas and shared per student areas.
On 2020-06-16 10:15 a.m., Rogier Wolff wrote:
On Tue, Jun 16, 2020 at 01:50:22PM +0000, Doug Moen wrote:
I haven't tried running a Raspberry Pi based makerspace for kids.
But, I imagine that you can just give each student their own Pi,
and swap out the SD card if the OS gets corrupted.
Or you tell everybody to bring their own SD card. (or supply everybody
with...)
Roger.
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
If the SDs are only used for boot, they should not get corrupted and
should not contain the students' files.
Ron
On 2020-06-16 10:22 a.m., nop head wrote:
The SD sockets on RPI's are not very robust in my experience. It might
be better for them to bring their own USB stick.
On Tue, 16 Jun 2020 at 15:15, Rogier Wolff <R.E.Wolff@bitwizard.nl
mailto:R.E.Wolff@bitwizard.nl> wrote:
On Tue, Jun 16, 2020 at 01:50:22PM +0000, Doug Moen wrote:
I haven't tried running a Raspberry Pi based makerspace for kids.
But, I imagine that you can just give each student their own Pi,
and swap out the SD card if the OS gets corrupted.
Or you tell everybody to bring their own SD card. (or supply everybody
with...)
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
+31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK:
27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
I believe that the Pi's ARM is a RISC architecture so that less gets
done on each cycle but the cycles come quicker!
On 2020-06-16 10:32 a.m., Rogier Wolff wrote:
On Tue, Jun 16, 2020 at 02:59:35PM +0100, nop head wrote:
I don't think the number of cores makes much difference unless you have
multiple instances open.
So... for Openscad, to be able to make better use of the available
performance on the pi, a "roadmap" for openscad might include: "make
better use of multiple cores".
Keep in mind that intel hit peak-clock-frequency somewhere around a
decade ago. But Moore's law says that transistors keep getting
cheaper, so even though still significant improvements keep being made
in how much work can be done in each CPU clock cycle, in the future
we'll be getting more and more cores in a chip. Currently even the
cheap hardware (e.g. pi) has four cores because they don't know what
otherwise to do with the available transistors!
Roger.
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
The cores might not help but my suggestion of a multi-computer
workstation with a single keyboard, mouse and screen with a bank of
slave Pis that could render the parts in parallel while you caught up on
your email, would mean that your whole render job would only take as
long as your longest render (given you have enough Pi4s).
For less than the price of a new workstation, you could probably put
together a 4 or 8 Pi4 box, power supply, shared 1 terabyte networked
drive and USB switch for the keyboard and mouse giving you the ability
to run 8 renders or previews in parallel.
You do not even need the keyboard/mouse switch if you can script a
rendering process that every 2 seconds wakes up and looks for new files
in a certain location on the shared drive and automatically renders
anything that the Pi4 finds that you have put there and moves the input
drawing and the results to an output folder when the render is finished.
I cannot see why every CAD person would not want a bank of render slaves!
Ron
On 2020-06-16 10:53 a.m., nop head wrote:
There are experimental versions of OpenSCAD using multiple cores for
rendering but that isn't what is slow for me. I do all my work in
preview mode and only render the STLs to print them. Most don't take
long, especially compared to printing them. E..g 38 parts to make a 3D
printer take 7 minutes to render individually. The slowest one is the
shelf bracket at 78 seconds, most take less than 10s. Drawing the
preview from scratch, which does render() some of the parts takes 4
minutes. The killer is every simple change takes at least 23 seconds
to redraw currently. Most of that time is running the script, so hard
to see how multiple cores would help that.
On Tue, 16 Jun 2020 at 15:32, Rogier Wolff <R.E.Wolff@bitwizard.nl
mailto:R.E.Wolff@bitwizard.nl> wrote:
On Tue, Jun 16, 2020 at 02:59:35PM +0100, nop head wrote:
I don't think the number of cores makes much difference unless
you have
multiple instances open.
So... for Openscad, to be able to make better use of the available
performance on the pi, a "roadmap" for openscad might include: "make
better use of multiple cores".
Keep in mind that intel hit peak-clock-frequency somewhere around a
decade ago. But Moore's law says that transistors keep getting
cheaper, so even though still significant improvements keep being made
in how much work can be done in each CPU clock cycle, in the future
we'll be getting more and more cores in a chip. Currently even the
cheap hardware (e.g. pi) has four cores because they don't know what
otherwise to do with the available transistors!
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
+31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK:
27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
The biggest pi4 is 4Gb and costs about $60 which is a lot less than 250
Euros
You don't need the monitor if it is only doing rendering.
Look at it as a notebook accessory for rendering.
Less than the cost of an ergonomic mouse or webcam.
Ron
On 2020-06-16 10:54 a.m., Torsten Paul wrote:
On 16.06.20 15:57, jon wrote:
This all makes sense. What I am not clear on is how much
of a performance hit I would take vs my 8 core 4 GHz desktop
Unless someone completes the "Multi-threaded Geometry
rendering" issue (earning the current bounty of $1060),
the number of cores does not matter much.
So comparing my 2 years old Dell XPS 13 with i7-8550U
@ 4GHz max using the Menger Sponge level 3 example, I
see (even including the monitor in the Raspi price):
Notebook | Raspi 4 (8GB) | Ratio
35 seconds | 2:46 minutes | 1 : 4.7
~2200€ | ~250€ | 8.8 : 1
I guess the performance hit is not as bad as one
would imagine while the price is very nice.
I certainly would not suggest using a Raspi for very
complex stuff, but there's lots of things that it will
be able to do in a reasonable way. Especially when
looking at the 64bit/8GB model.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Ron Wheeler
Artifact Software
438-345-3369
rwheeler@artifact-software.com
On 16.06.20 20:37, Ron Wheeler via Discuss wrote:
The biggest pi4 is 4Gb and costs about $60
Ahem, obviously not, as the one I tested on
has 8GB :-).
https://www.raspberrypi.org/blog/8gb-raspberry-pi-4-on-sale-now-at-75/
ciao,
Torsten.