Live data from Hacker News

Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

phoronix.com

631–640 of 722 posts

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#631

Earlier quoted context omitted.

Why do you need two DP cables? Is there not enough bandwidth in a single one? I use a 4k@60 display, which is the maximum my cheap Anker USB-C Hub can manage.

I'm not sure, but there's an in-depth exploration of the monitor here: https://tftcentral.co.uk/reviews/acer_nitro_xv273k.htm Reddit also seems to have some people who have managed to get 144 with FreeSync, but I've only managed 120. Funnily enough while I was typing this Netflix caused both my monitors to blackscreen (some sort of NVIDIA reset I think) and then come back. It's not totally stable!

Had the same issue at 4k 60fps, it mostly worked but the screen flashed black from time to time. I used the thickest cable I had lying around and it has worked fine since.

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#632
post #624

Earlier quoted context omitted.

I think all the people saying "just use a CPU" massively underestimate the speed difference between current CPUs and current GPUs. There's like four orders of magnitude. It's not even in the same zip code. Say you have a 64-core CPU at 2Ghz with 512-bit 1-cycle FP16 instructions. That gives you 32 ops per cycle, 2048 across the entire package, so 4TFlops. My 7900 XTX does 120TFlops. To match that, you would need to s…

Usually, you can do 2 AVX-512 operations per cycle and using FMADD (fused multiply-add) instructions, you can do two floating point operations for the price of one. That would be 128 operations per cycle per core. The result would be 16TFlops on a 2GHz 64 core CPU, not 4 TFlops. This would give a 1 order of magnitude difference, rather than 4 orders of magnitude. For inference, prompt processing is compute intensive,…

That's fair. On the other hand, there's like exactly one CPU with FP16 AVX512 anyways, and 64core aren't exactly commonplace either. And even with all those advantages, using a datacenter CPU, you're still a factor of 10 off from a GPU that isn't even consumer top-end. With a normal processor, say 16 cores, 16 float ops, even with fused ops and dispatching two ops per cycle you're still only at 2T and ~50x. In consumer spaces, I'm more optimistic about dedicated coprocessors. Maybe even iTPU?

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#633

Earlier quoted context omitted.

AMD has a 192GB GPU. I don’t see them eating NVidia’s lunch with it.

They are charging as much as Nvidia for it. Now imagine they offered such a card for $2k. Would that allow them to eat Nvidia's lunch?

AMD would be selling it at a loss. Given that HBM costs 3x the price of desktop DRAM and a 192GB kit costs $600 at Newegg, the memory alone would cost 90% of the price. The GPU die, PCB, power circuitry, etc likely costs more than $200 to make.

This does not consider that the board of directors would crucify Lisa Su if she authorized the use of HBM on a consumer product while it is supply constrained and there is enterprise demand for products using it. AMD can only get a limited amount of it and what they do get is not enough for enterprise demand where AMD has extremely healthy margins.

Even if they by some miracle turned a profit on a $2000 consumer card with 192GB HBM, every sale would have a massive opportunity cost and effectively would be a loss in the eyes of the board of directors.

Meanwhile, Nvidia would be unaffected because AMD could not produce very many of these.

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#634
post #331

Earlier quoted context omitted.

What if they put 8 identical GPUs in the package, each with 1/8 the memory? Would that be a useful configuration for a modern LLM?

