MagicBeanDev/Longshot

Watch

Fork 72

Game: up-front shader preparation does not finish on Intel Arc (Windows) with compiles one at a time #407

New issue

Open

opened 2026-11-14 10:17:01 +00:00 by mooki · 3 comments

mooki commented

2026-11-14 10:17:01 +00:00

Member

Longshot version

Native Windows development build of main cf605c85bbaeaaa78176b933b3bc1a3366e13a78. Its log reports cf605c85 (source 8672daee).

The long failing run used the co-op development build 1ed75e61b5bc083247950a262b1a48230f44909a, based on that main commit. Its log reports unknown (source c058db8c).

These are source builds, not a released or nightly package.

Channel

Built from source

What kind of problem

Something else

What happened

The shader preparation before play can sit without visible progress for minutes. In the long run below, it ended itself with “the GPU driver stopped responding” after five minutes without a progress change. It left a marker telling later starts to build the remaining shaders during play instead.

Main build, source 8672daee: one preparation-only observation, stopped by a quit request after 391.876 seconds, exit 0. It did not finish preparing shaders, but the watchdog did not fire during this bounded run. Before starting, there was no .warming or skipped-preparation marker. Existing caches held 555 program keys, about 69.1 MB of translated programs and 59.7 MB of driver pipeline data. No marker was manually changed.

Elapsed time on main	Reported shader-program counter
Initialization	0/0 before the total was established; first populated counter 217/38,809
1 minute	258/38,809
2 minutes	261/38,809
3 minutes	263/38,809
4 minutes	266/38,809
5 minutes	345/38,809
6 minutes	363/38,809
About 390 seconds, before quit	399/38,809

The longest reported pause on main was 57 seconds. During a 59.97-second CPU sample, the process used 60.11 CPU-seconds, roughly one logical CPU, while reporting 22 preparation workers.

Co-op build, source c058db8c: the uninterrupted run ended itself after 97.51 minutes, exit 4, at 262/38,809. The final five minutes had no displayed-counter advance. From the approximately 30-minute observation until exit, it advanced at about 7.2 completed work slots per minute. The displayed counter is completed slots divided by three and includes skipped variants; it is not a count of successful distinct driver compiles. An earlier one-minute sample used 59.47 CPU-seconds in 60 seconds.

A subsequent bounded co-op retry retained its cache and markers. The surviving .warming marker automatically omitted seed-pass driver warming. The seed phase finished in 57.7 seconds, reporting 0 compute pipelines and 70 failed results, then continued into noted pipelines. A quit request ended it after 390.160 seconds, exit 0, still incomplete. This changed retry path is not a matched speed comparison or proof that the original stall was fixed.

Neither build logged VK_ERROR_DEVICE_LOST or a caught driver fault. Both logged a compute translation failure for 79116b290d46542f and intentional network exclusions. The watchdog's message alone does not establish an actual device loss. The exact program and thread inside the driver at the long run's stop remain unknown.

The Intel setting has only two values, read at startup:

intel_shader_compiles=0: One at a time.
intel_shader_compiles=1: Side by side.
Values 2, 4 and 8 are clamped to 1, not interpreted as thread counts.

At main cf605c85, these are defined in gpu/vk/vk_menu.h:86-87 and gpu/vk/vk_menu.cpp:1414-1415; the INI clamp is at line 4153. The gate caches the startup choice in gpu/vk/vk_internal.h:132-135.

	`int intel_compiles = 0; // (longshot) Intel's shader compiler on Windows: 0 one thread at a time, 1 side by side (vk_internal.h`
	`// IntelDriverGate; RX_VK_NO_INTEL_SERIAL=1 over it). Read once, at the start`

	`{TAB_DEBUG, "Intel shader compiles", &opts.intel_compiles, 0, 1, 1, tx_intel_compiles,`
	`"Intel graphics: how many shaders Intel's compiler is given at once. Applies after a restart.", hn_intel_compiles, true, true},`

