Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

phoronix.com

Post reply on HN
Print view View original

551–560 of 722 posts

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

#551

Post by dmonitor »

robotnikman wrote: post #501
dmonitor wrote: post #394

Earlier quoted context omitted.

The major drawback for PC gaming at 4k that I never see mentioned is how much heat the panels generate. Many of them generate so much heat that rely on active cooling! I bought a pair of high refresh 4k displays and combined with the PC, they raised my room to an uncomfortable temperature. I returned them for other reasons (hard to justify not returning them when I got laid off a week after purchasing them), but I've…

>hard to justify not returning them when I got laid off a week after purchasing them Ouch, had something similar happen to me before when I bought a VR headset and had to return it. Wishing you the best on your job search!

That was earlier this year. I found a new job with a pay raise so it turned out alright. Still miss my old team though.. we've been scattered like straws in the wind.

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

#552

Post by ryao »

mandelken wrote: post #395
jsheard wrote: post #268

Earlier quoted context omitted.

The question is whether there's enough overall demand for a GPU architecture with 4x the VRAM of a 5090 but only about 1/3rd of the bandwidth. At that point it would only really be good for AI inferencing, so why not make specialized inferencing silicon instead?

I genuinely wonder why no one is doing this? Why can't I buy this specialized AI inference silicon with plenty of VRAM?

Intel and Qualcomm are doing this, although Intel uses HBM and their hardware is designed to do both inference and training while Qualcomm uses more conventional memory and their hardware is only designed do inference:

https://www.intel.com/content/www/us/en/products/details/pro...

https://www.qualcomm.com/news/onq/2023/11/introducing-qualco...

They did not put it into the PC parts supply chain for reasons known only to them. That said, it would be awesome if Intel made high memory variants of their Arc graphics cards for sale through the PC parts supply chains.

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

#553

Post by ryao »

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…

If their memory IO supports multiple ranks like the RTX 3090 (it used dual rank) did, they could do a new PCB layout and then add more memory chips to it. No additional silicon area would be necessary.

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

#554

Post by elabajaba »

AnthonyMouse wrote: post #498
jsheard wrote: post #100

Earlier quoted context omitted.

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…

To get 128GB of RAM on a GPU you'd need at least a 1024 bit bus. GDDR6x is 16Gbit 32 pins, so you'd need 64 GDDR6x chips, which good luck even trying to fit that around the GPU die since traces need to be the same length, and you want to keep them as short as possible. There's also a good chance you can't run a clamshell setup so you'd have to double the bus width to 2048 because 32 GDDR6x chips would kick off way too much heat to be cooled on the back of a GPU. Such a ridiculous setup would obviously be extremely expensive and would use way too much power.

A more sensible alternative would be going with HBM, except good luck getting any capacity for that since it's all being used for the extremely high margin data center GPUs. HBM is also extremely expensive both in terms of the cost of buying the chips and due to it's advanced packaging requirements.

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

#555

Post by wtallis »

jmb99 wrote: post #530
wtallis wrote: post #518

Earlier quoted context omitted.

