I'm trying to throw together an ultra budget system, and the last bit I need is a gpu.

compared to nvidia/intel, the intel GPU's are cheap, and am wondering if its a good idea to buy one right now since the rumor that intels GPU line may be dead.

Intel just announced the D270. The URL says d-series and the page says Intel GPU D-series. Does that mean we are already on Druid or is it just a weird naming by Intel?

Update on running PrismML's ternary Bonsai 2 27B on the B580. The video is real time in llama.cpp's web UI: it writes a full snake game (about 3,800 tokens of HTML, CSS and JS) in 34 seconds, then the same tab runs the exact code it wrote. Temperature 0, 128K context. The typing and the gameplay are automated, and the generation is unedited.

v0.10.1 is out: https://github.com/Torchit1/llama.cpp/releases/tag/arc-b580-v0.10.1 (Windows zip included)

With the public model on a B580 at 128K context: about 85 t/s writing code with MTP, 79 t/s in normal chat, 82 t/s with 48K tokens of history and 89 t/s at 115K. Plain generation 48.6 t/s, prompt reading ~1,480 t/s. That's 12-15% up on v0.8, same outputs token for token.

PrismML now ship their own SYCL build too. Same card, model and flags: chat with MTP 79.8 vs 58.0 t/s, plain generation 48.6 vs 31.0, and 46.4 vs 16.4 at 16K context.

The video is from my own server, which also uses a draft head I trained myself, so expect a few % less with the public one.

Needs an Xe2 GPU for the fast paths (Arc B-series, Lunar Lake). Numbers from other Arc cards very welcome: https://github.com/Torchit1/llama.cpp/discussions/1

I've also ported the q4_0 attention kernel onto upstream llama.cpp so it can benefit other models on Arc, not just Bonsai.

P.S. I know a snake game isn't a proper benchmark, it's just a bit of fun for Arc users.

This entire test was done thanks to the following github https://github.com/Uzbekunknown/dlss-nr-on-intel/releases/tag/v0.0.1.1

Specs: Windows 11 Intel arc b570 asrock challenger OC 10gb GPU R5 4500 16gb ram ddr4 2666 ssd nvme 1tb Mafia 3: 1360x768 without DLSS5 reaches 98 fps.

With DLSS5 it is basically a slideshow at 11 fps, 20 or 25 can be achieved if the resolution is changed to 1280x720 I think it is a great advance, the GPU is in use at 50% the same as the processor. ram memory at 76%

https://reddit.com/link/1x4gjek/video/j7p2lsc784vh1/player

Whats going on guys this seems like the appropriate group to ask so im going to dive right in.

Im a competitive CoD player I previously had a

9060xt 16gb

7700x

32gbs 6000mt

I had to sell it due to a large vehicle repair. This system did exactly what i needed it to consistent 240fps 1080p low settings. im currently shopping for parts to build a new am4 system strictly due to the am5 pricing right now and the b580 has caught my attention I am interested in it due to the fact it has 12gbs of vram because I want to do some light 1440p gaming (not cod) and I dont care about fps numbers or having to use frame gen outside of cod. Im not expecting to hit a consistent 240fps but I would like to be around 180-200 is it safe to assume the b580 can get me there with upscaling (not framegen) ? Ive watched benchmark videos but results are so varied i cant decide if i want to pull the trigger on it. Build specs below:

Ryzen 5 5600x

Intel arc b580

32gbs 3200mt

B550m

Any input would be greatly appreciated i would like to make a decision by end of the week. Thank you

When playing the witcher 3 remastered in 1080p the gpu power consumption doesn't exceed 110-120w, giving a framerate lower than expected, if i lower my res to at least 1600x900 the power comsumption goes to 130-140w (what it should be) and the game runs fine, TW3 is the only game i have experienced this so far. Have anyone else suffered from something similar?

Highlights:

Intel® Game On Driver support on Intel® Arc™ B-series, A-series Graphics GPUs and Intel® Core™ Ultra with built-in

Intel® Arc™ GPUs for:

• Call of Duty®: Modern Warfare® 4*
• Planet Zoo 2*

Game performance improvements on Intel® Core™ Ultra Series 3 with built-in Intel® Arc™ GPUs versus Intel® 31.0.101.9034 software driver for:

• F1® 25* (DX12)
  • Up to 5% average FPS uplift at 1080p with Medium settings

Game performance improvements on Intel® Arc™ B-series Graphics GPUs versus Intel® 31.0.101.9034 software driver for:

• Avatar: Frontiers of Pandora™ * (DX12)
  • Up to 6% average FPS uplift at 1440p with High settings
• MONSTER HUNTER RISE* (DX12)
  • Up to 6% average FPS uplift at 1440p with High settings

Game performance improvements on Intel® Core™ Ultra Series 2 with built-in Intel® Arc™ GPUs versus Intel® 31.0.101.9034 software driver for:

• Assassin’s Creed Shadows* (DX12)
  • Up to 18% average FPS uplift at 1080p with Medium settings
  • Up to 12% average FPS uplift at 1080p with High settings
• Assassin's Creed Valhalla* (DX12)
  • Up to 8% average FPS uplift at 1080p with Medium settings
  • Up to 11% average FPS uplift at 1080p with High settings
• Hellblade II: Senua’s Saga* (DX12)
  • Up to 6% average FPS uplift at 1080p with Medium settings
• Resident Evil Requiem* (DX12)
  • Up to 31% average FPS uplift at 1080p with Medium settings
  • Up to 29% average FPS uplift at 1080p with High settings
• Strange Brigade* (DX12)
  • Up to 16% average FPS uplift at 1080p with Medium settings
  • Up to 13% average FPS uplift at 1080p with High settings
• The Last of Us™ Part II Remastered* (DX12)
  • Up to 7% average FPS uplift at 1080p with Medium settings
  • Up to 5% average FPS uplift at 1080p with High settings

TL;DR

I installed an Intel Arc Pro B50 16GB into an old HP EliteDesk 800 G4 Small Form Factor (SFF) PC, powered by an Intel Core i5-8500, Q370 chipset, and its original 250W Platinum PSU.

Initially, Linux detected the card, but BAR2 was only 256MiB. Vulkan could access nearly 14GiB of dedicated VRAM, while PyTorch XPU couldn't detect the B50 at all.

After extensive troubleshooting, with help from ChatGPT and Claude Code Opus 5.5, we successfully enabled a full 16GiB ReBAR at runtime without flashing the BIOS.

The results:

• Full 16GiB BAR2 mapped successfully.
• Intel xe driver initialized correctly.
• PyTorch XPU recognized the B50 and executed real GPU matrix operations.
• Numerical comparison against CPU calculations passed.
• Automatic ReBAR restoration succeeded after one reboot.
• Qwen3-TTS generation throughput improved by approximately 35%.
• A functioning offline TTS worker and LAN API were deployed.

This is a real experiment, with actual logs and measurements. It is not a universal fix or a recommendation to blindly copy PCIe register modifications.

1. The story began with a failed B70 installation

In March 2026, I bought an Intel Arc Pro B70 32GB, hoping to use it in my Dell XPS 8930 with a Z370 chipset.

The CPU fan spun, but the display remained black. I never saw the Dell logo.

At the time, I assumed the machine couldn't boot with that GPU.

Looking back, I never actually verified whether the operating system was starting behind the black screen.

I eventually bought three secondhand components and assembled a separate Z390 system. That machine successfully runs the B70 alongside an AMD Radeon AI PRO R9700 and serves my local 27B language models.

But the original experience made me interested in modern Intel GPUs on older platforms.

2. Why I bought the B50

Later, ChatGPT pointed me toward a reported community success using an Arc Pro B50 in an HP EliteDesk 800 G4.

I already owned one: an HP EliteDesk 800 G4 Small Form Factor PC, running Linux as a home NAS.

I decided to take the chance.

The attraction was simple: 16GB of dedicated VRAM and relatively low power consumption, without having to replace the original 250W PSU.

