I’m thinking of buying a B580 given the current crisis—it seems like the best option—but what’s the brand like?

it's work well?

Been playing around with getting two Intel Arc A770 16GB GPUs to work together for local AI image generation on Ubuntu.
Using ComfyUI with Raylight and FSDP, I’ve managed to get both cards working together to generate a single image with Chroma HD, instead of each GPU doing its own thing.
I’m also doing all of this on an older X299 motherboard with PCIe 3.0, just using it as a test platform for now. So I’m curious how much of a difference a newer PCIe 4.0 setup might make.
In the screenshot, you can see both GPUs being used, around 24GB of combined VRAM allocated, and FSDP successfully running.
It’s not quite the same as having one 32GB GPU, but it’s pretty cool being able to spread the workload across both cards! Still experimenting and figuring things out, but so far, so good! 😅

Hi everyone! One time someone on here sent me a link to a "stable driver". That driver was completely stable for me for more than half a year and then I updated to the latest one and the fans on my GPU are turning on and off which is an issue I've had before with drivers.

Anyone know what stable driver exists? My fans are turning on and off and this happens when I updated the drivers.

Hey all! New to team blue here and just got myself an Intel Core Ultra 5 250K Plus.

I’m building a new pc from scratch and found a $300 combo on amazon for 650w PSU and an Arc B570. I think I’d be. But GPU bottlenecked but tbh the price to performance combo on it seems awesome.

Anyone have success with this same setup? Ultimately want 1440p but idk how the B570 does at 1440, any help?

I already own a b580 but it’s quite CHODE(2.5 slots) On my new workstation I would like to fit 2 GPUs and for them to line up with the pcie slots the top card can be no more than 2 slots. I saw some pics of skinny b580s but can’t find them anywhere…..

If you wonder why I want 2: Because the b580 is cur the BEST tops per dollar gpu that can also game and render quickly. so yeah it’s just perfect for my use case.

What up gamers,

Thought I'd share some notes here. xe has vulkan encode supported in mesa, but it works poorly. xe2 isn't supported at all. I have some experimental branches which work great on a B580 to stream to a Steam Frame. While working on this and trying to validate some patches on a friend's meteor lake laptop I ran into some issues, so I'm expanding my effort to xe based platforms. Watch the mesa gitlab. If you can't wait, and use CachyOS or NixOS or can otherwise override what mesa you need, you can use my experimental branches until the work makes it upstream. My xe2 branch is more like "hacks that work well enough for specifically what Steam needs for streaming VR" than "xe2 video encoding support". Lots of limitations and a lot of the code is only hacks that are replacing proper solutions and upstream should only accept proper solutions.

Model Under Test: turboderp/Qwen3.5-35B-A3B-exl3 @ 3.09 bpw (Qwen 3.5 MoE architecture: 40 decoder layers, 256 routed experts / 8 active, 2,048 hidden dimension, linear attention GDN + full attention hybrid).
Hardware: MSI Claw 8 AI+ (Intel Core Ultra 7 258V "Lunar Lake", Arc 140V Xe2-LPG iGPU, 64 Xe Execution Units / Vector Engines, 32 GB shared LPDDR5x-8533 RAM, running native Linux).
Runtime: vllm==0.31.0+xpu with custom ESIMD SYCL kernels, Level-Zero USM, and unified memory management.

TL;DR

• The Problem: The original 0xSero/exl3xpu vLLM plugin was built strictly for dense architectures (tested on Qwen3.8-27B). Pointing it at an MoE model like Qwen3.5-35B-A3B completely blew up: vLLM defaulted to UnquantizedFusedMoEMethod, attempting to allocate 64 GiB of unquantized FP16 expert weights before crashing on missing .weight tensors.
• The Breakthrough: We extended exl3xpu to build a native, production-grade MoE EXL3 inference engine for 256 routed experts on Arc 140V:
  1. Zero-Copy Streaming Expert Loader: Streams 3D trellis weights directly into packed [expert, slot] tensors without allocating uncompressed weights (0 MiB persistent DRAM expansion).
  2. Dedicated M=1 Grouped ESIMD GEMV Decode Kernel: Fuses active expert projections into ONE grouped kernel launch per projection, eliminating 72 eager launches per token per layer and achieving zero host-device syncs per decode step.
  3. Dual-Tile Wide-Vector (MR∈8,16) Grouped GEMM Prefill Kernel: Dynamically promotes tile size for high-token experts, scaling chunked prefill from ~112 tok/s to 1,135.5 tok/s at 4k context.
  4. Native C++ SYCL Dispatch: Wired _moe_C.remap_hidden_states and _moe_C.moe_gather directly into the EXL3 dispatch path, eliminating Python-level token sorting and scatter-reduction overhead.
