The Broadcom SoCs used on Pis still suck, and although this can probably be made to work, someone familiar with this codebase needs to care enough to fix the drivers to make it happen. It's probably quite doable for the open source drivers, but I wouldn't expect Nvidia's blob to work any time soon unless they take the time to fix it.
Not all PCIe root ports are equal. Some are, shall we say, less than amenable to devices more complicated than a USB controller.
Looking through the discussion here, there is some rather concerning stuff about DMA mappings (e.g. the thing with 64bit accesses not being supported). It's possible the Pi4 PCIe implementation is actually too broken to support these GPUs, though I haven't read through the whole thread in detail. It certainly looks pretty messy.
At this point I kinda have to wave the white flag on the driver issues because I'm not deep enough on the kernel / PCI spec side to be productive figuring out the holes on the Pi's 'messy' bus :)
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.
Just in case that's unknown to you or to other readers: It's really not true. Have a look at https://www.protondb.com/ - Linux is excellent for gaming, even AAA gaming. The PI processor just would be too weak either way, and not being x86 would prevent the games from running directly. Maybe that incompatibility and not having proprietary games compiled for ARM available is what you meant? That would need something like https://github.com/ptitSeb/box86, which actually seems to work way better than expected.
When they did run they ran great (testament to the hardware and the decent driver support), but that's what I mean when it's 'tough'. Not impossible but it's not like Windows, where you just click buy, wait for the game to download, and start playing.
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.
On those 5 games, 3 do not work at all, and Doom: Eternal keeps crashing every 15 minutes with the two latest builds.
I am sorry but the "You click on play and the game does run." is definitely not true, except if you are playing famous old games (mainly supported by Valve) like Portal, CS, ...
Thankfully, there is work being done and at least the situation with Battle Eye has improved in recent years.
I think the game itself was broken for couple of days for GNOME because of some library and if you want to play you have to switch to KDE.
Even if you want to game on linux, you have to install a ton of libraries, hope in wouldn't brick your system and then jump through the hoops all day and in case if something breaks you have to spent time debugging / reinstalling system instead of playing.
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.
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
On a higher level, anticheat is about locking down user behavior, confining it to acceptable corners of the machine. It is there to enforce the content creator's wish. It is just the latest incarnation of DRM. I expect that many in control of linux are quietly happy to hear that it doesn't work properly on linux systems.
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.
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.
On the other hand, the windows demo probably works, because wine still understands old windows apis and current linux apis.
It works about 90% of the time, but in that 10% there are probably a couple of games you're just not going to be able to get working. If you're serious about gaining, there's no reason to just not buy a Windows license. You can duelboot
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.
Windows 10 can't (at least not without a crack) because the DRM doesn't work anymore.
You can also run Linux inside of a VM on Windows.
Or you can even have a dedicated gaming PC and a cheap Linux PC. Windows Subsystem for Linux can give you the best of both worlds. I don't love Windows, honestly I think OSX is the best OS, but I can't run it on anything but a Mac.
>When 90% of your Steam library works anyway
Epic, EA, and Ubisoft don't even have clients for Linux.
That goes against some of my "get things done the cheapest way possible" philosophy, but it would be nice to be able to test things on hardware where it is known to _likely_ work.
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!
Off topic-ish, but maybe someone here would know... I have a 2013 macbook pro. It's still great for coding but recently I got into Blender, and now I understand why you might want an external GPU. Is that a possibility for such an old laptop? I couldn't find any definitive information on how to go about buying one, and setting it up.
More critically, at least in 2013, the docks you needed cost thousands of dollars—and made more sense to just get a separate desktop PC. I don't know if the situation has changed since then—there are more eGPUs out there but it's all for Thunderbolt 3. Thunderbolt 2 is more niche and thus may be more expensive.
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.
I was able to get a ThunderBolt 2 Mac to work with a Razor Core + Vega 56 combo, but YMMV. Away from computer so don’t remember exact year for my MBP, circa 2015 maybe?
Jetson Nanos are like $50 on Newegg. They are very cool. HN community should be all over this. I have used raspberry pis for robotics, but now I am seeing if I can switch and it seems to work. A Jetson Nano has (I believe) 128 cuda cores. If you want more, get a TX1 or a bigger board.
Seriously, trying to add an Nvidia care to a Pi is a dumb choice IMO. Show the Nano some love!
CPU speed is ordered pi3, nano, pi4, Xavier no. Memory bandwidth on the jetsons is much higher than on the pis.
And plus.. really I want to get people using these things so we can share code :)
On something like a MACCHIATObin or Honeycomb LX2K, AMD GPUs just work, even with pre-boot display in UEFI (thanks to EDK2 optionally including QEMU for this, it can just emulate x86 for the display driver it reads from the card). Well, the MCbin has a fun quirk with device enumeration, but actual operation of the device is perfect.