I installed the GPU, powered on the NAS, and tried SSH.

It connected.

Linux was running, and the card appeared in PCIe enumeration.

That was the beginning of the experiment.

3. Hardware configuration

The UHD 630 handles NAS media decoding, while the B50 is dedicated to AI compute.

No BIOS flash, custom firmware, or BIOS setting modifications were used.

4. The initial 256MiB BAR problem

The GPU was recognized, but lspci reported:

Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]

The card's ReBAR capability reported support for sizes up to 16GB, but the current size was 256MB.

At first, we wondered whether this would limit actual GPU memory usage.

So we tested it.

5. Vulkan could use 13.88GiB even with Small BAR

Vulkan recognized the B50 as a discrete GPU.

Its dedicated DEVICE_LOCAL memory heap reported:

We filled the allocation using GPU commands and checked 19 different memory positions, including locations beyond the 256MiB boundary and near the end of the buffer.

All 19 samples matched.

This was dedicated GPU memory, not a multi-gigabyte system RAM fallback.

The validation was sampled, not a full byte-for-byte readback. Larger allocations beyond the reported budget weren't attempted.

Lesson #1: A 256MiB BAR does not necessarily mean the GPU can access only 256MiB of dedicated VRAM.

6. PyTorch XPU was a different story

I installed the official torch==2.14.1+xpu wheel in an isolated environment.

torch.xpu.is_available() returned True.

But device enumeration showed only Intel UHD Graphics 630.

The discrete B50 was missing.

The runtime logs included:

Resizable BAR not detected for device 0000:03:00.0

So Vulkan worked, but Intel XPU couldn't use the B50.

That was a major limitation for running native Intel-optimized AI frameworks.

7. We managed to run Qwen3-TTS through Vulkan first

Before solving ReBAR, we tried llama.cpp's Vulkan backend with Qwen3-TTS 1.7B GGUF.

It worked.

The relevant logs showed:

• Vulkan1: Intel Arc Pro B50 / BMG G21
• 29/29 model layers offloaded
• GPU buffer: 811.93MiB
• token_embd.weight: 170.30MiB on CPU
• Audio graph splits: 2

The first Chinese WAV was 10.24 seconds, 24kHz, mono.

Later, 46.32-second and 82.88-second single generations succeeded. A roughly 180-second generation failed because of a memory-slot allocation error, not a confirmed VRAM OOM.

Before enabling ReBAR, three short-text generation runs recorded RTF values of:

1.182 / 1.257 / 1.174

Average: 1.204

The audio was being generated slightly slower than real-time playback.

For an offline audiobook workload, it was still useful.

But we kept investigating.

8. The PCIe switch complicated everything

The B50 is behind an integrated Intel PCIe switch.

On this particular HP system, the relevant topology was:

• 00:01.0 — CPU PCIe root port
• 01:00.0 — Intel switch upstream port, 8086:e2ff
• 02:01.0 — internal downstream port, 8086:e2f0
• 03:00.0 — B50 GPU, 8086:e212

The host-facing link was PCIe Gen3 x8.

The original bridge windows were relatively small, including approximately 256MiB prefetchable windows inside the switch.

Simply changing the GPU BAR size couldn't guarantee that the entire upstream PCIe resource path would accommodate 16GiB.

We exported and verified 36 ACPI tables, examined the PCI root bridge resources, and investigated the DSDT.

The static ACPI analysis did not establish an obvious usable 16GiB allocation.

There were dynamic 64-bit resource hooks, but their effective runtime values were not initially confirmed.

At that point, our conclusion was INCONCLUSIVE, not impossible.

9. The breakthrough: runtime PCIe resource reallocation

I eventually took the accumulated logs and findings to Claude Code using Opus 5.5.

The successful approach involved Linux runtime PCIe re-enumeration.

Conceptually, the experiment:

1. Verified the exact PCI device identities and ReBAR capability.
2. Unbound the B50 from xe.
3. Disabled GPU PCI memory decoding before changing the BAR configuration.
4. Changed the ReBAR size selection.
5. Kept the CPU root port powered.
6. Removed the PCIe switch upstream subtree.
7. Allowed time before rescanning.
8. Let Linux re-enumerate the subtree and allocate the required resources.

