Tried Nvidia’s GTX 1080 – still no external GPU on a Pi

I spent a night looking through the radeon driver and register documentation, and it seems to fall back on sane defaults without being able to access IO space, it just prints a nasty gram. All of the expected IO space is mirrored in the MMIO space and the VBIOS code will just use that as a fallback pathway just fine.

One sort of cheap way to get a sense of what's actually going on (at least way cheaper than a PCIe protocol analyzer) might be to put your hands on one of the USB3382 cards (the poor man's PCIe protocol analyzer for those who aren't that comfortable with FPGAs). Those are really neat soft PCIe devices that bridge the PCIe transactions over USB3 to another host computer and can do things like emulate other devices or send arbitrary TLPs. There's some hacker con talks about using them to attack systems by using their DMA TLPs as a read/write primitive. Using that to either bridge to a card on the host computer and tap the PCIe bus, or send your own TLPs to verify that stuff like 64 bit transactions are actually a problem and not a red herring. You can use a FPGA for the same thing pretty easily, but a USB3382 might be a lot closer to the skill set that you feel comfortable with.

With 1 out of 5 you were extremely unlucky. For the most part proton works exactly like described: You click on play and the game does run. In the other cases where there are fixes to be applied that's most of the time just setting a simple start parameter directly in Steam.

You also should consider that on Windows in practice there are many issues, ranging from drivers and OS updates critically breaking performance (happened just now again), middleware stopping to work, and many older games that run perfectly fine on Linux not running at all on Windows anymore. It always depends on your game selection of course, but I for example also removed my dual boot Windows installation to exclusively game on Linux a few years ago now because it got way too annoying dealing with all the breakage and incompatibility on that platform.

Can you name the games?

So your daily driver is Windows pc already?

For development + video editing + gaming, are you gonna make a Windows vs Mac comparison video soon?

Linking some comments from your pi vs mac thread over here

1. https://news.ycombinator.com/item?id=23503762

2. https://news.ycombinator.com/item?id=23503481

The problem with Proton is that some things cannot be bypassed. I recently downloaded a multiplayer game that uses Xigncode (anti cheat software) and it simply doesn't work with proton. I know the game works flawlessly because I played a version of it from a different publisher that didn't use anti cheat software (it's not a competitive game).

> Eh... the problem is even with Proton it's extra work and sometimes not pleasant try to keep games running natively in Linux.

I flipped one switch in settings and restarted Steam. I install Windows-only games in Linux just like I do in Windows within Steam.

How is that extra work?

The vast majority of the games now work in Proton without any significant performance differences. I actually have an inverse anecdote to yours: Two games I recently tried to run in Windows 10 wouldn't run, but ran flawlessly in Proton/Steam/Linux despite being newer Windows only games.

That's the nature of all desktop computing on Linux. Either way, Linux is very much capable of AAA gaming, though the setup can be a little rougher on the Linux side of things. That being said, Steam's Proton has made it so that 90% of my games just run out of the box.

That's exactly why it's excellent.

If the goals of future game development are pro-consumer and developer-centric like platform agnosticism (or, preventing artificial platform monopolies like, eg- GFWL) and simplifying development, then we're doing way better than good enough.

We've learned over the past decade that publishing Linux native games isn't as feasible or valuable because supporting them smothers smaller and independent developers in distro-specific bugs, robbing them of time and resources they could be putting towards developing content, spending time with family, or planning their next projects. There's no reason to publish natively as long as you can develop with Proton/SteamPlay in mind, and instead of every indie dev needing to fumble through learning Linux support, it shifts the burden to specialized developers (like Valve) who can more effectively contribute to Proton instead.

Linux native support is almost an anti-criteria for me today, because I'd much rather troubleshoot a known-working build with all the features enabled (eg- multiplayer works with other "Windows" versions) instead of a build that lags behind in updates and may never be more than a perpetual WIP. Proton and tools like DXVK and D3DVK that can be ported anywhere exist to circumvent that, and that's pretty amazing when you think about it.

DXVK is just Direct X for Linux. It's just a library the same way libc is a library. Why would I care about what libraries my games use?

The problem isn't the compatibility, it's the reliability. You can't expect every game to work under Proton. It's always a gamble.

If there was a guarantee that every game works then it would be indistinguishable from excellent first party support. The reason why it's only good enough is that you have to sacrifice the titles that don't work.

Wine has gotten incredibly good over the past few years.

A major problem with that is that you practically need an emulation layer to run old Linux games. Try running the sid meier alpha centauri linux demo... Chances are it won't work because distributions have moved on from where they were.

On the other hand, the windows demo probably works, because wine still understands old windows apis and current linux apis.

30% of my Steam Library runs on Ubuntu 20.10 out of the box. I was shocked at the advancements made on Linux in the last 2 years. It really was desperate before that but there are decent options now at least.

It's not like 100% of games someone wants to play will work on Windows. Back when GTA 4 was relatively new I got it as a present. Took months until the Games for Windows Live DRM permitted me to run it, and even then only offline. Another example - that's a while ago, but that's when I realized the compatibility you get from Linux: I tried to play the original Anno 1602 and of course booted up Windows, and it just was impossible at that time to get it to run. Annoyed me enough to finally try it on Linux, with the regular wine, where it just worked.

Sure, you can always dualboot, but it's honestly a hassle after a while. Windows updates every time you boot it up (when it's seldom enough), Grub breaking occasionally, and when you are used to Linux modern Windows is just excruciating user hostile. When 90% of your Steam library works anyway it's just not worth it.

Jetson Nano has PCIe, exposed through the M.2 slot. Far more bandwidth than an RPi too.

I'm actually stacking Raspberry 2/4 as servers with 1TB SanDisk (slow but with enough distribution fast enough)...

But right now I'm investing in Mini-ITX Atom 8/16-core servers (25/32W) with passively cooled cases (Streacom) and 8x64GB SATA SSDs from 2011 (50nm that last 100.000 writes per bit for 2W per drive = 18W total)!

So the Raspberries are an option if power becomes unstable/expensive, gonna have lead-acid backup and Gb/s fiber in appartement/summer house for 100% read uptime redundancy!

The other issue is drivers. Nvidia is definitely out since the drivers have not been updated in many years.

Thunderbolt 2, if supported natively by the hardware and using an external monitor, might actually be enough in practice. I used to game on rMBP 2015 with a GTX 1080 in a TB2-connected eGPU and it didn't even saturate the link, so when I upgraded to an iMac with TB3 the performance was pretty much identical.

The rule of thumb is: use an external monitor and the highest resolution possible. Sending control commands one way consumes much less bandwidth if you don't need to send whole images back down the link, and the high resolution and quality is to make the GPU the bottleneck, not the TB2 link.

It's possible to use at least some TB3 eGPUs with TB2 and adapters, it's not officially supported by Apple on macOS though. They are still insanely expensive in my opinion for what's basically a case, small PSU and PCI-E to TB3. The cheapest ones that can take most cards are around $300 and usually have some downside. I considered it for my Mac Mini but in the end it just made more sense to sell the Mini and buy a desktop PC with space for a real GPU, more storage, faster processor, etc. I mean my case, power supply and motherboard was less than the price of a Razer Core X...

Right, but the nano is cheap and you can get the TX1, TX is you need more power. There is no world where that is not a cheaper and more versatile solution than hooking up Pi to like a 1080 graphics card.

And plus.. really I want to get people using these things so we can share code :)

^ This. I'm working around the edges of the SoC in the Pi, the BCM2711, which has some implementation quirks.