*r.value = r.value == &opts.output_res ? parse_output(eq + 1) : std::min(std::max(v, r.lo), r.hi);

 inline bool intel_gate_on() {
 #ifdef _WIN32
     static const bool on = !intel_compiles_side_by_side() && dev.props.vendorID == 0x8086;
     return on;

Not tried: Side by side, another driver or a different process priority. Side by side was left untested because a driver hang on this unattended PC could require a restart. Both sampled processes ran at BelowNormal priority. The builds and cache states differ, so their rates are not a controlled comparison.

What would help decide: a per-program timer around compute warming, recording the program key, variant, thread ID, start/end times and time waiting for the Intel gate. Existing compute diagnostics do not provide that paired record, and the last saved cache entry does not identify the blocked call.

Related discussions:

#252

#15

#190 (comment)

Where in the game

Before the title screen, during up-front shader preparation with --prepare-shaders. No gameplay was involved.

How often

Once so far

Graphics card and driver version

Intel Arc integrated graphics in a Core Ultra 9 185H, PCI device 0x7D55. Intel driver 32.0.101.9175, Vulkan 1.4.

CPU, RAM and operating system

Intel Core Ultra 9 185H, 16 cores and 22 logical processors, 64 GB RAM, Windows 11 Pro.

Changes from the defaults

Preparation-only, without a game window, with Compile shaders set to Most.
Intel shader compiles remained One at a time (intel_shader_compiles=0).
Native float atomic add was selected automatically on main. The co-op runs explicitly used RX_VK_NATIVE_FADD=1, matching this hardware and driver's default.
RX_VK_PREPARE_STATUS_S=1 on main and the short co-op retry; the long run used the normal status cadence. The 300-second watchdog was unchanged.
The short co-op retry also used RX_VK_IR=log and RX_VK_PTR_DIAG=1 for diagnostic text. No shader dumps were produced.
Process priority was BelowNormal and was not changed. Co-op and hosting were off; sound, Discord presence and frame generation were off.
Caches were retained. No warming or skipped-preparation marker was manually deleted or created.

longshot_log.txt

Main development build:

[hos host] longshot cf605c85 (source 8672daee)
[hos host] vk: float atomic add on storage buffers: native (VK_EXT_shader_atomic_float), Intel's Windows driver, Meteor Lake or Arrow Lake
[hos host] vk: driver: Intel Corporation 101.9175
[hos host] vk: preparation: 22 workers for the shader programs (22 CPUs usable; the segment heap: as many as the free memory allows)
[hos host] vk: Intel's compiler is entered by one thread (Intel shader compiles row, RX_VK_NO_INTEL_SERIAL: side by side)
[hos host] vk: preparation: waiting: nothing in the shader programs has finished for 57 s (263 of 38809), waiting on the GPU driver or the disk. Stopped at 300 s if nothing moves
[hos host] control: quit asked by a client
[hos host] control: exiting

Long co-op-build run:

[hos host] longshot unknown (source c058db8c)
[hos host] vk: preparation: waiting: nothing in the shader programs has finished for 296 s (262 of 38809), waiting on the GPU driver or the disk. Stopped at 300 s if nothing moves
[hos host] vk: preparation: STOPPED: nothing moved for 300 s in the shader programs (262 of 38809): the GPU driver stopped responding. The rest is built in play, when first drawn; updating the GPU driver may help

These are text excerpts only. No caches, game files, executable or saves are attached.

Screenshots or video

None. These observations ran without a game window.

Before you send it

The problem is still there on the newest release or nightly.
I searched the open issues for it.
I'm not attaching game files, keys, the game's executable, its .bin caches or saves.

The first box is not asserted: the observations above are on the named development source builds, not a freshly tested release or nightly. The main observation did not reproduce the watchdog exit within its time limit.

### Longshot version Native Windows development build of main `cf605c85bbaeaaa78176b933b3bc1a3366e13a78`. Its log reports `cf605c85 (source 8672daee)`. The long failing run used the co-op development build `1ed75e61b5bc083247950a262b1a48230f44909a`, based on that main commit. Its log reports `unknown (source c058db8c)`. These are source builds, not a released or nightly package. ### Channel Built from source ### What kind of problem Something else ### What happened The shader preparation before play can sit without visible progress for minutes. In the long run below, it ended itself with “the GPU driver stopped responding” after five minutes without a progress change. It left a marker telling later starts to build the remaining shaders during play instead. **Main build, source 8672daee:** one preparation-only observation, stopped by a quit request after **391.876 seconds**, exit **0**. It did not finish preparing shaders, but **the watchdog did not fire during this bounded run**. Before starting, there was no `.warming` or skipped-preparation marker. Existing caches held 555 program keys, about 69.1 MB of translated programs and 59.7 MB of driver pipeline data. No marker was manually changed. | Elapsed time on main | Reported shader-program counter | |---|---:| | Initialization | 0/0 before the total was established; first populated counter 217/38,809 | | 1 minute | 258/38,809 | | 2 minutes | 261/38,809 | | 3 minutes | 263/38,809 | | 4 minutes | 266/38,809 | | 5 minutes | 345/38,809 | | 6 minutes | 363/38,809 | | About 390 seconds, before quit | 399/38,809 | The longest reported pause on main was **57 seconds**. During a 59.97-second CPU sample, the process used **60.11 CPU-seconds**, roughly one logical CPU, while reporting 22 preparation workers. **Co-op build, source c058db8c:** the uninterrupted run ended itself after **97.51 minutes**, exit **4**, at **262/38,809**. The final five minutes had no displayed-counter advance. From the approximately 30-minute observation until exit, it advanced at about **7.2 completed work slots per minute**. The displayed counter is completed slots divided by three and includes skipped variants; it is not a count of successful distinct driver compiles. An earlier one-minute sample used **59.47 CPU-seconds in 60 seconds**. A subsequent bounded co-op retry retained its cache and markers. The surviving `.warming` marker automatically omitted seed-pass driver warming. The seed phase finished in **57.7 seconds**, reporting **0 compute pipelines and 70 failed results**, then continued into noted pipelines. A quit request ended it after **390.160 seconds**, exit **0**, still incomplete. This changed retry path is not a matched speed comparison or proof that the original stall was fixed. Neither build logged `VK_ERROR_DEVICE_LOST` or a caught driver fault. Both logged a compute translation failure for `79116b290d46542f` and intentional network exclusions. The watchdog's message alone does not establish an actual device loss. The exact program and thread inside the driver at the long run's stop remain unknown. The Intel setting has only two values, read at startup: - `intel_shader_compiles=0`: One at a time. - `intel_shader_compiles=1`: Side by side. - Values 2, 4 and 8 are clamped to 1, not interpreted as thread counts. At main `cf605c85`, these are defined in `gpu/vk/vk_menu.h:86-87` and `gpu/vk/vk_menu.cpp:1414-1415`; the INI clamp is at line 4153. The gate caches the startup choice in `gpu/vk/vk_internal.h:132-135`. https://git.magicbean.dev/MagicBeanDev/Longshot/src/commit/cf605c85bbaeaaa78176b933b3bc1a3366e13a78/gpu/vk/vk_menu.h#L86-L87 https://git.magicbean.dev/MagicBeanDev/Longshot/src/commit/cf605c85bbaeaaa78176b933b3bc1a3366e13a78/gpu/vk/vk_menu.cpp#L1414-L1415 https://git.magicbean.dev/MagicBeanDev/Longshot/src/commit/cf605c85bbaeaaa78176b933b3bc1a3366e13a78/gpu/vk/vk_menu.cpp#L4153 https://git.magicbean.dev/MagicBeanDev/Longshot/src/commit/cf605c85bbaeaaa78176b933b3bc1a3366e13a78/gpu/vk/vk_internal.h#L132-L135 **Not tried:** Side by side, another driver or a different process priority. Side by side was left untested because a driver hang on this unattended PC could require a restart. Both sampled processes ran at BelowNormal priority. The builds and cache states differ, so their rates are not a controlled comparison. **What would help decide:** a per-program timer around compute warming, recording the program key, variant, thread ID, start/end times and time waiting for the Intel gate. Existing compute diagnostics do not provide that paired record, and the last saved cache entry does not identify the blocked call. Related discussions: https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/252 https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/15 https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/190#issuecomment-15831 ### Where in the game Before the title screen, during up-front shader preparation with `--prepare-shaders`. No gameplay was involved. ### How often Once so far ### Graphics card and driver version Intel Arc integrated graphics in a Core Ultra 9 185H, PCI device 0x7D55. Intel driver 32.0.101.9175, Vulkan 1.4. ### CPU, RAM and operating system Intel Core Ultra 9 185H, 16 cores and 22 logical processors, 64 GB RAM, Windows 11 Pro. ### Changes from the defaults - Preparation-only, without a game window, with Compile shaders set to Most. - Intel shader compiles remained One at a time (`intel_shader_compiles=0`). - Native float atomic add was selected automatically on main. The co-op runs explicitly used `RX_VK_NATIVE_FADD=1`, matching this hardware and driver's default. - `RX_VK_PREPARE_STATUS_S=1` on main and the short co-op retry; the long run used the normal status cadence. The 300-second watchdog was unchanged. - The short co-op retry also used `RX_VK_IR=log` and `RX_VK_PTR_DIAG=1` for diagnostic text. No shader dumps were produced. - Process priority was BelowNormal and was not changed. Co-op and hosting were off; sound, Discord presence and frame generation were off. - Caches were retained. No warming or skipped-preparation marker was manually deleted or created. ### longshot_log.txt Main development build: ```text [hos host] longshot cf605c85 (source 8672daee) [hos host] vk: float atomic add on storage buffers: native (VK_EXT_shader_atomic_float), Intel's Windows driver, Meteor Lake or Arrow Lake [hos host] vk: driver: Intel Corporation 101.9175 [hos host] vk: preparation: 22 workers for the shader programs (22 CPUs usable; the segment heap: as many as the free memory allows) [hos host] vk: Intel's compiler is entered by one thread (Intel shader compiles row, RX_VK_NO_INTEL_SERIAL: side by side) [hos host] vk: preparation: waiting: nothing in the shader programs has finished for 57 s (263 of 38809), waiting on the GPU driver or the disk. Stopped at 300 s if nothing moves [hos host] control: quit asked by a client [hos host] control: exiting ``` Long co-op-build run: ```text [hos host] longshot unknown (source c058db8c) [hos host] vk: preparation: waiting: nothing in the shader programs has finished for 296 s (262 of 38809), waiting on the GPU driver or the disk. Stopped at 300 s if nothing moves [hos host] vk: preparation: STOPPED: nothing moved for 300 s in the shader programs (262 of 38809): the GPU driver stopped responding. The rest is built in play, when first drawn; updating the GPU driver may help ``` These are text excerpts only. No caches, game files, executable or saves are attached. ### Screenshots or video None. These observations ran without a game window. ### Before you send it - [ ] The problem is still there on the newest release or nightly. - [x] I searched the open issues for it. - [x] I'm not attaching game files, keys, the game's executable, its .bin caches or saves. The first box is not asserted: the observations above are on the named development source builds, not a freshly tested release or nightly. The main observation did not reproduce the watchdog exit within its time limit.

mooki added the

kind

bug

label

2026-11-14 10:17:01 +00:00

mooki commented

2026-11-14 13:17:18 +00:00

Author

Member

Follow-up to "Not tried: Side by side" above. Tried now, with someone at the PC in case the driver hung, on the same native main cf605c85 (source 8672daee), Core Ultra 9 185H / Intel Arc, Windows 11, driver 32.0.101.9175.

Both preparation runs started from byte-identical copies of the existing 591,471,179-byte cache. I moved only the interrupted-warming marker aside in both starting copies, so neither skipped the seed's driver-warm pass. Both loaded 864 program keys and the same driver pipeline cache. Compile shaders was Most; priority stayed BelowNormal.

Process age	One at a time	Side by side
60 s	467 / 38,809	794 / 38,809
120 s	497 / 38,809	1,195 / 38,809
180 s	533 / 38,809	1,546 / 38,809
240 s	544 / 38,809	1,746 / 38,809

The one-minute CPU samples used 63.70 CPU-seconds in 59.96 seconds and 1,135.53 in 59.95 seconds, about 1.06 versus 18.94 busy logical CPUs. These are the game's displayed preparation counters, not successful distinct driver compiles.

Both answered quit and exited 0, at 241.082 and 242.172 seconds. Neither completed preparation or logged device loss, a caught driver fault or a watchdog stop. Both retained the known 79116b290d46542f translation failure. Side by side was selected only for the process with RX_VK_NO_INTEL_SERIAL=1; no saved option was changed. This binary logs the serial gate positively but has no corresponding positive Side-by-side log line.

This is one ordered pair on one PC and driver, not a full-preparation result, a general speed claim or a guarantee of stability.

Keeping P's cache, I then loaded the test save and stood where it starts, with Side by side on. The native option reply confirmed value1, “Side by side”. That run exited0 after 385.511 seconds, with 325.7 seconds between the first and last observed play states and no device-loss or driver-fault line. The inspected final picture shows Link, Navi and the HUD inside Link's house.

Corrected 14 November: this paragraph first said the run stood in the forest. The test save starts inside Link's house (the game reports the map as Kokiri Forest, but the scene and its music are the house's), and the picture shows that room. So this play run is a light indoor scene and says nothing about the open forest. Two nonfatal write-back wait timeouts occurred while loading. This was warm-cache play, not a repeated cold compile stress test.