The ReBAR control register changed from 00000822 to 00000e22.

The first immediate rescan didn't restore the card correctly. A subsequent attempt, after waiting and keeping the root port powered, succeeded.

Important warning: Removing a PCIe switch upstream port removes its child devices. This can break device enumeration or leave a headless computer unreachable.

The exact register offsets and PCI addresses belong to this tested configuration. This is not a safe universal copy-paste procedure.

10. Full 16GiB ReBAR — confirmed

After successful re-enumeration:

Region 2: Memory at 4400000000 (64-bit, prefetchable) [size=16G]

BAR 2: current size: 16GB

The xe driver reported:

This was a real full-sized BAR2 mapping, not simply a capability advertised by the GPU.

No BIOS flash was required.

11. PyTorch XPU finally worked

After ReBAR enlargement, the same existing PyTorch XPU environment detected:

Intel(R) Arc(TM) Pro B50 Graphics

We executed GPU matrix multiplication and retrieved the result.

The initial 4096×4096 smoke test succeeded.

A subsequent 2048×2048 CPU/XPU numerical comparison reported:

• Maximum absolute error: 5.34e-4
• torch.allclose: True

So we had moved beyond device detection to real, numerically validated XPU computation.

This didn't prove every PyTorch operator or every AI model would work, but the previously blocked GPU compute path had become usable.

12. Reboot restoration

The successful runtime configuration was not a BIOS modification.

A system-specific systemd helper and timer were configured to attempt restoration approximately three minutes after boot.

We rebooted.

The service exited successfully. After the boot-time procedure:

• BAR2 was 16GiB.
• The xe driver was initialized.
• PyTorch XPU detected the B50.
• A tensor computation passed.

This validated the restoration approach across one reboot.

Multiple cold boots, power-loss scenarios, and kernel-upgrade behavior still require further testing.

The timer mechanism should not be mistaken for a generally safe or validated solution for every old motherboard.

13. Unexpected result: TTS became significantly faster

We reran the same Qwen3-TTS Vulkan workload after enabling full ReBAR.

The model, text, offload configuration, and execution command were kept consistent.

This represents approximately:

1.35× generation throughput

34.9% higher throughput

25.9% lower generation time

Longer narration tests improved as well:

The 29/29 GPU layers didn't change. The 170MiB embedding buffer still remained on the CPU, and the graph-split pattern remained.

There is one important limitation: the system was rebooted between the old and new test groups, so ReBAR wasn't the only possible changing factor.

Still, the performance improvement was consistent, substantial, and worth reproducing independently.

The new RTF below 1 also meant speech was being generated faster than real-time playback.

14. The GPU now does actual useful work

We turned the working TTS setup into a background worker with a LAN HTTP interface.

Its functions include:

• Text segmentation
• Sequential audio generation
• Segment-level retry
• Resume after interruption
• WAV validation
• Audio concatenation
• LAN HTTP synthesis

A real 316.72-second audiobook-style story was generated.

The end-to-end job took 449.59 seconds, including an intentional interruption, retries, validation, and stitching.

For eight segments with complete timing information, the pure generation RTF was 0.935.

This is not yet commercial-grade audiobook production, but it's already a usable local AI service.

The B50 is now doing more than passing a benchmark.

It is giving an older NAS an entirely new capability.

15. Why I think this matters

Millions of older desktops and office PCs still have perfectly useful CPUs, memory, storage, and PCIe slots.

Their BIOS may not expose ReBAR.

That doesn't automatically mean modern Intel Arc workstation GPUs are unusable.

My HP EliteDesk 800 G4 SFF demonstrates that, at least on one configuration:

• A modern Battlemage GPU can work on an old Q370 platform.
• Linux can access substantial dedicated VRAM even with Small BAR.
• Runtime PCIe resource reallocation can sometimes enable full ReBAR without changing BIOS firmware.
• Full ReBAR may unlock Intel compute frameworks that previously couldn't initialize the GPU.
• Real application performance may improve substantially.

