Restoring Intel's foundry lead starting with 18A was central to Pat's vision and he essentially staked his job on it. 18A is supposed to enter production next year but recent rumors is that it's broken.

I have next to zero knowledge of semiconductor fabrication, but “Continued Momentum” does sound like the kind of corporate PR-speak that means “people haven't heard from us in a while and there's not much to show”.

I also would never have realized the 20A process was canceled were it not for your comment since this press release has one of the most generous euphemisms I've ever heard for canceling a project:

“One of the benefits of our early success on Intel 18A is that it enables us to shift engineering resources from Intel 20A earlier than expected as we near completion of our five-nodes-in-four-years plan.”

And despite this total failure they spent many tens of on stock buybacks https://ycharts.com/companies/INTC/stock_buyback no less than ten billions in 2014 and in 2018-2021 over forty billions. That's an awful, awful lot of money to waste.

I think at this point no one believes Intel can deliver. So news or not..

Intel finally seem to have got their act together a bit with OneAPI but they've languished for years in this area.

At least for Intel, that is just not true. Intel's DPC++ is as open as it gets. It implements a Khronos standard (SYCL), most of the development is happening in public on GitHub, it's permissively licensed, it has a viable backend infrastructure (with implementations for both CUDA and HIP). There's also now a UXL foundation with the goal of creating an "open standard accelerator software ecosystem".

I decided that I have to start looking at Apple's AI docs

Apple will sell you a machine with 48GB of memory for thousands of dollars but plenty of people can't afford that, and even then the GPU is soldered so you can't just put four of them in one machine to get more performance and memory. The top end 40-core M4 GPUs only have performance comparable to a single A770, which is itself not even that fast of a discrete GPU.

For whatever reason, people just delete these tools from their minds, then claim Nvidia still has a monopoly on CUDA.

And yet still the popcorn gallery says "there no [realistic] alternative to CUDA." Methinks the real issue is that CUDA is the best software solution for Nvidia GPUs, and the alternative hardware vendors aren't seen as viable competitor for hardware reasons, and people attribute the failure to software failures.

Is there?

10 years ago, I burned about 6 months of project time slogging through AMD / OpenCL bugs before realizing that I was being an absolute idiot and that the green tax was far cheaper than the time I was wasting. If you asked AMD, they would tell you that OpenCL was ready for new applications and support was right around the corner for old applications. This was incorrect on both counts. Disastrously so, if you trusted them. I learned not to trust them. Over the years, they kept making the same false promises and failing to deliver, year after year, generation after generation of grad students and HPC experts, filling the industry with once-burned-twice-shy received wisdom.

When NVDA pumped and AMD didn't, presumably AMD could no longer deny the inadequacy of their offerings and launched an effort to fix their shit. Eventually I am sure it will bear fruit. But is their shit actually fixed? Keeping in mind that they have proven time and time and time and time again that they cannot be trusted to answer this question themselves?

80% margins won't last forever, but the trust deficit that needs to be crossed first shouldn't be understated.

It certainly seems like there's a "nobody ever got fired for buying nvidia" dynamic going on. We've seen this mentality repeatedly in other areas of the industry: that's why the phrase is a snowclone.

Eventually, someone is going to use non-nvidia GPU accelerators and get a big enough cost or performance win that industry attitudes will change.

On paper, yes. But how many of them actually work? Every couple of years AMD puts out a press release saying they're getting serious this time and will fully support their thing, and then a couple of people try it and it doesn't work (or maybe the basic hello world test works, but anything else is too buggy), and they give up.

Do you have experience with SYCL? My experience with OpenCL was that it's really a PITA to work with. The thing that CUDA makes nice is the direct and minimal exercise to start running GPGPU kernels. write the code, compile with nvcc, cudaed.

OpenCL had just a weird dance to perform to get a kernel running. Find the OpenCL device using a magic filesystem token. Ask the device politely if it wants to OpenCL. Send over the kernel string blob to compile. Run the kernel. A ton of ceremony and then you couldn't be guarenteed it'd work because the likes of AMD, Intel, or nVidia were all spotty on how well they'd support it.

SYCL seems promising but the ecosystem is a little intimidating. It does not seem (and I could be wrong here) that there is a defacto SYCL compiler. The goals of SYCL compilers are also fairly diverse.

No, I bought a Nvidia card and just use CUDA.

> OpenCL had just a weird dance to perform to get a kernel running...

