It's a workstation card targeted specifically at inference. It's also their only late gen "AI GPU" arch available, baring the release of the D270 this thread is about.
I remember back in the day of AGP cards around 2002, you could use a 3d card on linux to render the grafix but use a different GPU for the actual output. I used XFree86 on linux with a voodoo banshee (or maybe was a riva tnt2) and a matrox mga200 for its sync-on-green support with my monitor to play games.
I know modern card architecture doesn't support this out of the box, but what is the actuall problem of forwarding a once-rendered frame to another card for output? Sureley DMA transfers PCIe->RAM->PCIe nowaday are fast enough to saturate 60fps at 4K?
Trivial to do this on Linux. I run my desktop on the on-chip Ryzen 9950X iGPU and I offload games to my nVidia dGPU.
I had a crazier setup in the past with the Intel i7-8809G APU: it had an AMD iGPU for desktop connected to the display, nVidia eGPU for games and the Intel iGPU for video encoding.
Of course there is additional latency due to frame copying, but I can’t notice it in practice.
I had that setup working back in the day with a Voodoo1 which had the pass-trough construction to take over full screen: only on Linux you could read the completed frames and render them in an X window. It was dog slow though.
While transfers have improved a lot the amount data needed for 4K60 with HDR is about 18Gbps. There's no way that doesn't have an impact.
We cooked up a setup where we had a PCI video card for X, and a separate Voodoo 1 or 2 and monitor for 3D (Mesa) rendering. I don't remember the details any more, but it was nice to not take out the desktop when someone borked up their OGL homework.
the voodoo1 worked differently as you looped through the video input. The voodoo banshee i mentioned was a separate 2d/3d card (it actually was 3DFx first true, combined 2d/3d card - not an accelerator).
I know. Voodoo 1 and 2 had the ugly VGA passthrough hack.
But the principle of reading VRAM from one card and copying it to another would remain the same I think.
There was a whole bunch of work on GPUs for databases before GPUs became hard to get, which slowed it down a bit. A lot of the columnar database performance gain is from vectorization. Now which direct pcie DMA to GPU from NVMe this is even more attractive. FPGA seems much more work than GPU.
My understanding is that FPGAs are targeted not because they are ideal for the task, but because they are commercially available. As in: the customers may rent a VM from a major cloud vendor with FPGAs attached.
Trying to grow a business that relies on bespoke hardware in the age of cloud monopoly is an uphill battle.
Its not clear, the IRS will presumably decide if, for example, Zuck gets an R&D tax deduction from his salary because he contributes to code, which no other large tech company has tried to claim.
So move the bar up to raidz3 or the equivalent? This adds cost, of course, but enhancing redundancy isn't free.
It was something I kept in-mind when I made the decision to use raidz2 for my own purposes: It tolerates two concurrent drive failures before local data loss happens, which I feel is acceptable for my purposes. raidz3 moves that tolerance to three concurrent drive failures.
I mean: What's the alternative for storing X amount of data? A greater number of relatively small drives? That's expensive in its own ways, too.
And adding complexity in that way tends to nosedive metrics like MTBF: If a system relies upon one widget and this system has an MTBF of n, then a system that relies upon two such widgets has an MTBF of n/2.
If the drives all have the same failure rate, then: A system with raidz2 and 10x 10TB drives will tend experience more disk failures than a system with raidz2 and 6x 20TB drives. Both systems can store ~80TB of data, but the one with 10TB drives has a worse ratio of redundancy and includes more parts that will eventually fail.
KISS, etc. :)
> and the longer it takes the more likely another drive will fail during that time.
You mean the old light-weight RAID-5-esque fear? A drive fails and redundancy drops to zero. So the failed drive is replaced or the hot spare is rotated in (or whatever), and the rebuild process begins. Another drive crashes during the rebuild because of the stress of actually-being-read and now the data on the array is presumed to be trash.
That process seems to actually work more like this: Old data that hasn't been read for years finally gets accessed (because RAID rebuild), and that's when some other drive starts reporting errors. But those errors were already there; they just weren't detected until it was way too late.
It doesn't really seem to work that way with filesystems like ZFS. The contents, whether old and stale or brand new, can (and should) be read routinely and checksummed to confirm integrity as part of a regularly-performed scrub.
The weak drives that can't stand to be read will be discovered during this read-only exercise, but they were already dead. We just didn't know it until we ran a scrub. So we scrub early, and often.
That's the same as with RAID, except: With RAID, the same disk still dies in the same way. We just don't know it was dead until a recovery is in-process. RAID, as commonly practiced, can therefore function as a problem-multiplier in ways that other systems can avoid.
reply