Intel announces Arc B-series "Battlemage" discrete graphics with Linux support • Hacker News Board

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

#491

Post by p1necone » Wed, Dec 04, 2024, 1:56 AM UTC

philistine wrote: post #158

giobox wrote: post #97

Earlier quoted context omitted.

For sure its been a sweet spot for a very long time for budget conscious gamers looking for best balance of price and frame rates, but 1440p optimized parts are nothing new. Both NVidia and AMD make parts that target 1440p display users too, and have done for years. Even previous Intel parts you can argue were tailored for 1080p/1440p use, given their comparative performance deficit at 4k etc. Assuming they retail at…

I'm baffled that PC gamers have decided that 1440p is the endgame for graphics. When I look at a 27-inch 1440p display, I see pixel edges everywhere. It's right at the edge of losing the visibility of individual pixels, since I can't perceive them at 27-inch 2160p, but not quite there yet for desktop distances. Time marches on, and I become ever more separated from gaming PC enthusiasts.

I think it's less that gamers have decided it's the "endgame" and more that current gen games at good framerates at 4k require significantly more money than 1440p does, and at least to my eyes just running at native 1440p on a 1440p monitor looks much better than running an internal resolution of 1440p upscaled to 4k, even with DLSS/FSR - so just upgrading piecemeal isn't really a desirable option.

Most people don't have enough disposable income to make spending that extra amount a reasonable tradeoff (and continuing to spend on upgrades to keep up with their monitor on new games).

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

#492

Post by pbronez » Wed, Dec 04, 2024, 1:58 AM UTC

semi-extrinsic wrote: post #214

Novosell wrote: post #192

Earlier quoted context omitted.

Gaming at 2160p is just too expensive still, imo. You gotta pay more for your monitor, GPU and PSU. Then if you want side monitors that match in resolution, you're paying more for those as well. You say PC gamers at the start of your comment and gaming PC enthusiasts at the end. These groups are not the same and I'd say the latter is largely doing ultrawide, 4k monitor or even 4k TV. According to steam, 56% are on 10…

I'm still using a 50" 1080p (plasma!) television in my living room. It's close to 15 years old now. I've seen newer and bigger TVs many times at my friends house, but it's just not better enough that I can be bothered to upgrade.

Classic Plasma TVs are no joke. I’ve got a 720p Plasma TV that still gets the job done.

If you’re ok with the resolution, then the only downside is significant power consumption and lack of HDR support.

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

#493

Post by Zandikar » Wed, Dec 04, 2024, 2:00 AM UTC

jsheard wrote: post #100

treprinum wrote: post #62

Earlier quoted context omitted.

M3/M4 Max MacBooks with 128GB RAM are already way better than an A6000 for very large local LLMs. So even if the GPU is as slow as the one in M3/M4 Max (<3070), and using some basic RAM like LPDDR5x it would still be way faster than anything from NVidia.

The M4 Max needs an enormous 512bit memory bus to extract enough bandwidth out of those LPDDR5x chips, while the GPUs that Intel just launched are 192/160bit and even flagships rarely exceed 384bit. They can't just slap more memory on the board, they would need to dedicate significantly more silicon area to memory IO and drive up the cost of the part, assuming their architecture would even scale that wide without hit…

> They can't just slap more memory on the board, they would need to dedicate significantly more silicon area to memory IO and drive up the cost of the part,

In the pedantic sense of just literally slapping more on existing boards? No, they might have one empty spot for an extra BGA VRAM chip, but not enough for the gain's we're talking about. But this is absolutely possible, trivially so for someone like Intel/AMD/NVidia, that has full control over the architectural and design process. Is it a switch they flip at the factory 3 days before shipping? No, obviously not. But if they intended this to be the case ~2 years ago when this was just a product on the drawing board? Absolutely. There is 0 technical/hardware/manufacturing reason they couldn't do this. And considering the "entry level" competitor product is the M4 Max which starts at at least $3,000 (for a 128GB equipped one), the margin on pricing more than exists to cover a few hundred extra in ram and extra overhead in higher-layer more populated PCB's.

The real impediment is what you landed on at the end there combined with the greater ecosystem not having support for it. Intel could drop a card that is, by all rights, far better performing hardware than a competing Nvidia GPU, but Nvidia's dominance in API's, CUDA, Networking, Fabric-switches (NVLink, mellanox, bluefield), etc etc for that past 10+ years and all of the skilled labor that is familiar with it would largely render a 128GB Arc GPU a dud on delivery, even if it was priced as a steal. Same thing happened with the Radeon VII. Killer compute card that no one used because while the card itself was phenomenal, the rest of the ecosystem just wasn't there.

Now, if intel committed to that card, and poured their considerable resources into that ecosystem, and continued to iterate on that card/family, then now we're talking, but yeah, you can't just 10X VRAM on a card that's currently a non-player in the GPGPU market and expect anyone in the industry to really give a damn. Raise an eyebrow or make a note to check back in a year? Sure. But raise the issue to get a greenlight on the corpo credit line? Fat chance.

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

#494

Post by bagels » Wed, Dec 04, 2024, 2:01 AM UTC

flockonus wrote: post #240

bagels wrote: post #178

Earlier quoted context omitted.

They could lose a lot of money?

They already do... google $INTC, stare in disbelief in the right side "Financials". At some point they should make a stand, that's the whole meta-topic of this thread.

Sorry, you're right, they could lose a lot more money.

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

#495

Post by anon373839 » Wed, Dec 04, 2024, 2:02 AM UTC

jsheard wrote: post #270

p1esk wrote: post #262

Earlier quoted context omitted.

Bleeding edge processes is what Intel specializes in. Unlike Apple, they don’t need TSMC. This should have been a huge advantage for Intel. Maybe that’s why Gelsinger got the boot.