Yeah but that entire list, if you step back and think big picture, probably isn't the problem. Programmers have a predictable response to that sort of silliness. Build a library over it & abstract it away. The sheer number of frameworks out there is awe-inspiring.

I gave up on OpenCL on AMD cards. It wasn't the long complex process that got me, it was the unavoidable crashes along the way. I suspect that is a more significant issue than I realised at the time (when I assumed it was just me) because it goes a long way to explain AMD's pariah-like status in the machine learning world. The situation is more one-sided than can be explained by just a well-optimised library. I've personally seen more success implementing machine learning frameworks on AMD CPUs than on AMD's GPUs, and that is a remarkable thing. Although I assume in 2024 the state of the game has changed a lot from when I was investigating the situation actively.

I don't think CUDA is the problem here, math libraries are commodity software that give a relatively marginal edge. The lack of CUDA is probably a symptom of deeper hardware problems once people stray off an explicitly graphical workflow. If the hardware worked to spec I expect someone would just build a non-optimised CUDA clone and we'd all move on. But AMD did build a CUDA clone and it didn't work for me at least - and the buzz suggests something is still going wrong for AMD's GPGPU efforts.

Impossible. GPGPU runtimes are too close to hardware, and the hardware is proprietary with many trade secrets. You need support from GPU vendors.

BTW, if you want reliable cross-vendor GPU, just use Direct3D 11 compute shaders. Modern videogames use a lot of compute, to the point that UE5 even renders triangle meshes with compute shaders. AMD hardware is totally fine, it’s the software ecosystem.

An x86 monopoly in the late 80s was a thing, but not now.

Today, there are sufficient competitive chip architectures with cross-compatible operating systems and virtualization that x86 does not represent control of the computing market in a manner that should prevent such a merger: ARM licensees, including the special case of Apple Silicon, Snapdragon, NVIDIA SOCs, RISC-V...

Windows, MacOS and Linux all run competitively on multiple non-x86 architectures.

Incorrect, we have an even greater lack of x86 vendors now than we did in the 80s. In the 80s you had Intel, and they licensed to AMD, Harris, NEC, TI, Chips & Technologies, and in the 90s we had IBM, Cyrix, VIA, National Semi, NexGen, and for a hot minute Transmeta. Even more smaller vendors.

Today making mass market x86 chips we have: Intel, AMD, and a handful of small embedded vendors selling designs from the Pentium days.

I believe what you meant was that x86 is not a monopoly thanks to other ISAs, but x86 itself is even more of a monopoly than ever.

C&T had some super-386 chips that apparently barely made it to market (38605DX), and the Cyrix 5x86 (most of a 6x86) is substantially different from the AMD one (which is just a 486 clock-quadrupled)

I think you're off by 20 years on this. In the 80s and early 90s we had reasonable competition from 68k, powerpc, and arm on desktops; and tons of competition in the server space (mips, sparc, power, alpha, pa-risc, edit: and vax!). It wasn't till the early 2000s that both the desktop/server space coalesced around x86.

It seems almost like the forces that are pushing against these long-term trends are focused more on trying to figure out how to saturate existing compute on the high-end, and using that to justify drives away from diversity and vertical integrated cost/price reduction. But there are, long-term, not as many users who need to host this technology as there are users of things like phones and computers who need the benefits the long-term trends provide.

Intel has acted somewhat as a rock in a river, and the rest of the world is finding ways around them after having been dammed up for a bit.

A lot of companies killed off their in-house architectures and hopped on the Itanium bandwagon. The main two exceptions were Sun and IBM.

Intel had just wiped the floor with x86 servers, all the old guard Unix vendors with their own chips were hurting. Then Intel makes the rounds with a glorious plan of how they were going to own the server landscape for a decade or more. So in various states of defeat and grief much of the industry followed them. Planned or not, the resulting rug pull really screwed them over. The organs that operated those lines of businesses were fully removed. It worked too well, I am going to say it was on accident.

Intel should have broken up its internal x86 hegemony a long time ago, which they have been trying since the day it was invented. Like the 6502, it was just too successful for its own good. Only x86 also built up the Vatican around itself.

> intended so they're not making an effective argument

To be fair I'm really struggling to somehow connect the "x86 monopoly in the late 80s" with the remainder of their comment (which certainly makes sense).

By that standard if we exclude mobile x86 has a much stronger monopoly these days than in 1985. Unless we exclude low end PCs like Apple II and Commodore 64.

