Hmmm Easy Easy folks IMHO it is way to late to have another either or discussion when we actually have it ALL.
The demo Image I have donated is fully scriped and therefore fully reproducable and every step / command / customisation to every step Is in the open. AND only addition to the default generated sd-image are the DE10_Nano bitfiles which not yet are merged. THis is not an effort to compete with RHN's bbb originated build scripts, but thought as an complementary alternative with additional other feel and options. This scripted image supports DE10 / DE0 with and without framebuffer out-of-the box without major issues. By editing 1 or 2 lines in the uEnv.txt file in the /boot folder the user can specify: whether to run with or without HDMI whether to turn the screen upside down (usefull for my13" lvds screen). And / or if to configure the fpga via u-boot or not. The only outstanding issue is that some of the packages / kernel options for enabling framebuffer support, seem to prevent the kernel from loading. I have this issue limited to the differences in generating a Jessie sd-image without or with the -desktop option in my buildscript repo ATM. --- I see no need for 3-D display or opengl etc. (I prefer the Machinekit-client --> Machineface, Cetus) However I see possibilities for having an local (touch based) 2-D display of which the Cyclone V socs do a decent job (even without DMA which is an upcoming option that may improve dragging windows a bit). --- On another note practical tests have shown that it is possible to fully reload the fpga, without the system going haywire (except for the blank screen), which indicates that linux and the built in fpga(freeze) bridged + the altera socfpga 4.1.22-rt-ltsi kernel play well together in a default non optimized for this scenario setup. You are very welcome to test the demo image with own hands to debunk or verify this bold claim. Having to physically lock down the framebuffer cores, may be to challenging for the small (60-70% full) DE0, however The DE10 project uses only (28%) in the HDMI PIN_3x24_cap config, so I cannot refrain any longer from just talking about it and have to do some practical real world testing going down this occult like (partial reconfiguration) road, and report my findings. Intel seems to have been busy focusing on the enterprise market for now leaving the Cyclone V SoC as the top low-cost bid. (I know not much about what Xilinx are doing). THis may change as Intel now has the potential to whip up something like a i5-fpga with a decent 3D graphics core, when the time gets ripe, why wait for that ? On Friday, 1 September 2017 20:28:30 UTC+2, Charles Steinkuehler wrote: > > On 9/1/2017 1:11 PM, mugginsac wrote: > > I disagree with Charles and Schooner. I used console access for years > and I > > have had enough of it. I am tired of typing long lines of console entry > to > > avoid the conveniences of a good gui interface. There are many features > > available in a good gui that help avoid carpal tunnel syndrome. I think > the > > HDMI interface should be enabled by default. You can run MachineKit via > ssh > > on another machine with decent 3D acceleration but having a gui > interface > > on the DE10 still has value. If you want to talk about slow go back to a > > 2mHz Z-80. > > You are free to work on this if you'd like. IMHO, graphics > performance on the DE10 HDMI output is going to be dismal without > hardware acceleration, and building a GPU isn't generally a very > efficient way to use FPGA gates (although it is possible). > > ...and I've used many single MHz 8-bit systems, most of which would > probably have perceptively better performance than what you can get > from a DE10. But today you usually can't get by with 2 or 3 > bit-planes of data with less than 100k pixels, or "cheats" like the > old character/tile based graphics displays. And even with a fast > 32-bit ARM core, it takes a long time to do 3D manipulations on > graphics data with the CPU. > > Using any sort of remote display with a built-in GPU (even my cheap > $20 Andriod cell phone) will give you *MUCH* better performance than > you could ever get natively on the DE10, even if you allocate all the > FPGA gates to graphics acceleration. > > > You can avoid a half a billion lines of gcode by using a code generator > > that uses subroutines where possible instead of straight inline code. > > For subtractive machining, yes. But the really big gcode files tend > to be generated by 3D printing, and there isn't really an effective > way to make them significantly smaller. > > -- > Charles Steinkuehler > [email protected] <javascript:> > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
