[Sticky] eGPUs under Linux: an advanced guide  

 

theitsage
(@itsage)
Noble Member Admin
Joined:1 year  ago
Posts: 2373
September 5, 2017 1:49 pm  

I've been following Blitz_Works on Twitter and his progress with eGPU under Linux. He published an advanced guide yesterday documenting his use and other interesting findings. He was able to flash the AORUS Gaming Box firmware in Linux.

Even if you're not a Linux user, I'd highly recommend reading his guide. This is a wonderful resource -  http://pocketnix.org/posts/eGPUs%20under%20Linux%3A%20an%20advanced%20guide

Best ultrabooks for eGPU use

eGPU enclosure buying guide

51 external GPU build guides


Flint Ironstag, 3RYL, ikir and 2 people liked
ReplyQuote
Da_Blitz
(@da_blitz)
Active Member
Joined:10 months  ago
Posts: 5
September 6, 2017 9:36 am  

Hoping to have more to come in the future, i have a bunch of small scripts and other things that can be dropped into places in /etc to make the whole experience plug and play, testing it all is what takes up most of the time.


theitsage
(@itsage)
Noble Member Admin
Joined:1 year  ago
Posts: 2373
September 6, 2017 12:22 pm  

@Da_Blitz Welcome aboard. Thank you for documenting your experience and findings. We're looking forward to your scripts and help for Linux eGPU users.

Best ultrabooks for eGPU use

eGPU enclosure buying guide

51 external GPU build guides


ReplyQuote
Flint Ironstag
(@flint-ironstag)
Estimable Member
Joined:1 year  ago
Posts: 157
September 18, 2017 5:14 pm  

Welcome @Da_Blitz, I'll check out your guide at lunch today.

MP 6,1 | 4c | d700
MP 6,1 | 6c | d500


ReplyQuote
(@john_langley)
New Member
Joined:3 months  ago
Posts: 1
February 15, 2018 8:14 pm  