In 1990 x86 had ~80%, Apple ~7%, Amiga ~4% (with the remainder going to lowend or niche PCs) so again not that different than today.

Sadly with the rise of laptops with soldered-in-everything, and the popularity of android/iphone/tablet devices, I share some of layer8's worries about the future of the relatively open PC architecture and hardware ecosystem.

We are really lucky that such a diverse and interoperable hardware platform like the PC exists. We should not discount it, and instead appreciate how important it is, and how unlikely for such a varied and high-performance platform to emerge again, should the PC platform die.

All the use cases, except gaming PC, have "less serious" solutions in Linux/ARM and Linux/RISCV today, where I would argue there is more interoperability and diversity. Those solutions get better and closer to "serious" x86 solutions every day.

Will they be roughly equivalent in price/performance in 5 years... only time will tell but I suspect x86 PC is the old way and it's on it's way out.

https://herecomesthemoon.net/2024/11/two-factions-of-cpp/

There are a lot of pre-compiled binaries floating about that are depended on by lots of enterprise software whose source code is long gone, and these are effectively locked to x86_64 chips until the cost of interoperability becomes greater than reverse engineering their non-trivial functionality.

"two factions" is only discussing source compatibility.

And then in the 2000s after AMD64 pretty much destroyed all competing architectures and then in the 2010s Intel itself effectively was almost a monopoly (outside of mobile) with AMD being on the verge of bankruptcy.

Could also be Intel and Micron. Then you end up with full stack devices with Intel CPUs and Micron RAM and storage, and the companies have partnered in the past.

Maybe they should follow AMD's lead and spin off the foundry business.

Samsung still has a fairly competitive process and could make x86 CPUs to put in their own tablets and laptops without having the OEM and Intel get into a fight about margins if they're the same company. And with the largest maker of Android devices putting x86 CPUs into them, you get an ecosystem built around it that you wouldn't when nobody is using them to begin with because Intel refuses to price competitively with ARM.

Wintel was a duopoly which had some power: Intel x86 has less dominance now partly because Windows has less dominance.

There are some wonderful papers on how game theory and monopoly plays out between Windows and Intel; and there's a great paper with analysis of why AMD struggled against the economic forces and why Microsoft preferred to team up with a dominant CPU manufacturer.

Part 1, combine branch predictor with the instruction trace cache to be able to detect workloads, have specific licenses for say Renderman, Oracle or CFD software.

Part 2, add a mesh network directly to the CPU, require time based signing keys to operate. Maybe every chip just has starlink included.

Part 3, In an BWM rent your seats move, the base CPU is just barely able to boot the OS, specific features can be unlocked with signed payloads. Using Shamir secrets so that Broadcom AND the cloud provider are both required for signing the feature request. One can rent AVX512, more last level cache, ECC, overclocking, underclocking.

The nice part about including radios in the CPUs directly means that updates can be applied without network connectivity and you can geofence your feature keys.

This last part we can petition the government to require as the grounds of being able to produce EAR regulated CPUs globally.

I think I'll just sell these patents to Myhrvold.

But didn't IBM do things like this for years with mainframes?

The best they could do with the GFX business is a public execution. We've been hearing about terrible Intel GFX for 15 years and how they are just on the cusp of making one that is bad (not terrible). Most people who've been following hardware think Intel and GFX is just an oxymoron. Wall Street might see some value in it, but the rest of us, no.

What does an OS need a GPU for?

My current laptop only has integrated Intel GPU. I'm not missing Nvidia, with its proprietary drivers, high power consumption, and corresponding extra heat and shorter battery life...

An 8K 32bpp framebuffer is ... omg 126MB for a single copy. I was going to argue that a software rasterizer running on vcache would be doable, but not for 8k.

For 4k, with 32MB per display buffer, it could be possible but heavy compositing will require going out to main memory. 1440p would be even better at only 15MB per display buffer.

For 1440p at 144Hz and 2TB/s (vcache max), best case is an overdraw of 984 frames/frame

I was doing a11y work for an application a few months back and got interested into the question of desktop screen sizes. I see all these ads for 4k and bigger monitors but they don't show up here

https://gs.statcounter.com/screen-resolution-stats/desktop/w...

And on the steam hardware survey I am seeing a little more than 5% with a big screen.

Myself I am swimming in old monitors and TV to the point where I am going to start putting Pepper's ghost machines in my windows. I think I want to buy a new TV, but I get a free old TV. I pick up monitors that are in the hallway and people are tripping on them and I take them home. Hypothetically I want a state-of-the-art monitor with HDR and wide gamut and all that but the way things are going I might never buy a TV or monitor again.