A low-power 16GB B50 can be attractive for older small-form-factor systems.

A larger 32GB B70 may offer another upgrade path for older desktops with suitable power supplies and cooling, although that requires independent compatibility testing.

This doesn't mean every motherboard will work.

But it does mean people shouldn't automatically discard otherwise useful hardware just because the firmware doesn't offer a ReBAR setting.

16. What others should test

I would encourage others to collect evidence in this order before attempting any low-level modifications:

1. Verify that the operating system actually boots, even if the display is black.
2. Record the GPU PCI ID, driver binding, and PCIe bridge topology.
3. Inspect BAR sizes and advertised ReBAR capabilities.
4. Test whether Vulkan or another backend can already perform GPU computation.
5. Check whether the PCI root bus has appropriate high MMIO resources.
6. Investigate the GPU's onboard PCIe switch and the kernel's bridge resource-allocation behavior.
7. Only consider disruptive PCIe reconfiguration if a local recovery plan exists.
8. Confirm real GPU computation and numerical correctness.
9. Compare actual model performance before and after changes.

The objective is not to blindly reproduce my commands.

It is to find out whether the underlying mechanism also applies to other hardware.

17. Questions for the community

I'd particularly appreciate input on these questions:

• Has anyone reproduced full runtime ReBAR on another HP EliteDesk 800 G4, Dell XPS 8930, or similar Q370/Z370 platform?
• Can an upstream Linux PCIe or xe fix remove the need for manual switch-subtree re-enumeration?
• Which bridge resource conditions are necessary for successful 16GiB or 32GiB BAR allocation?
• Has anyone compared Vulkan inference performance before and after ReBAR on the same Intel GPU?
• Could a hardware-specific recovery procedure eventually become a safer and more general diagnostic tool?

I'd love to compare PCIe topology and logs with anyone testing similar systems.

Final status

One last funny detail

To this day, I still have no idea whether this HP EliteDesk 800 G4 Small Form Factor PC would actually display anything on a monitor with the B50 installed — because I never connected a monitor to it, not even once, throughout the entire experiment. Everything was done headlessly over SSH.

So I've had bunch of parts sitting around for a while with the idea of building a secondary system in a mAtx case (Deepcool ch160)

Mobo is AM4 with a R5600, but the real question is, which card would make more sense, a B580 or RX6700XT 12GB. This is for a Linux build, possibly Cachy.

The 6700 is a fairly old model by now, but the card itself is a 2023 manufacture with moderate use history, the B580 is an Asrock challenger I bought back in 25, but soon replaced it with a 3 fan Sparkle in my larger main build.

B580 has supposedly better RT performance, but 6700XT could gain non-RT performance from Linux optimisation?

Really just throwing this question here if anyone else has been in a similar situation with comparable power cards.

Is there any chance of improving the upscaler? FSR4 and DLSS4+ run on FP8, while Arc only has FP16, even though we do have good INT8 performance, but will its precision be enough for an upscaler? I think fp16 xess han nowhere to grow but I'm not a ai specialist

A750 here. The latest driver seems causing my mouse pointer disappear. Any othwr fix other than roll back to the previous driver?

Anyone tried the God of War 3 PC port on an Arc B580? How does it run?

Link : https://github.com/FelipePrado0/gow3_pc/releases

Can you spot the Arc Pro B70 duo? They're hiding behind the Arc Pro B60, to do very intimate p2pdma things 😄

Both are connected over Gen5x8 to a Ryzen 9 9900X with 128GB DDR5, on an Asus ProArt X870e Creator Mainboard. The B60 sits on the chipset slot, extended by a Gen4x4 Riser cable, in a Fractal Define 7 case, which offers a vertical GPU Slot.

Am using the 64GB pool for Qwen3.8 27b in 8 bit quant, with 8 bit kv cache I get about 4x 160k Context windows for main agents and difficult tasks for Oh-My-Pi. Vision Tower is also active.