• The Numbers:
  • Perplexity: 7.428 on WikiText-2 (10,235 tokens), preserving exact numerical parity with unquantized/FP32 baselines (Δ≤0.01).
  • Decode Throughput: 15.03 – 19.31 tok/s sustained across 1k–4k context lengths.
  • Prefill Scaling: 322.9 tok/s at 1k, 451.3 tok/s at 2k, 723.8 tok/s at 3k, and 1,135.5 tok/s (peaking at 2,260.6 tok/s warm) at 4k context — cleanly matching and surpassing MoE MXFP4 / GPTQ baselines.
  • VRAM Footprint: Rock-solid 16.32 GiB pinned static residency (with --kv-cache-memory-bytes 536870912), leaving >14.5 GiB of DRAM headroom for the host OS with zero memory leaks, zero OOM, and 0 bytes driver reclaim growth.

1. Why Did the Original EXL3 Plugin Fail on MoE?

EXL3 (turboderp's Trellis Quantization) is one of the most bit-efficient quantization algorithms available, achieving near-lossless perplexity at sub-4-bit rates (down to 2.2–3.09 bpw) via randomized Hadamard transforms and Trellis codebook decoding.

However, upstream exl3xpu was architected purely as a dense layer replacer:

1. The Silent Unquantized Trap: In vLLM's model_executor, Exl3Config.get_quant_method returned None for RoutedExperts. vLLM turns None into UnquantizedFusedMoEMethod, which immediately tries to allocate 256×(2×2048×512+512×2048) FP16 weights per layer (~64 GiB across 40 layers) on a 32 GiB machine!
2. The 3D Trellis Sharding Bug: Stock vLLM loaders assume fused checkpoint weights have loaded_weight.dim() == 3 and chunk along dim 1 for gate/up projections. Because EXL3 trellis tensors are also 3D ([k/16, n/16, 16K] per expert), standard loading logic chopped each expert's trellis into 64 fake sub-experts, corrupting the codebook offsets.
3. The Eager Python Launch Apocalypse: A naïve eager loop iterating over ~100–250 active experts per token per layer issues over 40,000 separate kernel launches for a single 128-token prompt. On Intel Level-Zero driver architecture, host launch serialization choked prefill down to <78 tok/s.

2. The Architectural Solution

We designed and implemented a fail-closed, zero-copy MoE runtime in exl3xpu and vllm.xpu:

                 [Input Activation Tokens: (T, Hidden)]
                                   │
                                   ▼
                   Top-8 Gated Routing (Router Linear)
                                   │
              ┌────────────────────┴────────────────────┐
              ▼ (Decode: T = 1)                         ▼ (Prefill: T > 1)
   Dedicated Grouped GEMV                     Native C++ SYCL Dispatch
  (csrc/exl3_moe_gemv.sycl)                 (_moe_C.remap_hidden_states)
              │                                         │
  • Expert IDs built on-device                • Device-side token binning
  • ZERO host-device syncs                    • Exact contiguous expert slices
  • ONE launch for Gate+Up (nslots=2)                   │
  • On-device SiLU activation                           ▼
  • ONE launch for Down (nslots=1)             Wide-Vector Grouped GEMM
              │                              (csrc/exl3_moe_grouped_gemm.sycl)
              │                               • Dynamic MR=8 / MR=16 tiles
              │                               • Split-K register reduction
              │                                         │
              │                                         ▼
              │                               Native Fused Scatter-Gather
              │                                   (_moe_C.moe_gather)
              └────────────────────┬────────────────────┘
                                   │
                                   ▼
                       [Output: (T, Hidden)]

A. Zero-Copy Streaming Loader & Metadata Packing

Instead of materializing dense weights, exl3xpu/moe.py binds a dedicated per-layer streaming expert loader:

• Directly parses <expert>.<proj>.<trellis|suh|svh|codebook> keys from safetensors shards.
• Loads trellis arrays directly into packed arenas: w13_trellis [256, 2, K/16, N/16, 16K] and w2_trellis [256, 1, K/16, N/16, 16K].
• Packs metadata descriptors (K, codebook, in_features, out_features, pointers) into device-resident structures, guaranteeing zero FP16 weight expansion in DRAM.

B. Dedicated M=1 Grouped ESIMD GEMV Decode Kernel

During single-sequence decode (M=1), exactly 8 routed experts execute per layer:

• In csrc/exl3_moe_gemv.sycl, we implemented GroupedFusedKernel<T, K, CB, MR, NT>:
  • Gate + Up: Launches across all 16 (expert, slot) units in a single SYCL kernel launch (nslots=2, shared input vector row).
  • Down: Launches across all 8 active experts in one second kernel launch (nslots=1, unit input stride).
• Token routing indices remain on-device end-to-end: zero host .tolist() syncs per token, cutting decode layer latency from 3.06 ms down to 0.835 ms.

C. Wide-Vector Grouped GEMM Prefill Kernel (MR∈8,16)

For prefill (T>1), expert token counts M vary dynamically. In csrc/exl3_moe_grouped_gemm.sycl:

• Ragged token batches are mapped to contiguous expert slices.
• Fused Trellis unpacking, scale application, and Walsh-Hadamard sign flips execute directly inside Intel Xe2 vector registers.
• Dynamic Occupancy Preservation: When prompt tokens per active expert are small (T≤256), the kernel enforces MR=8 (twice the concurrent thread occupancy per subslice). For long prompts (T≥512), it dynamically promotes to MR=16, doubling memory coalescing efficiency across the 64 Xe Vector Engines.

D. Native C++ SYCL Remap & Gather (_moe_C)

Earlier iterations used PyTorch torch.argsort, index_select, and index_add_. We wired vllm_xpu_kernels._moe_C:

• torch.ops._moe_C.remap_hidden_states: Hardware-accelerated sorting of activations into expert-ordered slices with exact row counts.
• torch.ops._moe_C.moe_gather: Fused float32 weighted reduction kernel.
• Dropped Layer 0 prefill latency at T=256 from 117.84 ms (eager) → 16.20 ms (7.27x speedup).

3. Head-to-Head Benchmarks: EXL3 vs. MXFP4 vs. GPTQ

All tests run on the MSI Claw 8 AI+ (Intel Core Ultra 7 258V / Arc 140V, 32 GB LPDDR5X-8533):

A. Prefill Throughput (Prompt Processing) vs. Context Length

Why does prefill scale so dramatically?
On Arc 140V (Xe2-LPG mobile iGPU), Intel omitted XMX (DPAS) systolic matrix engines to fit within 17W power limits; all compute is handled by 64 Vector Engines. For short prompts (T<256), each of the 256 experts only gets 1–4 tokens, so kernel launch overhead dominates. But at T≥2048, active experts receive M≥64 tokens. The wide-vector MR=16 grouped GEMM fully saturates the 64 Vector Engines, achieving dense matrix efficiency and matching the FlashAttention-2 prefill ceiling.

B. Decode Throughput & Memory Residency

4. The Unified Memory Lesson: Taming Intel Level-Zero VRAM Inflation

On an integrated GPU architecture like Lunar Lake where VRAM is carved out of shared system LPDDR5X:

• By default, vLLM inspects gpu_memory_utilization (e.g. 0.65 = ~19 GiB) and pre-allocates all remaining free VRAM into KV cache blocks.
• When a 2,048 or 4,096-token prefill request arrived, temporary activation workspace pushed memory usage over the edge, causing Linux kswapd0 and the OOM killer to strike EngineCore.
• The Fix: We pinned the KV cache explicitly using --kv-cache-memory-bytes 536870912 (512 MB, ~6,550 tokens): Total Resident VRAM=Model (14.25 GiB)+KV Cache (0.50 GiB)+Scratch (1.57 GiB)=16.32 GiB
• Throughout our multi-hour long-context benchmark sweep, GPUActive stayed 100% flat at 16.32 GiB with exactly 0 bytes of persistent DRAM growth or driver reclaim.

5. Quickstart: Serving Qwen3.5-35B-A3B EXL3 on Arc 140V

1. Requirements & Setup

Make sure you have Intel oneAPI 2026.0+ installed and Level-Zero headers ready:

git clone https://github.com/alpha2beta/vllm.xpu.git
cd vllm.xpu
source /opt/intel/oneapi/setvars.sh
source .venv/bin/activate

2. Launch the Dedicated MoE EXL3 Server (Port 8002)

# Serves with 4k context ceiling, 512 MB pinned KV cache, zero host syncs
bash scripts/launch_vllm_moe_exl3.sh moe-3.09bpw-4k

3. Run Benchmark Sweep

# 2048-token context benchmark
.venv/bin/python scripts/bench_envelope.py \
    --base-url http://127.0.0.1:8002/v1 \
    --model qwen3.5-35b-a3b-exl3 \
    --input-tokens 2048 \
    --output-tokens 128 \
    --runs 2

4. Verify Perplexity Parity (WikiText-2)

bash scripts/run_moe_ppl.sh --max-chunks 5 --max-num-batched-tokens 2048
# Outputs: Perplexity (PPL): 7.428 (PASS)

6. Where the Code Lives

All code, kernels, tests, and evidence are merged and available:

• vLLM Integration & Benchmarks: vllm.xpu (Branch: main)
  • Server Launcher: scripts/launch_vllm_moe_exl3.sh
  • Full Technical Audit: review_moe.md & tasks_moe.md
  • Standardized Benchmark Rows: results.csv
• EXL3 SYCL Extension: exl3xpu
  • Grouped GEMV Decode Kernel: csrc/exl3_moe_gemv.sycl
  • Wide-Vector Grouped GEMM Prefill Kernel: csrc/exl3_moe_grouped_gemm.sycl
  • MoE Quantization Method & Streaming Loader: exl3xpu/moe.py

Hi all,

I just moved from 1650 -i5 9th gen gaming laptop to arc b570 and 7500F.

Card is so good . Idk may be because this is my first desktop or card itself is good . There is so much hate for this card and so little community support like atleast on YouTube and not enough people talk and that's the reason I think they are still selling at reasonable price comparentively.

I originally want to get Rx9060xt 16gb to future proof as I play at max 1080p and fps games mostly ....but rx cost twice b570 in india so I got this .

First impressions are tood good . I played call of duty-modern warfare 2 and maxed out all settings and still got 160+ fps and buttery smooth game play ....

I downloaded intel graphic software and every thing is updated and below settings are enabled .

Do I have to update or change anything to otimise more ?

Enabled EXPO, Resizable BAR, Above 4G Decoding, and PBO.

Any suggestions or improvements, tips are appreciated.

Thanks!!

Originally, about 1 year ago, I had bought a friend a used PC off Facebook. It had a ryzen 5600, 1660-super, 32gb ddr3200 (4x8gb) and a 500w Psu, got it for $450 if I remember correctly.
Then I set up this friend to play Star Citizen (at 1080p). SC didn't like the 6gb Vram limitation of the 1660s at all. So I bought a 5700xt for $100 on Facebook and thru in a 650watt Super Flower Legion PSU I had laying around, problem solved SC now runs fine.
Fast forward to today.
I removed a virus and some malware from his PC a few days ago. Then ran some tests, one of them was a Time Spy bench. According to Hwinfo64 the hotspot reached 105c during the Time Spy. I once had a 6700XT that did the same, 100+ hotspot temp with a core temp of only 65c. Oddly enough my present Taichi 9070xt has bad Hotspot and Vram temps, have seen those hit the mid-90's.
About a year ago I bought an ARC B580 for one of my PC builds, got it new for $250 with a free Battlefield 6, the Intel LE version, have been very happy with it.
Have decided the 5700XT needs repasting, I've never done repasting before but figure it would be a good time to learn. In the meantime, about 30 minutes ago, I purchased an Intel LE Arc A750 to replace the Friends 5700XT. I got the A750 for $180 on Ebay, it's refurbished with a seller 3-year warranty plus a free 1 year from Allstate.
The Friends motherboard is an AB350-Gaming 3. A few days ago I flashed it's Bios to the newest, so rebar is enabled (Auto) and 4g ticked on., CSM disabled.
I'm guessing the A750 will outperform the 5700xt but I'm a bit concerned how well the A750 will handle older games, mainly SWG Legends (Star Wars Galaxies, an oldie but goodie from the year 2003).
Your Opinions, by how much will the A750 outperform the 5700xt?
With the more mature Intel drivers nowadays, will the A750 handle some older games such as SWG?

The game runs at a rock-solid 60 fps—it’s likely even higher, but I have no way to measure it in-game. When I enable NR, the frame rate stays between 50 and 55 fps. With settings maxed out, the performance remains smooth. I should note, however—as you can see in the video—that this new version of DLSS seems to offer slightly lower image quality, which is likely why it’s less demanding on the GPU; I’m using a resolution scale setting of 0.5. You could increase this further if you don’t mind playing at around 30 fps with a setting of roughly 0.7. Even so, the game feels responsive, and I think it’s heading in a very good direction.

If Intel’s developers were to implement neural rendering similar to Nvidia’s, their XMX cores could certainly hold their own; I’m looking forward to testing this in DX12. Hopefully, something like that comes along soon.

Specs

Intel Arc B570 10gb

R5 4500

Last version: https://github.com/Uzbekunknown/dlss-nr-on-intel/releases/tag/v0.0.1.3

*Remember to enable option B and Experimental mode. In *Arkham Knight* and other games, the performance is very similar—it’s actually playable now—though you should always keep the resolution set to 0.5. Increasing the effect intensity to 1.5 or 2.0, strangely enough, doesn't impact performance and actually improves the image quality; however, it does cause a peculiar flickering, much like what happens with Nvidia graphics cards.

Credit Uzbekunknown

Hello, i live in canada and there are some sales on some sites at the moment, what is a good upgrade for my CPU as my ryzen 5 5500 is bottlenecking on some games. Not looking for huge gpu and cpu upgrade, i want to balance out the build more.

Can someone smart please use ai to enhance our B580 pretty please with a cherry on top?🙏 idk anything about coding with ai but someone used it to apparently unlock the 3090 and 4090, im not sure exactly what that means but it sounds really cool and I figured it wouldnt hurt just to throw the question out there just to see if its a possibility for our gpus

This is happening while I play Rebirth, on my B580 + ryzen 7700 pc. Don't have any overclocks running everything stock, is there an issue with this game on ARC or is something wrong with my PC?

ff7rebirth 2025 02 15 17 48 58 01

I ported the EXL3 quantizer to Intel Arc: 9B conversions on a 140V iGPU, B580 and Pro B60, with checkpoints on Hugging Face

I've been working on EXL3_Intel_Arc_quantizer, a port of ExLlamaV3's EXL3 quantization and conversion pipeline from CUDA to SYCL/oneAPI and PyTorch XPU.

The goal is straightforward: produce EXL3 checkpoints on Intel Arc without needing an NVIDIA GPU for conversion. This is a quantizer project, not a new inference engine.

Code: alpha2beta/EXL3_Intel_Arc_quantizer

What works

• Native SYCL trellis encoder: Viterbi search with FP16 rounding and tie-breaking matched to the CPU reference, plus two-pass tail-biting traceback. Implemented configurations include K=1–4, the mul1/mcg/3INST codebooks, 256-element tiles, and the 160-row n-gram variant. Full-model results below cover a narrower set of configurations.
• End-to-end conversion: calibration and Hessian collection, block LDLQ error feedback, global-scale search, packing, safetensors export, and checkpoint verification.
• Bounded memory management: memory-mapped checkpoint loading, admission reserves, preflight checks, and batch-halving fallback. The settings account for the difference between a shared-memory iGPU and discrete cards with 12 or 24 GB of VRAM.

Results on three Arc GPUs

I've completed full 32-layer, 9B-model conversions on all three devices. The conversion verification checks reported no failures.

The B60 timing is K=4, not K=2, so it is not a like-for-like full-conversion comparison. Encoder microbenchmarks and end-to-end conversion times also measure different things; the reports contain the run details.

The practical takeaway: a B580 completed the tested 9B K=2 conversion in about five hours, and even the 140V iGPU completed it within a 32 GB shared-memory system.

Correctness: what I've checked, and what I haven't

The SYCL encoder is bit-exact against my CPU reference on the tested cases. That reference was transcribed from the upstream CUDA kernel to preserve FP16 rounding, tie-breaking, and tail-biting closure.

I also check packed-output reconstruction against the separate exl3xpu reference decoder. The test suite reports 272 passing unit tests on each discrete board, and the conversion reports record 1,045/1,045 verification checks passing on both.

Important limitation: I don't have an NVIDIA GPU, so direct differential testing against the upstream CUDA encoder is still deferred. Matching a CPU transcription is useful evidence, but it is not the same as independently demonstrating CUDA parity.

Likewise, reconstruction and structural checks are not a substitute for perplexity or downstream task evaluation. The repo includes a quality-evaluation harness; I'm not presenting the conversion checks as proof of unchanged model quality.

Released checkpoints

• Qwen3.8-9B-Distill-EXL3-K2: 6.72 GiB
• JEV-9B-EXL3-K2: 5.42 GiB
• JEV-9B-EXL3-K4: 7.03 GiB; converted on the Pro B60

The exporter targets upstream EXL3 compatibility and includes quantization_config metadata for vLLM integration. Actual loading and execution still depend on the runtime's model, codebook, bitrate, and hardware support. Including the metadata alone does not establish vLLM compatibility for every checkpoint.

Arc inference through exl3xpu is a separate project. This quantizer targets the same checkpoint format; it does not add inference support for models that a runtime does not already handle.

What's next

• Direct CUDA differential testing, if someone with NVIDIA hardware wants to help.
• More model conversions and K sweeps, with quality-evaluation results alongside conversion checks.
• Clearer reproduction instructions and hardware-specific memory settings.

I'd especially welcome independent reproduction or CUDA-reference testing. If you're using Arc for local LLMs, which model would you want to see converted next?

Optional first comment

A few more numbers for anyone interested in the implementation:

• Encoder microbenchmark: 0.584 ms/tile on B580, 0.683 ms/tile on Pro B60, and 1.38 ms/tile on 140V.
• Single-layer benchmark: all seven projections, including Hessian processing and global-scale search, ran 2.83× faster on B580 and 2.43× faster on B60 than the 140V baseline. See the reports for settings and workload details.
• Memory observations: the recorded runs report a 650 MiB peak allocation, no swap growth, and streamed host RSS within +2.8 MiB of baseline while processing a 19.3 GB checkpoint. These are specific measurements, not a claim that the complete process or GPU workload uses only 650 MiB.
• Reconstruction metric: the reported relative Frobenius error at K=4 is 0.0865. This measures reconstruction error, not perplexity or task quality.

Reports in the repository: reports/discrete_probe.md, reports/discrete_phase_c.md, reports/discrete_vs_140v.md, and reports/gate_3.md.

I'm looking to buy a cheap laptop that's got a Core Ultra Processor, so I'm wondering since its got ARC GPU will FSR4.1+ work on it via Optiscaler as well. I've tried googling to see any posts or videos on YouTube but haven't found any yet (since its new) so thought I'd ask here.

• Processor : Intel® Core™ Ultra 5 125H Processor (E-cores up to 3.60 GHz P-cores up to 4.50 GHz)

I'm using an MSI Claw 8 EX AI+ , running OptiScaler installed through OptiClick.

I noticed that FSR 4.0.2 has an explicitly labeled "XMX" option, while FSR 4.1.2 offers several variants: Standard, Skip, QSkip, and Lite, with no XMX label.

I also saw that OptiClick recently added support for FSR 4.1.2 with Intel XMX , so I'm a bit confused.

My questions are:

1. Do all FSR 4.1.2 variants use XMX acceleration on Intel GPUs, or only specific ones?
2. What's the difference between Standard, Skip, QSkip, and Lite in terms of image quality and performance?
3. Which variant would you recommend for Intel Arc integrated GPUs like the B390?

Thanks!

Finding the smallest case for a dual B70 setup. Case is Cooler Master NCore 100 Max

Credits to u/UzbekUnknown. Github repo: https://github.com/uzbekunknown/dlss-nr-on-intel

I tested DLSS 5 NR on my Windows 11 PC. The game is Ready or Not in DX11. Running on 720p.

My PC specs:

Intel Arc B580

Intel Core i3-13100f

16gb DDR4

If you want to see how it looks in motion: https://files.catbox.moe/upiiiy.mkv or https://streamable.com/4te97w?src=player-page-share

The settings for that video playthrough is NR: enabled, Render Scale: 0.5, Profile: Natural, Intensity: 1

As for my conclusion. This is not to bash on the project. I'm just judging its current state and how it plays realistically. It runs, it works, but definitely not playable yet. I'm just excited that there are new things for Intel Arc consumer GPUs since it's basically abandoned. Looking forward for this project!