GPU inference is always a balancing act, trying to avoid bottlenecks on memory bandwidth (loading data from the GPU's global memory/VRAM to the much smaller internal shared memory, where it can be used for calculations) and compute (once the values are loaded). Splitting the model up between several GPUs would add a third much worse bottleneck – memory bandwidth between the GPUs. No matter how well you connect them,…

At least for LLMs and transformers this isn't relevant. Having 8x the chips and 8x the memory bandwidth is always better. Interchip communication for matrix multiplication against a constant left matrix with a tiny right matrix isn't bandwidth bound, only latency bound.

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#635
post #9

I put an a360 Card into an old machine I turned into a plex server. It turned it into a transcoding powerhouse. I can do multiple indepdent streams now without it skipping a beat. Price-performance ratio was off the chart

My 7950X3Ds GPU does 4k HDR (33Mb/s) to 1080p at 40fps (proxmox, jellyfin). If these GPUs would support SR-IOV I would grab one for transcoding and GPU accelerated remote desktop. Untouched video (star wars 8) 4k HDR (60Mb/s) to 1080p at 28fps

[deleted]

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#637

Earlier quoted context omitted.

> "Just add more RAM" doesn't work the way you wish it could. Re: Tomasulo's algorithm the other day: https://news.ycombinator.com/item?id=42231284 Cerebras WSE-3 has 44 GB of on-chip SRAM per chip and it's faster than HBM. https://news.ycombinator.com/item?id=41702789#41706409 Intel has HBM2e off-chip RAM in Xeon CPU Max series and GPU Max; What is the difference between DDR, HBM, and Cerebras' 44GB of on-chip SRAM?

How do architectural bottlenecks due to modified Von Neumann architectures' debuggable instruction pipelines limit computational performance when scaling to larger amounts of off-chip RAM? Tomasulo's algorithm also centralizes on a common data bus (the CPU-RAM data bus) which is a bottleneck that must scale with the amount of RAM. Can in-RAM computation solve for error correction without redundant computation and con…

For whatever reason Hynix hasn't turned their PIM into a usable product. LPDDR based PIM is insanely effective for inference. I can't stress this enough. An NPU+LPDDR6 PIM would kill GPUs for inference.

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#638
post #453

I wonder how many transistors it has and what the chip size it is. For power, it's 190W compared to 4060's 115 W. EDIT: from [1]: B580 has 21.7 billion transistors at 406 mm² die area, compared to 4060's 18.9 billion and 146 mm². That's a big die. [1] https://www.techpowerup.com/gpu-specs/arc-b580.c4244

Those numbers are identical to the A770, and don't match the numbers from the preview[0], so I think that's a copy paste error. If we use the numbers from the preview: | |Arc A770|Arc B580|RTX 4060| |--------|--------|--------|--------| |Process |N6 |N5 |N5 | |Die Size|406mm^2 |272mm^2 |159mm^2 | |Trans. |21.7B |19.6B |18.9B | |Mem Bus |256 bit |192 bit |128 bit | |TDP |225W |190W |115W | |~Perf |90% |110% |100% | In…

Those numbers suggest that they have caught Nvidia in performance per transistor. As for the die area being larger, I suspect that the larger memory bus might be partly responsible. The transistors used for IO stopped shrinking on new nodes a while ago, so they use plenty of die area.

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#639
post #211

Who is the target audience for this? Well informed gamers know Intel's discrete GPU is hanging by a thread, so they're not hoping on that bandwagon. Too small for ML. The only people really happy seem to be the ones buying it for transcoding and I can't imagine there is a huge market of people going "I need to go buy a card for AV1 encoding".

Intel has earned a lot of credit in the Linux space. Nvidia is trash tier in terms of support and only recently making serious steps to actually support the platform. AMD went all in nearly a decade ago and it's working pretty well for them. They are mostly caught up to being Intel grade support in the kernel. Meanwhile, Intel has been doing this since I was in college. I was running the i915 driver in Ubuntu 20 year…

This is repeated often, but I have had very good support from Nvidia on Linux over the years. AMD on the other hand gives lousy support. File a bug report about a problem and expect to be ignored, especially if it has anything to do with emulation. Intel’s Linux support on the other hand has been very good for me too.

Re: Intel announces Arc B-series "Battlemage" discrete graphics with Linux support

#640
post #448

Earlier quoted context omitted.

I wonder at that point you'd just be better served by CPU with 4 channels of RAM. If my math is right 4 channels of DDR5-8000 would get you 256GB/s. Not as much bandwidth as a typical discrete GPU, but it would be trivial to get many hundreds of GB of RAM and would be expandable. Unfortunately I don't think either Intel or AMD makes a CPU that supports quad channel RAM at a decent price.

I think all the people saying "just use a CPU" massively underestimate the speed difference between current CPUs and current GPUs. There's like four orders of magnitude. It's not even in the same zip code. Say you have a 64-core CPU at 2Ghz with 512-bit 1-cycle FP16 instructions. That gives you 32 ops per cycle, 2048 across the entire package, so 4TFlops. My 7900 XTX does 120TFlops. To match that, you would need to s…

This is only relevant for the flash attention part of the transformer, but a NPU is an equally suitable replacement for a GPU for flash attention.

Once you have offloaded flash attention, you're back to GEMV having a memory bottleneck. GEMV does a single multiplication and addition per parameter. You can add as many EXAFLOPs as you want, it won't get faster than your memory.

Post reply on HN