I currently evaluate my quant of Ornith 1.5 35b a3b int4 AutoRound XPU baked for llm-scaler, in int4 with 8 bit kv cache on the B60 with 4x 64k or 8x 32k context windows, for OMP roles that require less capabilities.

I added a tiny FastAPI Gate that properly rejects requests to Qwen3.8 27b if all seats are full, so that OMP can gracefully fall back to Ornith on the intermediate roles where I allow this to happen. Have documented this setup here (Has evolved since).

I recent bought the asrock intel arc b580 I installed it led lights up but the fans don't spin and it doesn't display on my monitor. I saw another post with similar issue having to return his card is there no way to fix this or is my card screwed

Pushing 1,798 tokens per second total throughput on a 27B-parameter model. 1,027 tok/s without prefix caching, 1,798 with it, nearly 300 output tok/s sustained at 64 clients, and a 110,000-token prompt processed on one 32 GB card with zero failures.

Why I quantized my own: ActiveKV

It's not just "KV cache offload." The idea is to stop treating GPU VRAM as the permanent home for an active request's entire KV history. I've been working on this product for a while.

ActiveKV keeps the private continuation host-authoritative while the GPU holds only the bounded working state it actually needs. Hot shared prefixes can stay resident, private tails can remain stable on-device, and the larger live history can exist outside HBM without requiring the model itself to move.

On Qwen3.8-27B, my current prefix-enabled prototype reduced peak GPU usage from 31.89 GiB to 23.14 GiB, about 27% less VRAM, while preserving exact outputs. Repeated shared-prefix H2D and warm-tail H2D are now both zero. The interesting part is what this potentially enables: models and context sizes that normally don't fit cleanly on a given GPU class may become practical without quantizing the model further or offloading the model weights.

More soon.

