Hacker News Reader

Comment by DeathArrow | Hacker News Reader

The revolution here is not that it is as good as the competition, but that it might have a much better price, leading to a much better price/performance ratio.

If Intel is patient to compete for lower grade GPUs for a few years without killing its GPU line, then we might see them competing for the top in the future. And the top is where the big money is. They'll also need a CUDA compatible API to stand a chance, but they have time.

The only thing that saved Intel until now is that Nvidia can't legally produce x86 CPUs, although they tried.

The more competition, the better.

View on HN

Apart from the software stack, Nvidia has invested a lot in the networking infrastructure for high bandwidth between gpu in a cluster. I think their acquisition of Mellanox might have helped here.

So competing on server grade gpu might be more difficult for intel.

The same intel that has been closely involved with ieee 802.3 development for decades and has had cutting edge NICs for datacenters ready to go in advance of new clause ratification? I'm sure they'll be fine.

You would be surprised.

Intel is nowhere in networking. IPU is dead last, they killed Fulcrum and Barefoot was a failure.

I would love to see Intel get somewhere but they are dead last among the major players.

Intel Gaudi2 is actually really good, better than A100s and cheaper (including interconnect, 2.15 Tb/s)

CUDA isn't that important any more.

The weird one was that Aurora at 2 exaflops using.. Intel Max?

> They'll also need a CUDA compatible API to stand a chance, but they have time.

Arc already has an extremely good value proposition: hardware AV1 encoding - so you can keep your existing GPU (let's face it: it's probably still more than fine) and augment it with a cheap Arc.

My A770 16GB originally intended for OpenVINO and OneAPI was repurposed into a workstation dedicated to AV1/VP9 encoding.

Slow developments are fine with me; it's a beautiful card.

They'll also need a CUDA compatible API to stand a chance, but they have time.

I guess CUDA compatible would be fine, but for myself, I'd buy their cards for compute workloads as long as they have some reasonable API regardless of whether it's CUDA or not. If they have something usable based on OpenCL, SYCL, whatever, they would have a shot at getting my money. Ideally that would also include then providing some support to make sure there are usable backends for PyTorch, Tensorflow, etc.

Ah well. Let's see if they can figure this out. Between Intel and AMD, you'd think somebody could step forward and give NVIDIA some serious competition.

Intel already has a working GPGPU stack, using oneAPI/SYCL.

They also have arguably pretty good OpenCL support, as well as downstream support for PyTorch and Tensorflow using their custom extensions https://github.com/intel/intel-extension-for-tensorflow and https://github.com/intel/intel-extension-for-pytorch which are actively developed and just recently brought up-to-date with upstream releases.

> And the top is where the big money is.

But the bottom is where volume and profits are. If the PC market has shown us anything, it’s that only producing for the top of the market gets you outcompeted.

I guess the top in the case might be the datacenter and stuff like A/H100 which have totally obscene margins compared to any consumer grade GPUs

Sure. But it’s a lot easier to pay back your investment in product development if you can amortise it over 50.000.000 GPUs instead of 50.000 GPUs. Same for ironing out the bugs in your software.

Getting paid a small yearly salary for every one of your products may look really nice but the size of the market makes it a precarious business.

Nvidia never needs to make a GPU again.

I wouldn't call that the top, that's an entirely different market.

Datacenter is considered a separate segment from gaming GPUs. So is automotive or AI.

Apple produced for the top and IBM for the masses. Look where both companies are today.

Apple certainly didn't produce for the top. The Mac Pro always was a niche product for media people.

It most certainly was priced for the top.

No, it was priced like a niche product for media people.

We obviously remember this time differently. Most people I knew had PCs, the few that had Macs had only one thing in common: Enough money to afford one.

The only other place where I saw a considerable number of Mac deployments was university. So portraying it as a niche product for media people has some truth in it but is in my opinion far from the whole truth.

They're not talking about today's apple, but the apple that sold a $10,000 Lisa.

IBM made very few products for the masses. Their platform took off because of clones like Compaq, HP, and Dell.

I advise every IBM naysayer to check their earnings, and all the beloved FOSS products that depend on IBM paychecks.

No, the profits are not in the volume. See the profitability vs. volume of iOS vs. Android. Ultimately, Nvidia charges a lot of mid-range cards because they don't have any competition. If Nvidia did have competition, they could lower the price of their midrange cards to stifle Intel while still profiting on the high end.

Midrange cards subsidize the higher end cards because they are often chips that were meant to be a tier or two higher but didn't pass QC at those performance levels. If you take a price hit on that, your entire fab/process is less profitable overall because you're not able to recover as much revenue from less than ideal yield.