The original cache, including its warming marker, is now restored. The saved options file is byte-identical to before the test.

Follow-up to "Not tried: Side by side" above. Tried now, with someone at the PC in case the driver hung, on the same native main `cf605c85` (`source 8672daee`), Core Ultra 9 185H / Intel Arc, Windows 11, driver **32.0.101.9175**. Both preparation runs started from byte-identical copies of the existing 591,471,179-byte cache. I moved only the interrupted-warming marker aside in both starting copies, so neither skipped the seed's driver-warm pass. Both loaded 864 program keys and the same driver pipeline cache. Compile shaders was Most; priority stayed BelowNormal. | Process age | One at a time | Side by side | |---:|---:|---:| | 60 s | 467 / 38,809 | 794 / 38,809 | | 120 s | 497 / 38,809 | 1,195 / 38,809 | | 180 s | 533 / 38,809 | 1,546 / 38,809 | | 240 s | 544 / 38,809 | 1,746 / 38,809 | The one-minute CPU samples used **63.70 CPU-seconds in 59.96 seconds** and **1,135.53 in 59.95 seconds**, about **1.06 versus 18.94 busy logical CPUs**. These are the game's displayed preparation counters, not successful distinct driver compiles. Both answered quit and exited 0, at 241.082 and 242.172 seconds. Neither completed preparation or logged device loss, a caught driver fault or a watchdog stop. Both retained the known `79116b290d46542f` translation failure. Side by side was selected only for the process with `RX_VK_NO_INTEL_SERIAL=1`; no saved option was changed. This binary logs the serial gate positively but has no corresponding positive Side-by-side log line. This is one ordered pair on one PC and driver, not a full-preparation result, a general speed claim or a guarantee of stability. Keeping P's cache, I then loaded the test save and stood where it starts, with Side by side on. The native option reply confirmed value1, “Side by side”. That run exited0 after **385.511 seconds**, with **325.7 seconds between the first and last observed play states** and no device-loss or driver-fault line. The inspected final picture shows Link, Navi and the HUD inside Link's house. *Corrected 14 November: this paragraph first said the run stood in the forest. The test save starts inside Link's house (the game reports the map as Kokiri Forest, but the scene and its music are the house's), and the picture shows that room. So this play run is a light indoor scene and says nothing about the open forest.* Two nonfatal write-back wait timeouts occurred while loading. This was warm-cache play, not a repeated cold compile stress test. The original cache, including its warming marker, is now restored. The saved options file is byte-identical to before the test.

