RosaicLabs, Atom RTL, and 32-Tile AMX: Trying to Piece Together a x86 Puzzle

Hello you fine Internet folks,

Today we are talking about one of the stranger x86 stories I have seen in a while. According to both SemiAccurate and Reuters, Intel is giving a new startup called RosaicLabs access to the register transfer language code for its Atom CPU technology. That is already a massive departure for a company that has historically guarded both its x86 license and CPU-core RTL very closely.

Two days before Reuters published its story, however, Phoronix spotted a very weird post on the Linux kernel mailing list. The post describes working x86 implementations with 16 and 32 Advanced Matrix Extension (AMX) tile registers, compared with eight tiles on Intel’s shipping AMX implementations. It was written by the same developer who said in October 2025 that a “corporate entity other than Intel/AMD” were already using its own x86 opcodes, CPUID range, and model-specific register range.

There are no public sources connecting Rosaic to that mystery x86 implementation. I want to be very clear about that from the start.

Still, an Atom-derived x86 core attached to a much larger matrix engine would make an awful lot of architectural sense for a startup staffed by Rivos veterans. Intel’s involvement would also answer the rather important question of how a new American company could legally build a custom x86 processor in the first place. So let’s dig into what we know, what the Linux posts actually say, and where the speculation begins.

Intel Lets Atom Out of the House

Both Reuters and SemiAccurate report that Intel has started providing Atom technology to RosaicLabs Inc., a startup incorporated in Delaware in May 2026. Rosaic is led by Amarjit Gill, a longtime semiconductor executive and investor who worked with current Intel CEO Lip-Bu Tan to assemble the founding team at Rivos. Reuters also says Rosaic’s team includes other Rivos veterans, including former Rivos finance chief Amit Parikh.

The reported arrangement goes well beyond an architectural license, with Intel reportedly supplying register transfer language, or RTL, code. RTL describes the logic and data movement inside a digital design in a form that can be simulated, verified, modified, and eventually synthesized into physical gates for a selected manufacturing process. In less technical terms, Intel is not merely giving Rosaic permission to execute x86 instructions. It is reportedly handing over the source-level description of an Atom CPU design.

That does not necessarily mean Rosaic gets every piece of an Intel processor. Reuters does not identify the Atom generation, the included cache and interconnect logic, the manufacturing process, or the contractual limits on modifying and shipping the design. Access to CPU-core RTL is also not the same as receiving a complete, tapeout-ready system-on-chip.

Even with those caveats, this is highly unusual. Intel has licensed x86 technology in limited circumstances before, but it has not operated like Arm, SiFive, or another merchant CPU-IP supplier. If this arrangement becomes a repeatable business model instead of a one-off deal, it would represent a fundamental change in how Intel monetizes its CPU designs. Intel has previously signaled that it wants to make more IP available through Intel Foundry, so this deal may be part of that broader strategy.

Rosaic itself remains almost completely in stealth. Reuters found no company website or LinkedIn page with any useful information, while an amended July filing reportedly gives the company room to raise a $10 million seed round. That is enough money to assemble a small early-stage team, but it is nowhere near enough to take a large, leading-edge processor from a blank sheet of paper to mass production.

Receiving an existing CPU core changes that equation by letting Rosaic spend its engineering budget on the parts that differentiate the product instead of rebuilding an x86 frontend, execution engine, memory-ordering machinery, privilege model, and software ecosystem from scratch.

The Other Mystery x86 Processor

The first useful clue appeared in October 2025. Longtime x86 researcher Christian Ludloff posted a message to the Linux kernel and GNU Binutils mailing lists saying he had been asked to relay information about opcode allocations already “in active use by a corporate entity other than Intel/AMD.”

The original Binutils post lists several reclaimed or otherwise unused opcode regions, an E000_xxxx CPUID range, and a matching E000_xxxx MSR range. Ludloff said these ranges were already in active use, implying that this was more than an academic proposal.