Intel competing in the midrange is far from a nothingburger.

Did you forget a "/s" tag? Because that pretty much sounds like ten years of AMD history!

Intel can afford to throw much more money at the problem. AMD can't even get their drivers straight for years now, apart from the gaming use case. I really see a chance for Intel.

Unless things have improved recently, Intel‘s graphics drivers are not that great on Windows.

I really wish someone would give Nvidia some effective competition, but I just don’t see that being Intel.

Not sure if this has ever improved, back in the day Intel drivers were known to lie about their OpenGL capabilities, stating supported, when the feature was actually emulated in software.

If they only say their driver supports the feature, that technically is not lying, is it?

And what do you expect the driver to say instead?

Also, for graphics cards, I expect every feature requires some work from the driver. It’s not as if OpenGL is a hardware interface.

It is, because the drivers are only supposed to tell about what is actually supported on the hardware, via the capabilities queries.

A critical feature for game engines to actually decide what features to use, otherwise instead of 60 FPS, you might get single digit FPS.

So, educate me.

https://www.saschawillems.de/creations/opengl-hardware-capab... claims:

“The “OpenGL hardware capability viewer” (short “glCapsViewer) a multi-platform client-side application that reads out all important hardware capabilities of the current OpenGL-implementation present on your system”

Reading its source (https://github.com/SaschaWillems/glCapsViewer/blob/85ee6ab68...), I get the impression it does that by calling either of:

  - glGetIntegerv
  - glGetInteger64v
  - glGetIntegeri_v
  - glGetProgramivARB
  - glGetFloatv
  - glGetString

I think https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGet.... documents all those functions.

I don’t see any occurrence of ‘hardware’ on that page. Looking at the data collected by that tool (example: http://opengl.gpuinfo.org/displayreport.php?id=10016), and checking some of the capabilities listed, I can find all I looked at on that page (https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGet....), so I don’t think that tool uses other methods to obtain information (I didn’t read its full source code, though)

Also:

1) https://registry.khronos.org/OpenGL/specs/gl/glspec46.core.p... doesn’t mention ‘capabilities’, doesn’t mention ‘hardware’ much, and even says

“While an implementation of OpenGL may be hardware dependent, the Specification is independent of any specific hardware on which it is implemented. We are concerned with the state of graphics hardware only when it corresponds precisely to GL state.”

2) https://community.khronos.org/t/determining-hardware-opengl-... asks “I am trying to find a way for my program to determine (during run time) whether the graphics card supports OpenGL hardware acceleration, and how much RAM is installed on the graphics card”

and

https://community.khronos.org/t/determining-hardware-opengl-... replies: “Sorry, there’s no way in OpenGL to do what you want. You’ll just have to trust the driver to do the right thing.”

Of course, that last reply may be incorrect, but from what I found, I think it is correct.

So, what’s going on? Is the spec unclear about the glGet functions? Am I overlooking a call that _does_ return hardware info? As I said: educate me.

(And of course, “implemented in hardware” does not guarantee anything about performance.)

That is the thing Intel drivers did not do the right thing, versus what AMD, NVidia, and all now gone 3D vendors.

Regarding Arc, I agree, the drivers were a nightmare at release, but I'm fairly confident that was just a very rushed release because arc was already way behind schedule, and things will get better. The old UHD i915 drivers were (are) pretty solid, let's hope that's where Arc is aimed at, plus maybe all those gaming-focused bells and whistles as an optional feature.

Their drivers have improved enough that for the old OpenGL/DX9 games they are emulating it's able to just brute force it's way to acceptable performance since those games are really old usually.

I've had ATI/AMD cards for more years than not since 2004. And in my personal experience, I have maybe once had a driver issue on an X800. I know sometimes they struggle with new cards, but is it really still a thing?

I don't think they meant drivers with respect to gaming, but I could of misunderstood. I think it is more in the context of GPGPU.

graphics drivers are some of the most complex pieces of software running on any PC with lines of code running into millions easily. yes, driver issues are most definitely 'a thing' for all GPU manufacturers.

No even gaming I was constantly bombarded with driver crash and quitting the unsaved game

Why can't nvidia legally produce x86 chips?

Because you need a license to do so and Intel and AMD are loathe to give a license to would-be competitors.

I believe that the person you're replying to is referring to an attempt to produce x86 compatible processors that Nvidia undertook when they bought the license that Via owned.

IIRC that didn't go so well for Nvidia because the license didn't include new parts of the instruction set like the 64 bit instructions that AMD made in the mid 2000s and AMD wouldn't license them.

I do believe they've tried to circumvent the IP by implementing a translation layer like in Transmeta Crusoe, but Intel still threatened them with lawsuits.