The Qwen3.8-27B quant I had been running on this card was the conservative recipe: INT4 on the MLP projections, FP8 on the attention and recurrent projections (I'd downloaded an NVFP4 release, which the B70 can't run, and converted it to that INT4/FP8 mix). On a B70 it tops out at 217 output tok/s no matter how many clients you throw at it (178 on upstream vLLM, 195 on Intel's container at 0.92 memory utilization, 217 at 0.94). To rule out the source weights I rebuilt the exact same recipe from the official BF16 checkpoint: 217 again.

So I took all 400 text projections to INT4, same group-32 format, from the official BF16 weights, and ran both builds back to back on the same B70 with the same harness. Result: +36% sustained throughput, 33% less device memory traffic per generated token, 21–23% less card energy per token, and 2.6 GiB more KV cache. Cost: +3.3% perplexity on my diagnostic set versus +0.25% for the conservative build.

Built specifically for the B70: Intel's own vLLM container, no forked vLLM, no custom kernels. Apache-2.0, weights here:

https://huggingface.co/Lets-Fafo/Qwen3.8-27B-FAFO-W4A16-G32-B70

Full breakdown of this build, all on one B70 (Intel `llm-scaler-vllm:0.26.0-b2`, eager mode, MTP off)

Sustained run, 512 requests at 64 clients over a fixed window, caching off: 294–297 output tok/s on two separate B70s (about 890 total tok/s at that 512/256 geometry).

Long context, single stream, caching off:

Zero failed requests across every run, close to 2,000 requests in total.

Memory

20.6 GB on disk, 18.66 GiB on the card, loads in 5 seconds. 7.8 GiB of KV cache at 32k context; with --max-model-len 114688 the cache holds 123k tokens, which is how the 110k prompt fits.

Quality

Small diagnostic set, so treat it as a sanity check rather than a benchmark: perplexity +3.3% vs the BF16 original, and 8/9 strict instruction/tool-call contracts. The one miss was a Markdown fence around otherwise correct tool JSON; with "return raw JSON" in the prompt it passes 9/9. This was resolved with a new prompt.

What's inside

Weight-only INT4, group size 32, BF16 scales, computed straight from the original BF16 weights (no calibration data, no fine-tuning). The 400 text projection layers are quantized; embeddings, lm_head, norms, the vision encoder and the MTP head are bit-identical to the original. Tokenizer and chat template are the upstream files. Standard compressed-tensors W4A16; vLLM picks it up with XPUwNa16LinearKernel.

Caveats

• Validated on the B70 only, with Intel's XPU build of vLLM. Not tested on B580, B60, or straight through Transformers. If you run it on another Battlemage card, post what you get.
• vLLM marks prefix caching experimental for this hybrid architecture. Median latency improved at every concurrency but p95 TTFT got worse at 4, 8 and 16 clients.
• The exact docker run command I verified is in the card. Copy it as-is first.

Happy to answer questions on the recipe or the measurements!

I’m thinking about ditching my B580 for a 5060 or a amd equivalent. this kinda hurts cos I was actually impressed but idk it’s kinda sucking at games like the new metal gear remake where id barely get 60fps without using framegen or with older games like halo mcc where it gets very high frames but goes drastically drop down to barely 60. I am running this with an i5-10400f and 16gb ddr4 which could explain the deficit but im willing to upgrade my cpu to a ryzen 9600x and with ddr5 16gb ram, someone make me talk out of this cos i really do like the b580 but with a lack of graphics settings and comparability makes me sick

The mouse cursor issue is still not fixed and the one major game it was supposed to prepare for(Gears E-Day) can't even load through the main menu. On top of that games like God of War 2018 are still unplayable.

One of the community's main requests and points of contention is official support for the XMX path for Intel XeSS on Linux; we already know that Intel began work on GitHub in February 2026, but so far, we do not know exactly when this support will arrive.

Looking at the timeline, it's clearly Intel's focus to resolve the hardware and compilation bottlenecks before supporting the upscaling itself.

Here is the breakdown of the most important Intel Arc changes recently:

• 24.2 = Out-of-the-box enabling (without force probe) for the Xe2 architecture
• 24.3 = Global HiZ-CCS fix (up to 260% performance gains in DX11)
• 25.0 = Drastic reduction in driver overhead (CPU bottleneck)
• 25.1 = Initial stable support for the Battlemage architecture
• 25.2 = Ray Tracing stability with the Xe kernel driver
• 25.3 = Initial implementation of the "Jay" shader compiler
• 26.0 = Enabling of Large GRF mode (FPS stability in complex shaders)
• 26.1 = Mitigation of crashes due to running out of VRAM (Out of Memory)
• 26.2 = VK_EXT_descriptor_heap extension enabled by default
• 26.3 (devel) = Global CCS buffer compression for DXVK (faster DX11 gaming)
• 26.3 (devel) = "Jay" shader compiler enabled by default for Xe2/Xe3 architectures
• 26.3 (devel) = Vulkan Video AV1 encoding support enabled for Alchemist GPUs
• 26.3 (devel) = Valve's Morton merge sort integration (faster Vulkan Ray Tracing)

This leaves us with an interesting question for discussion:

Do you think Intel is intentionally focusing on polishing the core hardware driver and compilation pipeline first, ensuring a flawless foundation, before finally bringing the official XMX support to Linux? Or is there another technical hurdle holding it back?

Note: AI was used solely to translate this post from Portuguese to English.

Since recent driver release has anyone noticed different behavior on ComfyUI for the B70?

Prior to updating a few days ago I was able to run MiniMax H3 Director at nearly all full weights with offloading, but it would run. Now I constantly get errors due to what seems to be out of memory errors even using FP8 pruned weights on the diffusers and LORAs with the error device lost.

I usually build small mini-itx desktops for clients (some light steam machines, essentially) but I have noticed in recent days and weeks that all sorts of models are quickly vanishing from stores, at least in the US market. You can still, for the most part, score a B570 or a B580, at inflated prices, but everything else is a crapshoot. My concern is that if I don’t stockpile now that by the holiday seasons this year, there really won’t be much, at all, budget-wise. With the ram increases being what they are, is it even likely that Intel’s partners will continue cranking out Intel Arc graphic cards instead of shifting to more profitable lines?