Good afternoon!  I wanted to thank you for the link.  I am a new member and a long-time Linux user (currently Arch on a 2017 version HP Spectre x360 13.3", and Gentoo on home built server and workstation/gaming station).  As the Spectre is decent with the built-in Intel video chip, I would like to have a little more "GAME" while travelling.  When I had run across the eGPU idea, it started the wheels turning.  I'm still reluctant on buying one right now, since I don't even know if it'd work or work well, but if I could find a decent enclosure that would travel in my suitcase with me and is compatible with Linux kernel, I would be apt to buy one today.  I say 'enclosure' because I already have several video cards laying around my house.  The latest addition to the stockpile of old equipment is an older GTX670, which I'm sure would be more than fine for a mobile eGPU to play a few games.

What say the Linux users here?  Are there many of us on this forum?  Has there been any headway in making this work?  Can I still use the laptop screen with the eGPU, or must it use an external display?  Is bumblebee used for the switching process, or is it 'on all the time'?

I truly hope you all don't mind my questions.  Being new to the idea (but not new to linux), I'm hoping to glean some good info before making a huge plunge into the area.

thanks for your time!!!

--John


ReplyQuote
Da_Blitz
(@da_blitz)
Active Member
Joined:10 months  ago
Posts: 5
March 2, 2018 2:23 pm  

Hi John

As per my guide above everything basically works with very little issue.

Bumbblebee operates in such a way where it is only active if the GPU is attached and an application is actively using it as well. This causes the GP U to downclock/Power manage or be detached at will

the driver stuff was the easy part, the hard part was working out what pieces where needed and the integration between them and as such my guide is more of a starting point that tries to fill in most of the gaps but some customization for your setup may be require

If doing opencl work or cuda work then its even simplier and nearly plug and play with linux


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
April 6, 2018 5:44 am  

The guide is rather useless - it is Nvidia specific.

Does anybody know what the story is with AMD?

It would appear to work, except:

[Apr 6 13:31] [drm] amdgpu kernel modesetting enabled.
[ +0.000272] [drm] initializing kernel modesetting (FIJI 0x1002:0x7300 0x1002:0x0B36 0xCA).
[ +0.000050] [drm] register mmio base: 0xC4000000
[ +0.000001] [drm] register mmio size: 262144
[ +0.000020] [drm] probing gen 2 caps for device 8086:1578 = 1715c43/e
[ +0.000004] [drm] probing mlw for device 8086:1578 = 1715c43
[ +0.000010] [drm] UVD is enabled in physical mode
[ +0.000001] [drm] VCE enabled in physical mode
[ +1.617919] ATOM BIOS: 113-C8820200-107
[ +0.000016] [drm] GPU posting now...
[ +5.370805] [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting
[ +0.000022] [drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing B456 (len 304, WS 4, PS 0) @ 0xB51B
[ +0.000019] [drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing B104 (len 183, WS 0, PS 8) @ 0xB17E
[ +0.000002] amdgpu 0000:3c:00.0: gpu post error!
[ +0.000002] amdgpu 0000:3c:00.0: Fatal error during GPU init
[ +0.000017] [drm] amdgpu: finishing device.
[ +0.000198] amdgpu: probe of 0000:3c:00.0 failed with error -22

Dell XPS 9370 i7-8650U, Gigabyte Aorus Gaming Box with AMD Radeon R9 Nano.

Linux 4.16.0-041600-generic with no kernel arguments. Ubuntu 17.10.

Anyway, as soon as that issue is solved (probably with a driver kernel patch from AMD), I find it likely that it will work without any tampering whatsoever.
Does anybody know of any workarounds?

Any information would be appreciated.
Thank you!


ReplyQuote
(@peter_gelderbloem)
Active Member
Joined:2 months  ago
Posts: 7
April 7, 2018 5:21 pm  

Would this work for a linux VM on a mac in virtualbox? 
I just need it for CUDA


ReplyQuote
(@peter_gelderbloem)
Active Member
Joined:2 months  ago
Posts: 7
April 7, 2018 7:26 pm  

virtualbox not working, will try docker


ReplyQuote
stingray454
(@stingray454)
New Member
Joined:2 months  ago
Posts: 3
April 7, 2018 8:17 pm  

Dell XPS 9370 i7-8650U, Gigabyte Aorus Gaming Box with AMD Radeon R9 Nano.

Linux 4.16.0-041600-generic with no kernel arguments. Ubuntu 17.10.

 

Would be very interested to hear of any progress on this, I'm currently thinking of going for an XPS 9370 + eGPU solution, and I have an AMD card laying around that I can use.

Was there any scripts / daemon released by @Da_Blitz?


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
April 9, 2018 7:07 am  

@stingray454 who is "Da_Blitz" and what is their significance here? Sorry, I am unfamiliar.

Linux has much better Thunderbolt Networking already - Windows has had it for a much longer time, and its performance is crippled to less than 3Gbps on a fast computer if mpssvc / msmpeng are running. Linux just works here at full 10Gbps or close enough to that.
You *must* use a very recent kernel. I cannot remember if it was 4.13 or 4.14 with the massive diff in linux/drivers/thunderbolt but the kernels before that will be useless.
Mika Westerburg's patches seem to be in the pipeline for Linux 4.17-rc1 finally. There are also a small number of patches under another Intel employee's name. They might not help at all, but then again, they might just happen to fix a bug or two. They are supporting OsNativePciEnumeration for Titan Ridge which greatly reduces the dependencies on ACPI and firmware, but the word I received from a large AIC maker suggests that it will not work on any system. I was hopeful before that, though. What they did say was it should release the burden on OEMs of implementation costs, and make things much more straight forward.
I would never pay actual money for an Nvidia card - but I found a 750Ti dumped in a system and it worked. Although I thought it was broken because it took me three hours to install the drivers successfully. And people have the nerve to say that AMD has bad drivers. I could try it in the eGPU when I have some spare time. But it will only be an experiment - they say it is an efficient card, but my two year old R9 Nano appears to be much more efficient (and a lot faster).
The other option is to find a way to make it boot as if the card were installed internally. On my Dell 9365 which I returned to the store, if I enabled pre-boot modules for Thunderbolt, it would load the eGPU in Windows without AMD XConnect showing up. The internal GPU was visible, but Windows said it couldn't start. The laptop screen would not work. Disconnecting the eGPU would result in no video output, but it could actually restore the video when the eGPU was re-plugged. However, it does not appear to do that with the Dell 9370 with pre-boot modules enabled. Then again, this thing introduced a few bugs (despite stomping many that were present in the 9365). If you disable the SATA controller, the NVMe M.2 SSD becomes undetectable at boot, and even by an OS booted from USB.
One thing I noticed is that the Dell 9370 had the NVM28 firmware published in January, soon after it was announced. But my laptop shipped with NVM23 - which I did not know existed. So before you upgrade, go into Linux and save the firmware to a file, so that you can revert if need be.
sudo dd if=/sys/bus/thunderbolt/devices/0-0/nvm_active0/nvmem of=/path/to/empty/file

To re-flash a firmware saved this way, you need to prepend 8192 or 16384 null bytes. Which, I cannot remember. I think it makes the total up to 2^19 = 524288 bytes. The firmware updates you download are good to go without tampering. Although if you flash the wrong thing, you can brick it and you will likely need a ROM programmer to fix it. Been there. Not fun.
https://www.kernel.org/doc/html/v4.14/admin-guide/thunderbolt.html
You can find my post in about page 8 of the half-H2D thread - I was getting 1.815GB/s read and write, which is too high for the H2D bug, but too low for what it should be.
Just a tonne of random thoughts. Probably not of immediate use, but then again, the more we put out there, the more likely we are to discover new things of importance.


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
April 9, 2018 7:22 am  

@stingray454 my opinion on the Dell 9370 is excellent right now. It does not appear to be system bottlenecked.
But as I said, Linux and eGPU still do not play nice. At least with AMD - I am not sure about Nvidia.
Overall everything appears to work fine with the Dell 9370 in Linux. There are a few dmesg errors about ACPI method execution failures but everything seems to work as it should. I am not sure yet whether they are Thunderbolt-related or not. I have not tried to make the fingerprint reader work.
I swear, Microsoft Surface Pro that I had before is a joke. For Microsoft Surface, you need a custom kernel, and even then it is dodgy.
It is extremely fast. I smashed the hell out of the Geekbench 4 record for this model. https://browser.geekbench.com/v4/cpu/7826398
Nobody had benchmarked this model before. I am the first. My first result did not add to my account because I messed around with signing in. I wonder why nobody else has benchmarked the i7-8650U. http://www.dell.com/au/p/xps-13-9370-laptop/pd?oc=b520151au&model_id=xps-13-9370-laptop
Also available in 1TB but my advice is buy the 512GB and upgrade the SSD to something decent (read "Samsung; not Toshiba") if you want to do that.
As with all Dells, the arrow keys suck. They should put the PgUp, PgDn, Home, End keys as fn modifiers in the keys. But they screwed that up big time. Pretty that is what LinusTechTips said of a previous model with the same issue.
In Windows, it says External GPUs Supported: No.
But it works fine. Not a hitch. Have not done the NVM28 upgrade, though, and that might change it to be officially "yes".
Also to note, you can see the wattage of the USB-PD adapter in the BIOS screen (I'd love how to find this out in Windows or Linux, anybody know?). The Dell 9365 came with a 30W adapter, but could accept up to 50W as displayed in the BIOS (tested with 100W Aorus eGPU).
The Dell 9370 comes with the 45W adapter, but cannot accept any higher than 45W. Personally they should allow a little more so that it can output more current on Thunderbolt ports for charging phones, or charge its own battery faster, when plugged in to a big dock. Much like Apple was lazy with 87W, but I confirmed it can handshake the full 100W with a friend's Macbook Pro.


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
April 13, 2018 4:09 pm  

Disregard. I got the Fiji XT (AMD Radeon R9 Nano) working with Linux and Thunderbolt. Dell 9370 i7-8650U (B520151AU). Gigabyte Aorus 1070 Gaming Box w/ included 0.5m 40Gbps cable (0.5m is an absolute joke, though. They made optical Thunderbolt 2 cables. Why are there still no optical Thunderbolt 3 cables?).

Upgraded to 4.16.2 kernel (I don't know if that had anything to do with it).

I found that plugging it several times, and spamming the authorisation command in terminal until it appears, seems to get it working. Particularly when you switch from one Thunderbolt port to the other.
It takes a few goes, but it works. I found adding line "DRI_PRIME=1" without quotes in /etc/environment helps (then reboot).

It got smoked by the Intel GPU in glmark2, but that stuff wouldn't stress a 15yo system. I downloaded Unigine Heaven and the performance was well beyond what the Intel GPU could provide. Performance is crap compared to what I would normally expect, but I am not sure whether to attribute that to Thunderbolt, or Linux. I remember using HD6970 and even the mighty HD7970 / R9 280X and this Fiji XT does appear to be extremely good at tessellation. Looking at the dragon with the tessellation maxed out could bring older cards to low single digit FPS. Holding a good 30FPS here at 1080p. Also, who knew that you could tessellate with OpenGL? I thought it was a DX11 thing....

Linux has a fair amount of work to do with this, aside from the amdgpu.ko driver. Dragging windows around on the external monitor is extremely jittery under the wrong conditions. I tried to echo 1 | sudo tee /sys/bus/pci/devices/0000\:00\:02.0/remove but instead of disabling the Intel GPU, the system just locked up. Anyway, if you have DRI_PRIME=1 in environment and have rebooted, it helps, especially with the internal display switched off.

I tried getting the Github progress of the second week merge window for 4.17-rc1 kernel, but I am not sure if you can get half-completed releases. It should almost certainly be out on 2018.04.15 and I can test the drm.ko patches and see if they changed anything in thunderbolt.ko whilst adding Titan Ridge support.


theitsage liked
ReplyQuote
stingray454
(@stingray454)
New Member
Joined:2 months  ago
Posts: 3
April 13, 2018 6:59 pm  

@karatekid430 About Da_Blitz, he just said at the start of the thread that he had some scripts and such to automate the eGPU connection process, just wondered if anyone knew if that ever happened. I assume not.

Thanks for the update though. I've seen a bunch of people (youtube and such) that has got an eGPU running under linux and it seemed pretty effortless from the description. Your description makes me doubt that :/. I suppose you did all the necessary BIOS changes and updated the thunderbolt drivers? I do agree though that it seems to need a lot of work before it's plug and play. I've tried making my thunderbolt monitor be hotpluggable this week too - the device appears / disappears in /sys/bus/thunderbolt, but that's about it - xrandr doesn't notice the connects / disconnects and so on, no way to reset the display. Seems like one of these "let's just wait for the next version of things and hope it's fixed"-scenarios.

I'm starting to think a 9370 + eGPU isn't a good candidate for now. Sure it's the best linux laptop on the market hands down, it's just that I'd like some GPU power occasionally, and might consider a more bulky 9570 instead.. I'll keep a close eye on this for a while longer. Please update with any progress, most interesting to see what can be done!


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
April 17, 2018 3:45 am  
Posted by: stingray454

@karatekid430 About Da_Blitz, he just said at the start of the thread that he had some scripts and such to automate the eGPU connection process, just wondered if anyone knew if that ever happened. I assume not.

Thanks for the update though. I've seen a bunch of people (youtube and such) that has got an eGPU running under linux and it seemed pretty effortless from the description. Your description makes me doubt that :/. I suppose you did all the necessary BIOS changes and updated the thunderbolt drivers? I do agree though that it seems to need a lot of work before it's plug and play. I've tried making my thunderbolt monitor be hotpluggable this week too - the device appears / disappears in /sys/bus/thunderbolt, but that's about it - xrandr doesn't notice the connects / disconnects and so on, no way to reset the display. Seems like one of these "let's just wait for the next version of things and hope it's fixed"-scenarios.

I'm starting to think a 9370 + eGPU isn't a good candidate for now. Sure it's the best linux laptop on the market hands down, it's just that I'd like some GPU power occasionally, and might consider a more bulky 9570 instead.. I'll keep a close eye on this for a while longer. Please update with any progress, most interesting to see what can be done!

Okay, you really shouldn't need scripts to attach it. Granted, the Linux documentation says the sysfs at /sys/bus/thunderbolt is not designed for human interaction - you're meant to use some sort of program to manage it (like the Windows Thunderbolt software). I am not sure if a GUI version exists. But  https://github.com/intel/thunderbolt-software-user-space is something. But from my experience, it is easy to interact with anyway. You cd into /sys/bus/thunderbolt/devices/X-Y - where X is always 0 with single Thunderbolt controller systems, and Y is the port number.
Then "echo 1 | sudo tee authorized" and it should work.

This is with AMD and their drivers seem to have problems over Thunderbolt on Linux for now. At least with Fiji cards. I could try with my R9 280X cards, but that would require a full disassembly of the Aorus Gaming box to fit it in the slot. Anyway, the drivers should be fixed.

FYI, Linux does not "have drivers" in the usual sense. Granted, you can load modules, but if they were compiled separately from the kernel tree then they taint the kernel. The Thunderbolt driver is baked into the kernel source and is upgraded with the kernel version. Not every kernel version results in changes to the driver. But you can identify the driver version by the kernel version. If two people have the same kernel, they should have the same Linux thunderbolt.ko module.

I tried with the Linux 4.17-rc1 that was finally released, which has:
- Patches to thunderbolt.ko to support Titan Ridge Thunderbolt controllers, and to add other enhancements
- Patches to DRM (not Digital Rights Management - it's Direct Rendering Manager - I made that mistake because both sound plausible with HDCP).
- Patches to amdgpu.ko

But it made things much worse. Surprisingly, I could get the eGPU running with loopback to internal display (you'd think that would be the part to require special drivers). Running Unigine Heaven at reasonable performance. But as soon as you plug in an external monitor on the Radeon, it stack dumps and locks up fairly hard (command = "dmesg -wH" to see self-refreshing kernel logs).

This did not happen in 4.16.2 kernel. Even the external display worked on that, once you get the eGPU to pass Atom BIOS. Also, on 4.17-rc1, sometimes pulling the Thunderbolt cable after failed Atom BIOS will actually crash the thunderbolt.ko or related kernel modules - whereas this never happened in 4.16.2. I reported a bug on bugzilla.kernel.org.

Dell 9370 + eGPU is a fantastic candidate - possibly the only one I'd recommend right now. Actually the only laptop even worth buying. Windows, it works fantastically. Linux, it works fantastically except for the AMD Radeon eGPU, which should be patched soon.

**Again, I am loyal to AMD GPUs and this is why I am publishing my findings for AMD. Nvidia could well be working already with Linux, so don't write Linux + eGPU off yet**.

Dell 9570 vs Dell 9370
+ 6-core 12-thread CPU (rumoured i9-8950HK)
+ 32GB RAM configuration available (max 16GB on 9370)
- Only one Thunderbolt port (but at least it's PCIe 3.0 x4, unlike the last model Dell 9560)
= Default charger is not USB-C which means no interchanging charger with other laptops and your smartphone, also unknown compatibility with third party USB-C chargers.
    - Side note, if it can draw 100W from Thunderbolt 3 port, that could be enough to power from the Gigabyte Aorus Thunderbolt 3 Gaming Box eGPU - that would allow for one cable docking by using the USB ports on back of eGPU for Ethernet and peripherals.
    - I think the default barrel charger supplied is 130W - but I doubt it needs it all, since the 9370 only draws 45W (even from 100W source, it does not go any higher, unlike Dell 9365 (30W default -> 50W max if third party charger used).
- Thicker and heavier. I am not sure, but the Dell 9560 had a 2.5" HDD bay which is completely unnecessary in this day and age. I hope the Dell 9570 loses this.
+ dedicated GPU (for me, this is actually a minus, as I never want to own one with dedicated GPU - ask me why if you actually want the long winded reasoning).
- Legacy ports, particularly bad is HDMI. They got the Dell 9370 close to perfect with USB-C only, but I am starting to think this was only to make it thinner. That is not the reason why USB-C should be used exclusively. I believe they are actually way more convenient in every way once people embrace the new technology (you only need adapters if you hold onto the old stuff).
? To be confirmed, Dell 9570 may have second M.2 slot, which opens up a lot of options. You could in theory do NVMe RAID, or boot off an Optane 118GB 800p series and then use a Samsung 960 Pro for main storage. You could have one for Windows and one for Linux. If you are nuts you could run a ribbon cable out of the bottom of the laptop and connect eGPU like that, which would perform slightly better than Thunderbolt.

Overall if you can put up with the bulk and weight of Dell 9570, can put up with there being fewer Thunderbolt 3 and more legacy ports, can put up with losing the ability to charge from either side of laptop, and don't mind dedicated GPU, it could be okay. But then again, what about cost?

Everybody, when choosing eGPUs, please always go for ones with full 100W charging. You might not care now, but down the track you'll end up with something power hungry like the Dell 9570 and then it won't be adequate. If buying something the size of a desktop (such as Sonnet 550W) when you could fit a whole desktop in that footprint, is what floats your boat, then go ahead. But I do think the Gigabyte Gaming Box (available with RX550 / GTX1070 / GTX1080) is the only reasonable option right now.


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
April 17, 2018 3:59 am  

TL;DR? Don't give up on Linux + eGPU because of what I am saying.

My findings are for AMD, and only with one model. I am certain it will be patched soon.
The fundamental parts of Linux for Thunderbolt 3 are working. You approve the device, it shows up in "lspct -vt" command. That is the important part. Just that the amdgpu.ko driver is freaking out under these circumstances right now. So just liken it to Windows driver problem and wait for the update in a later Linux kernel.

Can anybody with Linux + Nvidia GPU confirm if that is working? Post specific hardware - GPU, which enclosure, which system, kernel version, are you using proprietary drivers or Linux kernel ones, make sure you include the names of the Thunderbolt controllers in the computer and the eGPU, along with their respective NVM firmware versions.
In Linux - you can find out this by force enabling Thunderbolt controller if no devices attached "echo 1 | sudo tee /sys/bus/wmi/devices/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power"
Then "cat /sys/bus/thunderbolt/devices/X-Y/nvm_version" where X is always 0 for systems with only one Thunderbolt controller, Y=0 for host controller, Y=1 or higher for attached devices.
Then "lspci | grep "System peripheral"" (remove outer quotes) for controller model.
Then "uname -r" for kernel version.

Thanks!


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
April 17, 2018 4:33 am  

Tried my GTX750Ti that I found dumped. Either it has become faulty, or it has an issue with eGPU - not detected at all.

I did use a PCIe 3.0 x1 cable out of my eGPU to one of my R9 280X cards (too long to fit in Gigabyte Aorus) and it worked first time, no issues whatsoever, external monitor and internal.

So it looks like some AMD cards do work with Linux eGPU flawlessly - but the Fiji (Fury X / Nano) still has some work to be done.

This is on kernel Linux 4.17-rc1.


ReplyQuote
stingray454
(@stingray454)
New Member
Joined:2 months  ago
Posts: 3
April 17, 2018 7:14 am  

Sorry, what I mean to say was firmware (not drivers) - many people recommend booting into windows and flashing some new TB controller firmware before using it in linux, to my understanding the tools are not available in linux yet. Maybe this could help if you haven't tried that already?

I largely agree with you that 9370 is preferable. In my case, I much prefer the 4k display (touch is really useful for me) and HiDPI just looks so good. HiDPI support is good enough to use on a daily driver now imo, using it now. I do however intend to use it for work, where I do at least _some_ 3d stuff - WebGL and such. I currently use a macbook with dedicated M370X that works flawlessly, BUT the performance isn't great. WebGL stuff for example stutters somewhat unless you make the window something like 1920x1080 or smaller, ie a quarter of the screen on 4K. The intel gpu in the 9370 is even slower (although maybe better drivers so it evens out? I'm not really sure), but I can expect equal to worse performace. I also travel with the laptop a lot and wouldn't mind some stutter-free work and lighter gaming on the move. Naturally the plan is to use the eGPU to help with all this, but can't bring that when travelling. A 9570 with discrete gpu sounds like a good deal for me, but I totally agree on all of the other stuff - it has a lot of downsides. A 9370 would tick most of my boxes IF I was sure I could get it working, hence me stalking these forums 🙂

Really good to hear the 280X works fine at least (I have a 290X myself that I can throw into an eGPU, even though I'd rather get something more modern). Less so about the nvidia card. I really seems that you need very specific cards to make this work at all, would be good if someone would compile a list of the success of using different cards in a TB3 eGPU solution under linux. Maybe there is one that I'm not aware of?

Do you happen to know the state of hotplugging? I'm not even sure this work under Windows, but it would be super useful with hotplugging for me personally (often have to disconnect the laptop for meetings and such at work). I'm assuming this won't work for quite some time yet, but if you've tried it with the 280x or similar I'd love to hear what happens.

Anyway, thanks for another good write-up, really appreciated to learn about your progress (or lack thereof). Getting close to ordering a 9370 every day 😀


ReplyQuote
karatekid430
(@karatekid430)
Eminent Member
Joined:7 months  ago
Posts: 43
May 22, 2018 6:16 am  

Did you get the Dell 9370? I am really enjoying it.

Hotplugging - in Windows, close to perfect. On a rare occasion, something goes wrong, but that might be in userspace, rather than kernel land. If the external display was being used with different to scaling than the internal screen, the scaling can sometimes go funny, possibly since the 1803 Windows update.

Hotplugging - in Linux, DO NOT F****** PULL OUT THE CORD. The amdgpu.ko driver clearly has not been updated with whatever is in the Windows driver (I assume the former driver would not have handled it, as opposed to the XConnect driver, which I assume are two different things). The amdgpu.ko will crash hard, sometimes completely taking down the system, and other times leave it in a semi-broken state. If you need to pull it, you need "echo 1 | sudo tee /sys/bus/pci/devices/0000\:08\:00.0/remove" with the bus number replaced with the one relevant to your system (lspci -vt command will help, or do "cat /sys/bus/pci/devices/0000\:08\:00.0/vendor" or "cat /sys/bus/pci/devices/0000\:08\:00.0/device" to check for vendor and device IDs matching your GPU first).

As for portable, there is the Sonnet Puck eGPU which is reasonably small. Otherwise we can wait for a tiny portable unit (GPU BGA straight onto the same PCB as the Thunderbolt controller) that gives lots of UHD-60Hz outputs and low-level acceleration, with a tiny footprint and powered off a USB-C laptop charger. You can get 15W out of the Thunderbolt bus power, but especially after the Thunderbolt controller eats into that, there is not a lot left for any significant performance.

The Aorus Gaming Box clearly is not a pocket solution - but if you do serious travelling, it is small enough to stash in your suitcase for use when you are at your destination. I carry it over my shoulder in the included bag to university occasionally.

As I have said in the past, from what I know, I believe it should be possible to define services other than Thunderbolt Networking between two computers, including granting control of a desktop's discrete GPU to a connected laptop. This would be achieved with the IOMMU and VT-d to send commands to the GPU with the same mechanism used for sharing the GPU with virtual machines. I hope Intel start getting creative with Thunderbolt.

Soon I might be reporting on turning a Thunderbolt 3 M.2 SSD enclosure (fits into palm) into a full-blown eGPU - except obviously it will become cumbersome lugging around the PSU and GPU hanging out of it.

I have never owned one with a dedicated GPU. Suddenly the weight and heat shoot up, and the power brick trebles in size. Plus, unless the laptop is one of those fifteen tonne desktop hardware in a laptop things, the GPU performance will still be disappointing. I prefer keeping it modular with eGPU, and am happy to wear the performance penalty of Thunderbolt because overall, it will still perform way better, leaving you with a light laptop for on the go.


ReplyQuote