First, it's great that we are starting to get an open parallel GPU software stack. This can all get leveraged by open hardware.
But Try doing secure boot (or just working with a bootloader) on an Intel CPU and you might see why it's a non-starter. The problem with 'disposable' consumer hardware is... it's disposable. I cannot afford the testing to re-qualify a new disposable hardware platform if I'm in the middle of harvest. I have to find a replacement part and get the combine moving again as fast as possible. For this reason, if I don't have the silicon mask I can call up a fab house running on 15 year old tech and have them make me a few wafers of spares, then it's pointless. I might as well just save my effort, and use pre-computer technology (relays and switches) because I can troubleshoot, repair, and replace it when it fails. Unless, of course, someone decides to offer long-term support on the 'disposable' consumer hardware by opening up the masks, then I might think it's worth my time to document all the hardware bugs and fix the ones that irritate me. In the meantime though, an open infiniband core for an FPGA might be really interesting link to connect to fast disposable stuff that can do fancy things that are nice to have but are not critical to operation... see http://seniord.ece.iastate.edu/may0904/project-files.html https://bitbucket.org/tmagik/infiniband-fpga On Wed, Jan 27, 2016 at 07:11:13PM -0500, John Culp wrote: > Troy, > You are hitting on something that I've been working on for quite > some some. (for personal - not GaTech - projects). > > My conclusion has been that I should build around an io subsystem > with an embedded processor (all fpga based of course) that I can > talk to over Ethernet. > > This lets me leverage all the consumer tech with its regular > performance and power improvements to run high level and gui stuff > while still being able to do serious hard real time work in a no OS > environment. The top level consumer platform is really just > disposable. > > What I am describing is actually a lot more than theoretical - I've > built many automated systems and robots with my first generation > hardware, and just hit timing closure on the second generation hours > ago. What I have described is a bit simplified, but the point is > this design approach just werks! > > As far as this open graphics stuff goes, I am still convinced that > the problem of free software support is disappearing as graphics > hardware becomes general purpose. > > One example: I have built a mobile robot platform based on the > kinect2 that runs ROS and has a Haswell cpu on an itx motherboard. > The freenect2 drivers (as compiled) utilize the gl stack for > hardware accelerated kinect2 data processing. So this is a real > software stack utilizing entirely open software for robotics that > uses the internal Intel GPU. I do the entire mapping & localization > thing based purely on the kinect2 data. I plan to move this code > over to the opencl paths using beignet, again fully open source. I > have certainly seen the order-of-magnitude (plus) performance > improvement in going from purely cpu to gpu processing during that > project. > > Anyway: Your application seems so similar to mine that I can only > recommend not getting too hung up on open hardware for the user > interface. I would think that most of your value is going to be > created in the low level engineering and high level management / > front-end code. So use whatever disposable platform you want for > the front-end that gives you the most bang for the buck. Of course > put pressure on the manufacturers by picking the one that is most > open that fits your needs. :) > > Any platform that gives you a serial, ethernet, or wifi, or I > suppose even bluetooth serial (have not tried) can get you > interfaced to some embedded system handling hard real time control > loops and low level io. These high-level interfaces are not going > anywhere, so you are not tying your engineering to any given > platform. That being said, I personally try to avoid USB where > possible. > > -John > > Troy Benjegerdes wrote: > >Yes, because I'm not going to buy a GPS guidance system for > >my tractor, combine, or agricultural imaging drones without > >having a long-term path to be able to replace the silicon in > >the display console with something I have the source HDL for. > > > >If I do a horribly subjective estimate based on: > >http://download.intel.com/pressroom/kits/IntelProcessorHistory.pdf > >I suspect we could get somewhere between 75 and 150mhz, which > >should be plenty to do better with some peer reviewed software > >than what google maps with all its java overhead, random crashes, > >and binary blobs can do on my phone. > > > -- ---------------------------------------------------------------------------- Troy Benjegerdes [email protected] 7 elements earth::water::air::fire::mind::spirit::soul grid.coop _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