thomas-montano referenced this issue

2026-11-14 13:21:39 +00:00

WIP: fix(vk): Mesa's Intel driver finishes the shader preparation on an Iris Xe #426

honda233 referenced this issue

2026-11-14 15:20:58 +00:00

Game: shader preparation hard-freezes the whole PC (no TDR, no watchdog) — RX 9070 XT, Windows #462

nyannoying commented

2026-11-14 16:18:38 +00:00

Numbers from an Arc B580 for this, in play rather than in the preparation: with One at a time a first visit to an area freezes the picture for minutes; with Side by side it does not freeze at all, and nothing faulted in ten areas.

Arc B580 12 GB, driver 32.0.101.9154, Core i5-13600K (20 threads, 6 background workers), 64 GB, Windows 11. A source build of main cf605c85 with the B580 fixes of #443, #444 and #446 in (main alone loses the device on this card), a game folder never prepared (RX_VK_PRECOMPILE=0), each area entered by the debug teleport for the first time on this PC. An area can be new only once, so the two settings were run in different areas; the programs counted are the log's vk: in play: lines.

Setting	Area	New programs	Picture under 5 fps	Steady (25 fps or more) after
One at a time (default)	Hyrule Field	398	248 s	about 250 s
One at a time (default)	Market	322	409 s	about 410 s
One at a time, `RX_VK_TRANSLATE_WAIT_MS=8`	Graveyard	134	73 s	134 s
Side by side (`RX_VK_NO_INTEL_SERIAL=1`)	Kakariko Village	155	0 s	52 s
Side by side, `RX_VK_TRANSLATE_WAIT_MS=8`	Goron City	106	0 s	30 s
Side by side, one launch through eight areas	Zora's River, Zora's Domain, Death Mountain Trail, Lost Woods, Gerudo Valley, Deku Tree, Dodongo's Cavern, Desert Colossus	850	0 s polled	20 to 80 s each

