0

Can a laptop with a AMD or Intel CPU, an AMD GPU and a Thunderbolt port connect to an external GPGPU box with a NVidia card?

The code to run on the external GPU could be either OpenCL or CUDA based.

Pietro
  • 127
  • 6
  • I'm voting to close as off topic, but the answer is that it'd be fine with an Intel CPU but won't work with AMD since until the X399 Designare comes out, no AMD motherboards support Thunderbolt 3, and no AMD laptops support Thunderbolt 3. – JMY1000 Jan 12 '18 at 04:55

1 Answers1

1

According to this Wikipedia article, the external GPU will be connected by carrying the PCIe bus signals over a Thunderbolt connection, at the speed of upto PCIe x4 rather than x16. Now, for many general-purpose computing applications, the PCIe bandwidth is already a bottleneck at x16 (16 GB/sec theoretical, 12 GB/sec actual), so reducing that by a factor of 4 would be terrible. If, however, you have a lot of computation to do on every piece of data, this should be possible. (I'm not being definitive since I haven't tried this myself).

It's likely, however, that the whole exercise is not worth it, and you should just get a small-form-factor PC which fits a full size GPU (here are a few of them, in a roundup from April 2017).

einpoklum
  • 138
  • 4
  • A 4x 3.0 connection is unlikely to be a bottleneck; cards are nowhere near saturating their connection. You're not wrong that there's a performance decrease, but this comes from the fact that the connection goes through the chipset rather than directly to the CPU. As much as I'm an advocate for building your own computer, there are many, many legitimate use cases for an eGPU, and dismissing them out of hand is a poor decision. – JMY1000 Jan 12 '18 at 04:59
  • @JMY1000: This is actually my field of research - GPUs in analytic DBMS work. So, I can tell you with some confidence that at in many (though not all) computational workloads, 12 GB/sec is very much a bottleneck. When it isn't, either you're doing some, say, deep learning, or physics number crunching, or alternatively - your system is likely mis-designed or mis-implemented. That would not at all be surprising, because software systems utilizing GPUs are still in their infancy in many respects. – einpoklum Jan 12 '18 at 12:40
  • It'll depend on the workload of course, but for something like deep learning or graphics rendering, having to go offboard on any sort of regular basis is often considered a failure because the time to do any sort of fetch from the main system memory absolutely kills the performance; you just can't do 900 GB/s over FSB/HT/QPI/UPI. For our application we only ever fetched data from the system memory when switching out training batches. – JMY1000 Jan 12 '18 at 12:51
  • That combined with the fact that his post history focuses heavily on Boost and TensorFlow leads me to believe that his workload shouldn't be regularly fetching from system memory. To be honest, I'm not an expert in this field, but it seems like your use case is fairly different from OPs. I tried pulling up the page on your profile to poke around some more and better understand it, but it's 404ing unfortunately. – JMY1000 Jan 12 '18 at 12:54
  • The workload will be a deep-learning based one. So there should not be a huge amount of I/O, being it limited to the input/output layers. However, periodically I may have to swap the NN stored on the GPU memory with another one stored in main memory (network partitioning). – Pietro Jan 12 '18 at 13:23
  • 1
    @Pietro In that case an eGPU solution is probably fine. That said, given what you're doing, it's likely that the GPU will be a massive portion of the cost of the build (especially if you opt for a Quadro or other high-memory card), and just throwing it on a cheap platform may work out better than trying to lug around a GPU and enclosure all the time. – JMY1000 Jan 12 '18 at 13:51