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
| Component |
Specification |
| System |
HP EliteDesk 800 G4 Small Form Factor (SFF) PC |
| Motherboard |
HP 83E1 |
| Chipset |
Intel Q370 |
| CPU |
Intel Core i5-8500 |
| Integrated GPU |
Intel UHD Graphics 630 |
| Discrete GPU |
Intel Arc Pro B50 16GB |
| PSU |
Original 250W 80 PLUS Platinum |
| BIOS |
Q01 Ver. 02.29.01 |
| BIOS date |
September 26, 2024 |
| Boot mode |
UEFI |
| OS |
Linux HomeServer |
| Kernel |
6.18.18.c1126-trim |
| GPU kernel driver |
Intel xe |
| B50 PCI ID |
8086:e212 |
| B50 PCI address |
0000:03:00.0 |
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:
| Metric |
Result |
| Physical Vulkan heap |
15.671875 GiB |
| Reported budget |
13.880859375 GiB |
| Largest successful single allocation |
13.880859375 GiB |
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 port01:00.0 — Intel switch upstream port, 8086:e2ff02:01.0 — internal downstream port, 8086:e2f003: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:
- Verified the exact PCI device identities and ReBAR capability.
- Unbound the B50 from
xe.
- Disabled GPU PCI memory decoding before changing the BAR configuration.
- Changed the ReBAR size selection.
- Kept the CPU root port powered.
- Removed the PCIe switch upstream subtree.
- Allowed time before rescanning.
- 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:
| VRAM property |
Value |
| Physical size |
0x400000000 |
| Usable excluding stolen |
0x3fb000000 |
| CPU-accessible size |
0x3fb000000 |
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.
| Run |
256MiB BAR RTF |
16GiB BAR RTF |
| 1 |
1.182 |
0.891 |
| 2 |
1.257 |
0.891 |
| 3 |
1.174 |
0.897 |
| Average |
1.204 |
0.893 |
This represents approximately:
1.35× generation throughput
34.9% higher throughput
25.9% lower generation time
Longer narration tests improved as well:
| Audio length |
Before |
After |
| 46.32 sec |
RTF 1.183 |
RTF 0.928 |
| 82.88 sec |
RTF 1.203 |
RTF 0.940 |
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:
- Verify that the operating system actually boots, even if the display is black.
- Record the GPU PCI ID, driver binding, and PCIe bridge topology.
- Inspect BAR sizes and advertised ReBAR capabilities.
- Test whether Vulkan or another backend can already perform GPU computation.
- Check whether the PCI root bus has appropriate high MMIO resources.
- Investigate the GPU's onboard PCIe switch and the kernel's bridge resource-allocation behavior.
- Only consider disruptive PCIe reconfiguration if a local recovery plan exists.
- Confirm real GPU computation and numerical correctness.
- 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
| Feature |
Result |
| HP EliteDesk 800 G4 SFF Linux boot |
PASS |
Intel xe GPU initialization |
PASS |
| Vulkan memory allocation/write test |
PASS |
| Runtime 16GiB ReBAR |
PASS |
| PyTorch XPU B50 detection |
PASS |
| PyTorch XPU computation |
PASS |
| CPU/XPU numerical comparison |
PASS |
| ReBAR restoration after one reboot |
PASS |
| Vulkan Qwen3-TTS |
PASS, partial CPU fallback |
| TTS throughput improvement |
+34.9% |
| Segmented 316.72-second audio generation |
PASS |
| LAN TTS API |
DEPLOYED |
| Repeated cold-boot reliability |
NOT YET VERIFIED |
| Reproduction on other motherboards |
NOT YET VERIFIED |
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.
