<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The bottleneck in todays graphics is not hardware as the GPU is idling most of the time. You may argue that this is not the case, as you get better results with more lanes and higher bus speeds.<div class=""><br class=""></div><div class="">The reason for the performance boost for high speed, multiple lanes is that transfer between the CPU and GPU goes faster, leaving more execution time to the bloatware in the computer to do their stuff.</div><div class=""><br class=""></div><div class="">However, the bottom line is that good software can increase the performance of feeding the GPU more than 25 times faster, making up for the ”bottleneck of the hardware”. I was ironical here.</div><div class=""><br class=""></div><div class="">Let’s think about this for a while. For example, hardware takes giant steps in evolution to get faster and faster. Ethernet has gone from 10Mbit to 100Mbit, 100Mbit to 1 Gbit, from 1 Gbit to 10 Mbit. How about the software? It travels in the opposite direction.</div><div class=""><br class=""></div><div class="">Luckily for all these bloatware contributors, Intel has done real magic making there CPUs unbelievable fast, so despite the total lack of software performance it works quite good.</div><div class=""><br class=""></div><div class="">However, writing software the right way can actually increase performance 20 to 100 times, depending on there task. If you can keep the GPU from idling you will get a lot of performance out of Minnowboard Max with the built in GPU.</div><div class=""><br class=""></div><div class="">It doesn’t matter how fast the hardware made by Intel and other vendors are. It takes two to tango, so good software is the key. This will not happen in the open source community as there are too many involved. It always tend to be quantity instead of quality.</div><div class=""><br class=""></div><div class="">Quantity is not the answer to high performance. Quality is. Everything counts, so every single peace in the machinery needs to perform. You wouldn’t build an engine on a race card with a mixture of low and high quality components, would you?</div><div class=""><br class=""></div><div class="">Best regards,</div><div class=""><br class=""></div><div class="">B-O </div><div class=""><br class=""></div><div class=""> <br class=""><div><blockquote type="cite" class=""><div class="">16 jul 2015 kl. 04:01 skrev Scott Guthrie <<a href="mailto:scottgu3@gmail.com" class="">scottgu3@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="">You know...this type of thing has been tickling my brain lately. I wasn't thinking Minnowboard though...but a NUC (i7 or i5) would seem to have enough oomph to do this. Sadly they seem to be limited to 12 PCIe lanes and 4x1 or 2x4 lane configurations.<br class=""><br class=""></div>And frankly, I can surmise this isn't really in the INTEL roadmap (after all a NUC is not really MEANT to be a Gaming PC), but damn, one x16 Slot, even if I had to through a slot extender to a second case and power the GPU separately. <br class=""><br class=""></div>Once can dream I suppose.<br class=""><br class=""></div>Sorry....Tangent.<br class=""><br class=""></div>S.<br class=""><div class=""><div class=""><br class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jul 15, 2015 at 8:04 PM, John 'Warthog9' Hawley <span dir="ltr" class=""><<a href="mailto:warthog9@eaglescrag.net" target="_blank" class="">warthog9@eaglescrag.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/15/2015 08:42 AM, Ashot Arshakyan wrote:<br class="">
> Hello. I have a project where I need to render thousands of OpenGL<br class="">
> frames each second by using a x86 based PC and a typical high end NVidia<br class="">
> GPU.<br class="">
> The problem is I have a pretty limited space for the electronics of the<br class="">
> device I'm working on so I was hoping I could use a single board PC<br class="">
> instead of using a mini ATX.<br class="">
> SInce the main rendering job is done on the GPU, I thought the<br class="">
> Minnowboard CPU would be fast enough for the job. What are your thoughts?<br class="">
> Now I just need to know how I can connect a standard GPU to Minnowboard.<br class="">
> I'm thinking of powering the GPU with a flat 12V 30A power supply<br class="">
> instead of ATX to again save some space.<br class="">
<br class="">
</div></div>So there's a couple of things you should be aware of while pondering<br class="">
this. It *MIGHT* work, but you'll need to consider that modern graphics<br class="">
cards use a LOT of bandwidth for moving data in and out of the graphics<br class="">
card. They usually employee 16 lanes of PCI-e, which at it's oldest and<br class="">
slowest is about 4GByte/s. So there's two potential issues here:<br class="">
1) The MinnowBoard only has a single lane of PCI-e v2<br class="">
available for use through the high speed expansion<br class="">
header. This gives you a maximum throughput of<br class="">
about 500MByte/s<br class="">
<br class="">
2) *MANY* graphics cards won't negotiate their PCI-e<br class="">
lanes down to the point where it will work in a x1<br class="">
connector. This is mostly an assumption from the<br class="">
manufacturers that the card would never be used in<br class="">
such a slot. Case in point when we tried to get a,<br class="">
admittedly rather high end, graphics card working on<br class="">
the MAX on April 1st this year, it didn't work as<br class="">
the card couldn't negotiate down to a single PCI-e<br class="">
lane<br class="">
<br class="">
The only way to overcome 2, that I can think of, is to put a PCI-e<br class="">
switch on the bus that can provide 16 lanes, but only upstream via 1.<br class="">
This still limits your maximum bandwidth to 500MByte/s though, but it<br class="">
should get you past the lane negotiation issue. That's a substantial<br class="">
amount of work though, and likely a need for a custom lure to be built<br class="">
to accommodate it. Just some thoughts.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
- John 'Warthog9' Hawley<br class="">
_______________________________________________<br class="">
elinux-MinnowBoard mailing list<br class="">
<a href="mailto:elinux-MinnowBoard@lists.elinux.org" class="">elinux-MinnowBoard@lists.elinux.org</a><br class="">
<a href="http://lists.elinux.org/mailman/listinfo/elinux-minnowboard" rel="noreferrer" target="_blank" class="">http://lists.elinux.org/mailman/listinfo/elinux-minnowboard</a><br class="">
</font></span></blockquote></div><br class=""></div>
_______________________________________________<br class="">elinux-MinnowBoard mailing list<br class=""><a href="mailto:elinux-MinnowBoard@lists.elinux.org" class="">elinux-MinnowBoard@lists.elinux.org</a><br class="">http://lists.elinux.org/mailman/listinfo/elinux-minnowboard<br class=""></div></blockquote></div><br class=""></div></body></html>