If the above-linked website uses data reported by the browser, I wonder how this scenario might be taken into consideration (or even if such a thing is possible)

A complex desktop web form with several pages, lots of combo boxes, repeating fields, etc. I cleaned up the WCAG AA issues and even the S, but the AAA requirement for click targets was out of scope but had me thinking that I wanted to make labels (say on a dropdown menu bar) as big as I reasonably could and that in turn got me thinking about how much space I had to work with on different resolution screens so I looked up those stats and tried to see what would fit in which constraints.

The PC I'm typing this on has two 27in 4k screens. I'm sitting so that I look at them from about 75cm away (that's 2.5 feet in weird units).

I archive most of my video files in 720p, because I genuinely don't see that big of a difference between even 720p and 1080p. It is definitely visible, but usually, it does not add much to the experience, considering that most videos today are produced to be watchable on smartphones and tablets just as much as cinema screens or huge TVs. I only make an exception here for "cinematic" content that was intended for the very big screen. That does not necessarily mean movies, but also certain YouTube videos, like "Timelapse of the Future": https://youtube.com/watch?v=uD4izuDMUQA - This one hits differently for me in 4K vs. just 1080p. Having to watch this in just 720p would be tragic, because its cinematography relies on 4K's ability to resolve very fine lines.

So why would I make a point to have both my screens be 4K? Because where else do you look at fine lines a lot? You're looking at it right now: Text. For any occupation that requires reading a lot of text (like programming!), 4K absolutely makes a difference. Even if I don't decrease the font size to get more text on screen at once, just having the outlines of the glyphs be sharper reduces eye strain in my experience.

“Ubuntu 7.10 is the first version of Ubuntu that ships with Compiz Fusion enabled by default on supported hardware. Compiz Fusion, which combines Compiz with certain components developed by the Beryl community, is a compositing window manager that adds a wide range of visual effects to Ubuntu's desktop environment. The default settings for Compiz enable basic effects—like window shadows and fading menus—that are subtle and unobtrusive. For more elaborate Compiz features, like wobbling windows, users can select the Extra option on the Visual Effects tab of the Appearance Preferences dialog.”

MacOS in 2000 was still old MacOS, with no compositing at all. The NeXT derived version of MacOS was still in beta, and I tried it back then, it was very rough. Even once OSX shipped in 2001, it was still software composited. Quartz Extreme implemented GPU compositing in 10.2, which shipped in 2002.

Windows finally got a composited desktop in Vista, released in 2007. It was GPU accelerated from day one.

https://en.m.wikipedia.org/wiki/Windows_Aero

It actually separates the OS from the GPU. Before WDDM your GFX device driver was the only software that could use GFX acceleration. After WDDM the GPU is another "processor" in your computer that can read and write to RAM and the application can use the GPU in user space any way it wants, and then the compositor can to the same (in user space) and in the end all the OS is managing communication with the GPU.

For that approach to work you need to have enough fill rate that you can redraw the screen several times per frame. Microsoft wanted to have enough they could afford some visual bling, but Intel didn't give to them.

Which is far more powerful than the ones that caused problems almost two decades ago.

As people noted, most of your GUI is being rendered by it. Every video you watch is accelerated by it, and if it has some compute support, some applications are using it for faster math at the background (mostly image editors, but who knows).

[1] https://www.engadget.com/2008-03-27-nvidia-drivers-responsib...

It wasn't fully WDDM compatible for a quite minor (overall) part, but the performance were awful anyway and lack of running in the full WDDM mode (ie Aero) also didn't help too, partly because running in Aero was faster.

not sure about it. i had friends with discrete GPUs at the time and they told me that vista was essentially a gpu-stress program rather than an OS.

at the same time, compiz/beryl on linux worked beautifully on intel integrated gpus, and were doing way cooler things than vista was doing at the time (cube desktops? windows bursting into flames when closed?).

I'm a bit sad that compiz/beryl is not as popular anymore (with all the crazy things it could do).

The problem with the "use the GPU in a SoC" proposition is everyone that makes the rest of a SoC also already has a GPU for it. Often better than what Intel can offer in terms of perf/die space or perf/watt. These SoC solutions tend to coalesce around tile based designs which keep memory bandwidth and power needs down compared to the traditional desktop IMR designs Intel has.