As Phoronix noted at the time, that raises two questions: Who was building the processor, and what legal right did it have to implement x86? Existing x86 companies such as VIA, Zhaoxin, or Hygon would be obvious candidates, but they already have public toolchain and kernel histories. Routing the notice through an independent expert while refusing to name the company would be an odd way for one of them to reserve instruction space.

Then on July 27, 2026 Ludloff posted again, this time the subject was an x86 implementation with more than the normal eight AMX tiles. The full mailing-list post documents implementations with 16 and 32 tile registers and explains how they can be fitted into mechanisms that already exist in the AMX architecture.

From Eight Tiles to 32

Intel’s current AMX programming model provides eight tile registers. Each register can hold up to 16 rows of 64 bytes, giving each tile 1 KB of capacity and the complete tile file 8 KB of architectural state. A separate Tile Matrix Multiply unit operates on those registers. Intel’s own AMX documentation describes this as palette 1.

Interestingly enough, the 64-byte TILECFG structure used to configure AMX already contains row and column fields for 16 tiles. Shipping implementations simply use the first eight. Ludloff says a 16-tile implementation can therefore use existing VEX instruction encodings, which can address TMM0 through TMM15, along with fields already present in the configuration structure.

Moving AMX to 32 tiles requires more work. The proposed AMX implementation uses EVEX encodings to address TMM0 through TMM31 and doubles TILECFG from 64 to 128 bytes so it can describe the extra registers. The post says existing CPUID mechanisms can already report more than eight tiles, the total tile-state size, and the width of TILECFG, so the implementation does not require a new feature flag.

In other words, the original AMX framework was more extensible than Intel’s shipping hardware. However, compatibility could become a problem because existing software often assumes that TILECFG is always 64 bytes and that the tile-data state is always 8 KB. Software with those assumptions would have to run in a degraded eight-tile mode. The post even proposes MSR controls to disable the additional registers when necessary.

For a 16-tile implementation, the tile file grows to as much as 16 KB per hardware thread. At 32 tiles, it reaches 32 KB, which is a large chunk of state for an operating system or hypervisor to save and restore, especially on a many-core processor. This points to the device containing the 16- or 32-tile AMX unit being much more focused on matrix multiplication than on general-purpose server tasks.

The mailing-list post refers to both AMX and its cross-vendor successor, AI Compute Extensions (ACE). AMD and Intel developed ACE through the x86 Ecosystem Advisory Group as a common matrix-acceleration target for future x86 CPUs.

The ACE whitepaper defines eight 512-bit-by-16-row tile registers plus a block-scale register. It also places ACE inside the existing AMX palette framework, allowing operating systems to reuse much of AMX’s state-management machinery. The mysterious design’s 16- and 32-tile modes therefore go beyond the baseline state defined by both AMX and ACE. They look like a vendor-specific scaling of the same programming model rather than merely a straightforward implementation of the new common standard.

Again, this points to a matrix-accelerator chip rather than a conventional general-purpose CPU.

Now the Real Question… Is This Rosaic?

Now we get to the fun part, because the circumstantial evidence is fairly compelling with both Reuters and SemiAccurate saying a previously unknown startup staffed by Rivos veterans is receiving Atom RTL from Intel. Days earlier, an unnamed corporate entity asked Ludloff to disclose details of a heavily extended x86 matrix implementation. Ludloff had previously relayed private x86 instruction, CPUID, and MSR allocations on behalf of an unknown corporation. An appropriately broad Intel agreement could explain how such a company gained both a functional x86 core and the legal right to ship it, although neither report discloses the actual licensing terms.

Atom also makes sense as a starting point. Intel’s Atom-derived cores are designed for better area and power efficiency than its large performance cores. Rosaic could use a relatively compact x86 core as the host and control processor, then spend most of its transistor and power budget on matrix execution, cache, memory bandwidth, and interconnect.

That would look less like a conventional Xeon competitor and more like an AI accelerator that happens to execute x86 natively. Instead of pairing a RISC-V control core with a giant data-parallel engine, as many accelerator startups do, Rosaic could pair an Atom-derived core with a giant AMX- or ACE-like engine. Ordinary x86 software would handle orchestration, while long-running kernels would use the expanded tile-register file.