One at a time: the log's translation ... ms in all reached 158,713 ms after Hyrule Field and 541,531 ms after the Market; side by side it was 1,636 ms after Kakariko. Both timers start before the gate, so most of that is queueing at the lock, not translating.
Side by side, three launches, 1,111 programs first compiled: no VK_ERROR_DEVICE_LOST, no fault line, no exit, and the areas looked at are drawn right. RX_VK_COMPUTE_SERIAL was left at its default.
With the gate on, the six workers run about one logical CPU; that matches the one CPU of the preparation above.

So on Battlemage with this driver the gate costs minutes a new area and its reason (igvk64 faulting with two threads in it) did not show. I am preparing a pull request that makes Side by side the default on the Arc B-series from 101.9154, the family and driver it was run on, and leaves every other Intel GPU as it is; the up-front preparation on this card is not measured yet.

Numbers from an Arc B580 for this, in play rather than in the preparation: with **One at a time** a first visit to an area freezes the picture for minutes; with **Side by side** it does not freeze at all, and nothing faulted in ten areas. Arc B580 12 GB, driver 32.0.101.9154, Core i5-13600K (20 threads, 6 background workers), 64 GB, Windows 11. A source build of main cf605c85 with the B580 fixes of #443, #444 and #446 in (main alone loses the device on this card), a game folder never prepared (`RX_VK_PRECOMPILE=0`), each area entered by the debug teleport for the first time on this PC. An area can be new only once, so the two settings were run in different areas; the programs counted are the log's `vk: in play:` lines. | Setting | Area | New programs | Picture under 5 fps | Steady (25 fps or more) after | |---|---|---|---|---| | One at a time (default) | Hyrule Field | 398 | 248 s | about 250 s | | One at a time (default) | Market | 322 | 409 s | about 410 s | | One at a time, `RX_VK_TRANSLATE_WAIT_MS=8` | Graveyard | 134 | 73 s | 134 s | | Side by side (`RX_VK_NO_INTEL_SERIAL=1`) | Kakariko Village | 155 | 0 s | 52 s | | Side by side, `RX_VK_TRANSLATE_WAIT_MS=8` | Goron City | 106 | 0 s | 30 s | | Side by side, one launch through eight areas | Zora's River, Zora's Domain, Death Mountain Trail, Lost Woods, Gerudo Valley, Deku Tree, Dodongo's Cavern, Desert Colossus | 850 | 0 s polled | 20 to 80 s each | - One at a time: the log's `translation ... ms in all` reached 158,713 ms after Hyrule Field and 541,531 ms after the Market; side by side it was 1,636 ms after Kakariko. Both timers start before the gate, so most of that is queueing at the lock, not translating. - Side by side, three launches, 1,111 programs first compiled: no `VK_ERROR_DEVICE_LOST`, no fault line, no exit, and the areas looked at are drawn right. `RX_VK_COMPUTE_SERIAL` was left at its default. - With the gate on, the six workers run about one logical CPU; that matches the one CPU of the preparation above. So on Battlemage with this driver the gate costs minutes a new area and its reason (igvk64 faulting with two threads in it) did not show. I am preparing a pull request that makes Side by side the default on the Arc B-series from 101.9154, the family and driver it was run on, and leaves every other Intel GPU as it is; the up-front preparation on this card is not measured yet.

nyannoying referenced this issue

2026-11-14 16:52:47 +00:00

perf(vk): the Arc B-series compiles shaders side by side by default: a new area no longer freezes the picture for minutes #500

nyannoying commented

2026-11-14 16:53:18 +00:00

The pull request for the Arc B-series is #500 : the row gets an Auto value, its default, which is side by side on Battlemage from driver 101.9154 and one at a time on every other Intel GPU. One build, the default against RX_VK_NO_INTEL_SERIAL=0: 373 new programs with no frame under 5 fps against 372 with 181 s of it.

The pull request for the Arc B-series is https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/500 : the row gets an Auto value, its default, which is side by side on Battlemage from driver 101.9154 and one at a time on every other Intel GPU. One build, the default against RX_VK_NO_INTEL_SERIAL=0: 373 new programs with no frame under 5 fps against 372 with 181 s of it.

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MagicBeanDev/Longshot#407

No description provided.

Rows
Columns