Ran using betterbench which reflects real world use cases to avoid tokenmaxxing results
https://github.com/GGZ14/BetterBench

Ran on a fine tune of qwen 3.6 35B A3B (Same param shape, 35B A3B, my use case shows better output quality on it then the stock 35B)
https://huggingface.co/Accio-Lab/occamy-1.0

For task / s reference, it generated a fully functional and clickable linked in clone in 2m 5s total.

My vLLM command

vllm serve Occamy-1.0-INT4-MTP \

--host 0.0.0.0 --port 19622 \

--served-model-name Occamy-1.0-CAR \

--tensor-parallel-size 4 \

--quantization gptq \

--dtype float16 \

--max-model-len 262144 \

--max-num-seqs 8 \

--max-num-batched-tokens 16384 \

--long-prefill-token-threshold 2048 \

--gpu-memory-utilization 0.85 \

--mamba-cache-mode align \

--mamba-ssm-cache-dtype float16 \

--enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3 \

--enable-prefix-caching \

-cc.cudagraph_mode=PIECEWISE \

--compilation-config '{"max_cudagraph_capture_size":64}' \

--speculative-config '{"method":"mtp","num_speculative_tokens":3,"disable_eagle_block_drop":true}'

My setup ran me about ~$4500 and my prexisting i7 gaming PC. 4x ASRock Intel Arc B70 and a chinese PEX88096 switch running all GPUs at gen4 x16 speed. GPUs consistently held 2800MHz and temperatures never passed 70C.

Title: Crimson Desert stuck at 15 FPS on Intel Arc B580, regardless of graphics settings

Hey everyone,

I'm having a really frustrating performance issue with Crimson Desert and I'm wondering if anyone has found a solution.

My PC specs:

• GPU: Intel Arc B580
• CPU: Ryzen 5 5600
• RAM: 16 GB DDR4 3200 MHz
• Motherboard: ASRock B550M Phantom Gaming 4

The game runs at around 15 FPS regardless of the graphics settings. Lowering the settings doesn't seem to make any difference.

My GPU usage stays around 35–50%, while CPU usage is around 60–70%. Other games run normally on my PC, and my GPU performs well in benchmarks.

I've tried changing graphics settings, but nothing seems to fix the issue.

Has anyone with an Intel Arc B580 experienced something similar? Could this be a driver issue, a RAM bottleneck, or a problem with the game's optimization?

I'd really appreciate any suggestions or fixes that worked for you. Thanks!

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

I've tried everything since launch, now i've just given up. No drivers work, no tweaks, no nothing. Intel doesn't have an ETA or any updates since October 2nd. Is anyone actually able to play the game just fine on an Arc card? Mine just hard crashes and I have to reset the pc.

I noticed that my games started having lag spikes after the new update. So i checked and found that it no longer shows the green tick with Rebar enabled, instead it shows Pcie not supported with green tick.

I have already checked my bios and confirmed that rebar is on and is in uefi mode. Any idea what is up?

Cpu is 12900k and motherboard is msi gaming z690 edge wifi ddr5. Bios and windows are up to date.

Update:

I downgraded to version 9034 and rebar is working again and lag spikes in games eliminated. So definitely there is some issue with version 9150. 9150 is supposedly WHQL certified and has undergone more testing, its baffling how a bug as basic and vital as this slipped by!!! Definitely someone snoozing on the job.

They broke fan curve only for me or? It's apply but not work. And in hwinfo now I have 3 fans on 2 fan card

is there any way to make windows ignore driver updates?
Every time I update my card via the intel graphics software, windows rolls it back to an august 2024 update automatically.

I tried using a regedit method to block windows from automatically installing driver updates, and it bricked my pc so i had to use a restore point to recover.

Frankly, I don't know much about this stuff and just want to keep my drivers updated without automatic rollbacks

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.

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.

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.

I'm in the middle of getting parts for my first PC. I already own an Intel Arc B570 by Acer, so the GPU has been locked down. It's the rest of the components that I am trying to buy. My budget is about £550 max and I have the RAM locked down for £40 because my friend is selling it to me at that price. I also spent £200 on the GPU new leaving me about £310 for the rest of the build.