Nvidia can't do a translation layer. Back around 2010 Intel and Nvidia were suing each other, the settlement agreement specifically said Nvidia wouldn't produce anything like that

Because you need a license and very few companies have one.

IP laws strike again. This is like saying someone can't make Lego compatible plastic bricks, or a Torx wrench.

Seem unreasonable to me. Even without a legal protection there is some degree of protection for the original creator something as complicated as a CPU.

Can Intel refuse to sell such license to nVidia or ask for much higher fees than other companies? If nVidia bought one of those companies, would that allow them to produce x86 chips at will?

the license doesn't transfer if the company is bought.

As far as I can remember they would have to buy AMD, VIA or IBM to get a X86 licence. That's just the beginning though as many later patents are also important, but they would likely also be already licensed by these companies (like AMD64 for one). If they could even use the license after a take over.... I don't know.

If AMD got taken over, then they would automatically lose their x86 license, as I believe it is a condition in their cross-licensing agreement. This is why I don't expect AMD to get bought in the near future.

That's correct yes, if AMD is bought then the cross-licensing deals terminate in both directions - i.e. Intel also lose access to the AMD patents.

It's a poison pill which means Intel themselves would be the only serious buyer.

Wouldn’t that mean Intel would really have to negotiate a new deal with whoever buys AMD since otherwise they couldn’t make any new cpus?

Technically AMD could still make ARM[1] or RISC-V based CPUs under a new owner.

[1] https://www.trustedreviews.com/news/amd-reveals-its-ready-to...

> It's a poison pill which means Intel themselves would be the only serious buyer.

Which market regulators would never allow. This is even bigger in terms of monopoly than Nvidia trying to buy arm.

> Can Intel refuse to sell such license to nVidia or ask for much higher fees than other companies?

Yes. There's no requirement to sell licenses to patents in general. Sometimes (not always) if a patent is included by a government in a standard that government will require the owning company to license it on "Fair, Reasonable, And Non-Discriminatory" terms (FRAND). Most patents, including the x86, x86_64, and various extension patents are not required to be licensed under FRAND terms.

AMD and Intel have a mutual licensing agreement. When Intel patents a new extension, they license it to AMD. Likewise when AMD patents a new extension, the license it to Intel. That's why Intel CPUs use the AMD x86_64 instruction set, AMD CPUs use the Intel AVX 512 vector instructions, etc.

AMD only got one for the 286 because IBM wanted a second source supply for their IBM PC's and things got murky when the i386 came around and AMD needed to compete.

There were some copying and I think they settled with AMD licensing the Intel FSB for $$$ (they switched to DEC Alpha bus protocol when the AMD Athlon 64 bit era came around).

With the AMD 64 they licensed it back to Intel when it became clear that Itanuim was dead as it was so slow and Microsoft forced Intel's hand by releasing a version for Windows Server.

The market is big enough for both.

> clear

Yep, but they're both willing to use the patents to keep other entrants out.

This is a redherring; Amazon and Apple are happier on ARM. Nvidia may have been blocked from buying them outright but are free to still make them.

Nvidia has produced arm cpus, eg for the Nintendo switch.

And Jetson

That is what I am saying; Nvidia don't need or want an x86 license. Thier best move is to dedicate all posible manufacturing to AI but a fallback stratagy might be to outcompete Intel in CPU. (They tried to buy Arm a year or so ago but it was stopped by the FTC.)

The problem with arm is that it is lacking in software support and optimizations compared to x86; it's only recently that there's proof of viability of arm cpus outside mobile through apple, and they also have the advantage of full stack integration and over a decade of experience building the best performing ARM cpus.

So there's a reason why they'd prefer x86. Hopefully they manage to release an ARM competitor for the desktop market, though with AI boom, it seems more likely that it will be a server focused on supporting their GPU lineup.

I think the tipping point was a few years ago. The are simply more Phones/tables/tvs/cars then the have ever been desktop PCs. They tend to be more latency sensitive and resource constrained. Therefor it is unsurprising that more optimization work has been invested in ARM then x86.

Graviton's certainly work out better for every program I have tried on AWS (obviously this is mainly because AWS set the price to ensure they do).

I mean the are complex x86 programs that run just as fast for longer on battery on a M1 then a comparable Dell/Lenovo.

I hope Intel keeps throwing more VRAM at their top cards than the competition. With the way current AI works that VRAM alone could make them attractive to try to develop for in the consumer/hobbyist space.

> Nvidia can't legally produce x86 CPUs, although they tried

What did they try? And when?

What became Denver CPUs were originally targeting x86.

Reply on news.ycombinator.com