Intel's foundry side has been floundering so hard that they've resorted to using TSMC themselves in an attempt to keep up with AMD. Their recently launched CPUs are a mix of Intel-made and TSMC-made chiplets, but the latter accounts for most of the die area.

I'm not certain this is quite as damning as it sounds. My understanding is that the foundry business was intentionally walled off from the product business, and that the latter wasn't going to be treated as a privileged customer.

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

#496

Post by anon373839 » Wed, Dec 04, 2024, 2:03 AM UTC

kevingadd wrote: post #95

treprinum wrote: post #62

Earlier quoted context omitted.

M3/M4 Max MacBooks with 128GB RAM are already way better than an A6000 for very large local LLMs. So even if the GPU is as slow as the one in M3/M4 Max (<3070), and using some basic RAM like LPDDR5x it would still be way faster than anything from NVidia.

Are you suggesting that Intel 'just' release a GPU at the same price point as an M4 Max SOC? And that there would be a large market for it if they did so? Seems like an extremely niche product that would be demanding to manufacture. The M4 Max makes sense because it's a complete system they can sell to Apple's price-insensitive audience, Intel doesn't have a captive market like that to sell bespoke LLM accelerator ca…

> release a GPU at the same price point as an M4 Max SOC

Why would it need to be introduced at Apple's high-margin pricing?

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

#497

Post by to11mtm » Wed, Dec 04, 2024, 2:07 AM UTC

treprinum wrote: post #26

Why don't they just release a basic GPU with 128GB RAM and eat NVidia's local generative AI lunch? The networking effect of all devs porting their LLMs etc. to that card would instantly put them as a major CUDA threat. But beancounters running the company would never get such an idea...

I've said this for a while...

I do think one challenge is, AFAIK with most GDDR5/6 there's a density issue that requires either larger memory bus paths or other additional complexity to support large sizes.

That said, the lack of even a 16GB variant is sus.

I'll take some copium in that maybe they're trying to solve the 'size' issue somehow and are just making sure whatever system they use isn't gonna be an i820 MTH debacle before they pull the trigger on announcing it.

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

#498

Post by AnthonyMouse » Wed, Dec 04, 2024, 2:08 AM UTC

jsheard wrote: post #100

treprinum wrote: post #62

Earlier quoted context omitted.

M3/M4 Max MacBooks with 128GB RAM are already way better than an A6000 for very large local LLMs. So even if the GPU is as slow as the one in M3/M4 Max (<3070), and using some basic RAM like LPDDR5x it would still be way faster than anything from NVidia.

The M4 Max needs an enormous 512bit memory bus to extract enough bandwidth out of those LPDDR5x chips, while the GPUs that Intel just launched are 192/160bit and even flagships rarely exceed 384bit. They can't just slap more memory on the board, they would need to dedicate significantly more silicon area to memory IO and drive up the cost of the part, assuming their architecture would even scale that wide without hit…

> They can't just slap more memory on the board

Why not? It doesn't have to be balanced. RAM is cheap. You would get an affordable card that can hold a large model and still do inference e.g. 4x faster than a CPU. The 128GB card doesn't have to do inference on a 128GB model as fast as a 16GB card does on a 16GB model, it can be slower than that and still faster than any cost-competitive alternative at that size.

The extra RAM also lets you do things like load a sparse mixture of experts model entirely into the GPU, which will perform well even on lower end GPUs with less bandwidth because you don't have to stream the whole model for each token, but you do need enough RAM for the whole model because you don't know ahead of time which parts you'll need.

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

#499

Post by dogcomplex » Wed, Dec 04, 2024, 2:12 AM UTC

ryao wrote: post #480

bayindirh wrote: post #264

Earlier quoted context omitted.

Disclosure: HPC admin who works with NIVIDA cards here. Because, no. It's not as simple as that. NVIDIA has a complete ecosystem now. They have cards. They have cards of cards (platforms), which they produce, validate and sell. They have NVLink crossbars and switches which connects these cards on their card of cards with very high speeds and low latency. For inter-server communication they have libraries which coordi…

I have been hacking on local llama 3 inference software (for the CPU, but I have been thinking about how I would port it to a GPU) and would like to do a rebuttal: https://github.com/ryao/llama3.c Inference workloads are easy to parallelize to N cards with minimal connectivity between them. The Nvlink crossbars and switches just are not needed. In particular, inference can be divided into two distinct phases, which a…

what kind of bandwidth/latency between GPUs would one need in that setup to not be bottlenecking? What you're describing sounds quite forgiving. Is it forgiving enough that we could potentially connect those GPUs over a LAN, or even a remote decentralized cloud of host computers?

From my understanding that's certainly possible to do without the latency hurting much with large batching between inference layers

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

#500

Post by superkuh » Wed, Dec 04, 2024, 2:12 AM UTC

m00x wrote: post #73

treprinum wrote: post #60

Earlier quoted context omitted.

llama.cpp and its derivatives say yes.

This is the most script kiddy comment I've seen in a while. llama.cpp is just inference, not training, and the CUDA backend is still the fastest one by far. No one is even close to matching CUDA on either training or inference. The closest is AMD with ROCm, but there's likely a decade of work to be done to be competitive.

You're not wrong, but technically llama.cpp does have training (both raw model and fine tuning). And it's been around for a long time. Back around the ggml->gguf switch I used llama.cpp to train a tiny 0.9B llama 1 through the early fast parts of the loss reduction on 3GB of IRC logs with 64 tokens of context over about a month. It eventually produced some gpt2-like IRC lines within it's very short context.

Would anyone choose llama.cpp's training tools to do serious work? No. Do they exist and work, yes.