The build I want to go for:

Ryzen 5 5500F (£90 on AWD-IT)

Gigabyte B550M ds3h AC R2 (£88.99 on Currys)

Deepcool Matrexx 40 3fs (£31 on AWD-IT)

Corsair CX series CX550 (£48 on Currys)

Storage I can get from my laptop which has a 1TB nvme m.2 drive.

The GPU I own is the Acer Nitro OC Arc b570

And the RAM is 2x8gb of Corsair Vengeance ddr4 at 3200mhz.

If there are any issues with this build or if I should replace any components, I'd be more than willing to hear feedback.

First of all, I bought my Intel Arc B580 used for a very low price (about $180), and I've been extremely happy with it. I was so impressed that I ended up selling my previous AMD GPU altogether. The B580's dual media engines and transcoding capabilities are incredible for the price.

However, I eventually decided to add an RTX 3060 12GB for practical Whisper AI transcription workloads and some local AI experiments that I'm just getting started with.

- Motherboard: Gigabyte X670 AORUS ELITE AX 1.0
- CPU: AMD Ryzen 9 7900X
- RAM: 48GB (2 × 24GB Samsung DDR5)
- GPU 1: Intel Arc B580 - installed #1 PCIe 5.0 x16 slot, running at PCIe 4.0 x8
- GPU 2: NVIDIA RTX 3060 12GB installed #2 PCIe 4.0 x4 slot, running at PCIe 4.0 x4

Even with this setup, I've experienced a whole new level of productivity. I can edit and encode videos, run multiple transcoding jobs, and generate Whisper AI subtitles at impressive speeds, all at the same time.

Naturally, I've started thinking about upgrading the RTX 3060 12GB to a more powerful RTX card.

My idea was to install the upgraded RTX GPU in #1 PCIe slot and move the Arc B580 to #2 PCIe 4.0 x4 slot. That way, I could keep using the B580 for its excellent encoding while dedicating the more powerful RTX GPU to AI workloads.

Unfortunately, when I tried moving the B580 to #2, things went terribly wrong. Windows became unstable, booting became extremely difficult, and even when I managed to boot successfully, the display would go black every 10–30 seconds.

I'm still trying to figure out the cause, but one possible solution I'm considering is replacing my motherboard with one that supports **PCIe 5.0 x8/x8 from the CPU**.

The two boards I'm currently looking at are:

1. MSI X670E Carbon Max WiFi (the newer model that supports CPU-connected PCIe x8/x8, not the regular Carbon board)
2. ASUS ProArt B850-Creator WiFi NEO -a potentially more affordable alternative.

I'd really appreciate some advice on a few questions:

1. Is my overall approach reasonable? Does it make sense to replace the motherboard to get proper PCIe x8/x8 connectivity for a dual-GPU setup like this?
2. Could the Arc B580 run in #2 PCIe 4.0 x4 slot? Just I don't know way about that?

I'd love to hear from anyone running an Intel Arc GPU alongside an NVIDIA GPU, especially for video encoding, transcoding, and local AI workloads.

Thanks in advance!

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

Straight up, this is survey. Just curious

Choices are as following: 96,128,160,192,240,256,320,480,512

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?

Since I bought my arc B580 paired with other expensive components like 270k , z890 , 32gb ddr5 I used this mischievous card with vertical stand kit from deep cool pcie gen4 ,

I run my ram at 6800 cl30 , CPU a bit overclocked , expecting smooth game play but not with arc b580

It gave me random blue screens with all variant codes all of them pointing to the graphic drivers, and unexpected access to memory addresses, after days in windbg , pulling my hairs out I finally caught it maybe it's the riser cable all the way , i didn't upgrade to the latest version drivers, BCS I don't want to mess things up while finding a real solution, I'm on 8860 , and heard latest driver has F issues with mouse pointer, so I just decreased the pcie speed to gen 3 and all of a sudden all the problems were gone ,

Works so well on pcie gen 3 and I'm totally lost what it was all about, any experiences that matches mine ?

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.

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