Having four chips per channel is exactly why this is implausible. DDR5 can barely operate with four ranks per channel, at severely reduced speeds. Pulling that off with GDDR6 or GDDR7 is not something we can presume to be possible without specific evidence. The highest-density configurations possible for LPDDR5x are dual-rank and byte mode (one chip per 8 bits of the memory bus, so two chips ganged together to popula…

> DDR5 can barely operate with four ranks per channel, at severely reduced speeds. That is objectively false. See, for instance, V-color’s threadripper RAM[0]. If 96GB quad-rank modules @ 6000Mhz in octo-channel counts as “barely operating” maybe we have different definitions of operation requirements. As a side note, their quad-channel 3-rank RAM [1] hits 8000MHz, out of the box. Admittedly only 24GB modules, but st…

You linked to registered/buffered memory modules. I already addressed that case; it doesn't apply to LPDDR or GDDR.

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

#556

Post by ryao »

talldayo wrote: post #300
adventured wrote: post #213

Earlier quoted context omitted.

I do not misunderstand why Nvidia has a monopoly. You jumped drastically beyond anything I was discussing and incorrectly assumed ignorance on my part. I never said why I thought they had one. I never brought up matters of performance or software or moats at all. I matter of fact stated they had a monopoly, you assumed the rest. It's impossible to assail their monopoly without utilizing far lower prices, coming up un…

Nvidia's monopoly is pretty much detached from price at this point. That's the entire reason why they can charge insane margins - nobody cares! There is not a single business squaring Nvidia up with serious intent to take down CUDA. It's been this way for nearly two decades at this point, with not a single spark of hope to show for it. In the case of ARM, Office, Linux, Huawei, and ChromeOS, these were all actual alt…

It is cheaper to pay Nvidia than it is to roll your own solution and no one else is competitive. That is the reason Nvidia can charge so much per card.

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

#557

Post by ryao »

tw04 wrote: post #467
epistasis wrote: post #373

Earlier quoted context omitted.

Rather than tackling the entire market at once, they could start with one section and build from there. NVIDIA didn't get to where it was in a year, it took many strategic acquisitions. (All the networking and other HPC-specialized stuff I was buying a decade ago has seemingly been bought by NVIDIA). Start by being a "second vendor" for huge customers of NVIDIA that want to foster competition, as well as a few others…

Intel has already bought and killed everything they need to compete here. They seem incapable of sticking to any market that isn’t x86. Likely because when they were making those acquisitions they were drunk on margin and didn’t want to focus anywhere else.

Killing QLogic’s infiniband business after buying it was a major loss for the industry.

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

#558

Post by tristan957 »

ddtaylor wrote: post #297
Havoc wrote: 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…

The AMD driver has been great on my Framework 13, but the 6.10 series was completely busted. 6.11 worked fine. I can't remember a series where any of my Intel laptops didn't work for that long.

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

#559

Post by wtallis »

ryao wrote: post #524
wtallis wrote: post #518

Earlier quoted context omitted.

Having four chips per channel is exactly why this is implausible. DDR5 can barely operate with four ranks per channel, at severely reduced speeds. Pulling that off with GDDR6 or GDDR7 is not something we can presume to be possible without specific evidence. The highest-density configurations possible for LPDDR5x are dual-rank and byte mode (one chip per 8 bits of the memory bus, so two chips ganged together to popula…

In that case, we need a 512-bit memory bus to do this using the 32Gbit GDDR7 chips that should be on the market in the near future. This would be very expensive, but it should be possible, or do you see a reason why that cannot be done either? That said, I am not an electrical engineer (although I work alongside one and have had a minor role in picking low end components for custom PCBs), I think if Intel were to mak…

I think the goalposts may have shifted a bit, from why hasn't Intel made such a card to why is Intel not (publicly) working on such a card to be released in a year or two.

In terms of what would have been feasible for Intel to bring to market in 2024, the cheapest option for 128GB capacity would probably have been ~8.5Gb/s LPDDR5x on a 256-bit bus, but to at least match the bandwidth of the chip they just launched, it would have made more sense to use a 512-bit bus and bump the die size back up to ~half the reticle limit like their previous generation die with a 256-bit bus. So they would have had a quite slow but high-capacity GPU with a manufacturing cost equal to at least an RTX 4080, before adding in the cost of all that DRAM. And if they had started working on that chip as soon as LLaMA went public, they might have been able to deliver it by now.

It's no surprise at all that such a risky niche product did not emerge from a division of Intel that is lucky to not have been liquidated yet.

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

#560

Post by my123 »

CoastalCoder wrote: post #362
jsheard wrote: post #100

Earlier quoted context omitted.

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…

> The M4 Max needs an enormous 512bit memory bus to extract enough bandwidth out of those LPDDR5x chips Does M4 Max have 64-byte cache lines? If they can fetch or flush an entire cache line in a single memory-bus transaction, I wonder if that opens up any additional hardware / performance optimizations.

> Does M4 Max have 64-byte cache lines?

on the CPU side: 64 bytes at L1, 128 byte cachelines at L2

Post reply on HN