However, there is a fly in the ointment. Rosaic was only incorporated in May 2026. The October 2025 opcode notice predates the company’s first filing by about seven months. That does not mean Rosaic could not have been working on a chip before those filings. However, in the July mailing-list post, Ludloff says that an implementation supporting 16 and 32 tiles “has been running at large scale for some time.” It is very unlikely that a startup receiving Atom RTL could have quietly designed, taped out, and deployed a new x86 core with an AMX implementation that is not directly compatible with current AMX code at “large scale” in that time.

There are ways to make the timeline fit, but each requires another assumption on top of the assumption that Rosaic is the company Ludloff is working with. The design could have started as an internal Intel project that was later handed off to Rosaic. “Running at large scale” could refer to simulation, emulation, or FPGA instances rather than production silicon. The unnamed corporation in 2025 could also have been a predecessor entity whose work is now being commercialized through Rosaic.

It is also entirely possible that the timing is a coincidence. The mailing-list posts never name Rosaic, and Reuters never mentions AMX, ACE, custom opcodes, or a matrix accelerator. Access to Atom RTL does not imply that Intel included AMX, because Intel’s shipping Atom-derived cores do not provide the per-core AMX engines found in its large Xeon cores. Rosaic would still need to design or obtain the accelerator, integrate it with the core, and make the enlarged architectural state work across the operating system and hypervisor.

Conclusion: Who Is Hiding Behind the Tiles?

The hard evidence leaves us with two separate stories. Intel is taking the extraordinary step of providing Atom RTL to Rosaic, while an unnamed company has an x86 AMX implementation with 16 and 32 tile registers that Ludloff says has been running at large scale. Connecting those stories produces a very compelling architecture, but it does not yet produce a confirmed product.

If “running at large scale” means deployed production silicon, Rosaic is difficult to reconcile with the timeline unless it inherited a mature design. If the phrase instead covers simulation, emulation, FPGA prototypes, or work performed by a predecessor organization, Rosaic becomes much more plausible. That single ambiguity is doing an awful lot of work.

Rosaic is not the only possible name. Zhaoxin is the obvious conventional candidate because it has a legal path to x86 through VIA and is actively building modern x86 processors, while Hygon has an AMD-derived x86 lineage, a growing data-center CPU business, and public ambitions around AI acceleration. A large tile file would fit either company’s server ambitions, but both already submit compiler and kernel support under their own names, making the anonymous relay difficult to explain; neither company’s public software support exposes anything resembling 16- or 32-tile AMX.

A hyperscaler’s internal chip program may fit the “large scale” wording better: Google, Meta, Microsoft, and Amazon have the money, deployment volume, and custom-silicon teams needed to build such a device. Google is tempting because Ludloff previously worked there, while Meta has the Rivos connection, but that is extremely thin circumstantial evidence and none has publicly disclosed the x86 license or Intel-core agreement such a design would appear to require. The fun wildcard is the old Centaur/VIA lineage, because Centaur already built an x86 server SoC with a large integrated NCORE AI coprocessor. Most of that team moved to Intel years ago, and there is no evidence NCORE evolved into this mysterious AMX implementation, but it shows that pairing a third-party x86 core with a giant matrix engine is not an entirely new idea.

My best guess is that the mystery design belongs to either an Intel-backed spinout or a confidential custom-silicon customer, with Rosaic remaining the most interesting named candidate. Zhaoxin and Hygon have clearer routes to implementing AMX, while a hyperscaler better fits the claim of large-scale operation. Every option solves one part of the puzzle and creates another.

For now, the most important detail is not whether the mystery company is Rosaic. It is that Intel appears willing to let outside companies build around its CPU RTL at the same time that someone outside Intel and AMD is publicly reserving substantial new x86 architectural space for matrix compute. Even if the two stories are unrelated, both point toward a much stranger and more open x86 ecosystem than the one we are used to.