EA Sports UFC 6 (PPSA23566)

[0xcrstn]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

EA SPORTS UFC 6 (PPSA23566)

Content version tested

01.004.000

AnyPS5 commit

Fork commit c222bd2 (ufc6/testing): 0xcrstn@c222bd2 — tested upstream base 84b01f9, plus local bring-up/performance fixes. No upstream PRs opened for this report.

System tested

Windows 11 Pro; Intel i9-13900K; 64 GB RAM; NVIDIA RTX 5090, driver 32.0.16.1742; WinLibs MinGW-w64 GCC 15.2.0 r7, Release + libs.

Furthest point

In game

What is shown

EA SPORTS UFC 6 now reaches an interactive octagon fight on my Windows setup. Fighters, the referee and the tutorial HUD render, and gameplay input works. Performance is still far below playable speed.

The final sampled gameplay minute recorded 127 presents in 61.330 seconds, about 2.07 FPS, with six reporting windows ranging from 1.90 to 2.14 presents/s. This is a late-fight sample, not a whole-match average. I noticed an improvement of roughly 0.2–0.5 FPS compared with earlier runs, but I do not have a controlled before/after benchmark.

Gameplay showcase

These clips come from a separate showcase recording of the same installed build. The measurements below come from the completed validation run. Both attachments were compressed to fit GitHub's 10 MB upload limit.

Real-time — 6 minutes 57 seconds, with game audio. Original timing is preserved; this attachment is a 480p, 10 FPS video export. Its encoding frame rate is not the game's measured FPS.

UFC6-2026-10-14_21-12-55-realtime-github-10mb.mp4

Sped-up — 18.18 seconds, silent, 60 FPS playback. Duplicate pictures were removed and the retained frames retimed, giving roughly 23× average speed-up with variable speed. This is a 720p showcase edit, not native 60 FPS gameplay; the video also carries a burned-in sped-up label.

UFC6-2026-10-14_21-12-55-sped-up-60fps-github-10mb.mp4

Recorded resource usage

These figures come from the completed 14 October 2026, 20:44–20:59 EEST validation run, with the diagnostics and verification settings listed below. They describe observed usage on this machine, not minimum hardware requirements. Memory was sampled every 60 seconds; the final values below were also the highest captured memory samples, so brief peaks between samples may be missed.

Resource	Recorded result
Resident process RAM / working set	20.23 GiB in the final memory sample.
Process commit	32.32 GiB, also the reported peak commit. This is committed process memory, not physical RAM usage.
VRAM / Vulkan device-local heap	10,191 MiB / 9.95 GiB used, against a driver-reported budget of 31,419 MiB / 30.68 GiB.
Vulkan host-memory heap	5,254 MiB / 5.13 GiB used. This overlaps other memory accounting; it is not extra RAM to add to the figures above.
GPU activity from application timestamps	Final present report: 213.2 ms busy + 312.8 ms of gaps per frame, about 40.5% busy within that recorded timeline. This is a derived queue-timing figure, not a Task Manager or NVIDIA utilization reading.
CPU utilization	Total process/system CPU percentages were not recorded for this run. The draw profiler recorded 8.20 seconds of aggregated draw-path elapsed time over a 10.00-second interval; those timers include waits and do not measure total CPU utilization.

Process commit includes GPU-driver mappings; it should not be added to working set or VRAM as an independent physical-memory requirement. Whole-machine RAM usage, hardware CPU/GPU utilization percentages, temperatures and power draw were not captured in this completed run.

What changed

The fork carries the accumulated UFC bring-up and correctness fixes, including memory-coherence and shader-read fixes retained while reconciling upstream changes. The latest combined changes:

• Reuse cached vertex layouts during pipeline prewarming.
• Restrict arena snapshot copies to proven read ranges where possible, retaining coverage and in-flight ownership checks.
• Compile eligible compute pipelines ahead of demand with two workers and a bounded request queue; share concurrent requests for the same pipeline.
• Separate verification and pipeline-preparation costs in draw diagnostics, and report the actual elapsed interval.

The new paths are exercised: 108 pipelines built ahead were subsequently consumed, with no recorded background compilation failures. Sparse copies also occur, but avoid little of the total copying in this workload so far. These counters establish that the paths run; they do not measure each patch's FPS benefit.

The complete run recorded 33,324,722 low-level dirty-set checks with zero disagreements, plus 6,196,738 binding decode comparisons and 12,405,294 stage comparisons with zero differences. Full arena byte verification was disabled, so this is not complete rendering or snapshot-byte validation.

These FPS numbers describe the verification-enabled configuration. Epoch VERIFY retained reference revalidation and reported zero production revalidation skips; this run does not measure the benefit of that early-return path.

The earlier bright cyan crowd/lighting patches were not obvious in the two inspected fight views, and gameplay currently looks good to me. Other cameras and scenes still need testing.

Current blocker

1. Low sustained FPS. One late ten-second interval still copied 6,646 MiB into draw snapshots. Unbounded draw indices accounted for most full-copy traffic. GPU time also remains substantial: the final present report recorded 213.2 ms busy and 312.8 ms of gaps per present. CPU verification adds overhead, but copying, other draw work and GPU execution remain separate costs. These overlapping measurements cannot be added into a frame-time breakdown.
2. Frame waits still time out. There were 13 SubmissionManagerPs5::waitForFrame failures with error 0x8002003C, despite continued gameplay. The run ended with exit code 0; that does not make it error-free.
3. Shader and pipeline stalls remain. Cold graphics pipeline creation reached 4.075 seconds. The new compilation-ahead path covers eligible compute work, not graphics pipeline creation. Deferred shader-preparation and storage-image ownership diagnostics remain tracked.

Release/library builds and 148 selected CTests passed, together with two full recorder configurations. One initial PM4 teardown hang did not recur in 11 repeats; its cause remains unresolved. Some watched-host-import test subcases are unavailable on Windows. Other game modes and a complete match have not been validated.

How it was run

Check out the exact fork commit above, initialize its submodules, and follow the project's Windows build and runtime-layout instructions. Build both Release and libs, and use --windows --to-intel --registry --module-dir .. Installed AnyPS5 libraries must come from that build. The title's own modules are relinker inputs.

The performance/correctness settings used were:

APS5_WORKER_AFFINITY=1
APS5_STORE_AT_FLIP=1
APS5_DRAW_SNAPSHOT_ARENA=1
APS5_DRAW_SNAPSHOT_ARENA_EXTEND_KIB=1024
APS5_BINDING_PLAN=1
APS5_VERIFY_BINDING_PLAN=1
APS5_EPOCH_DIRTY_SET=1
APS5_VERIFY_EPOCH_DIRTY_SET=1
APS5_EPOCH_DIRTY_SET_WIDEN_KIB=256
APS5_PIPELINE_COMPILE_AHEAD=1
APS5_PIPELINE_COMPILE_THREADS=2
APS5_NO_GPL=1
APS5_NO_SHARED_FLOAT_FUNCTIONS=1
APS5_LAZY_STAGING_OUT=0
APS5_ARENA_DEVICE_TWINS=0

Diagnostics were enabled with APS5_PROFILE_DRAW=1, APS5_PROFILE_GPU=1, APS5_TRACE_WRITE_TRACKING=1, APS5_TRACE_EPOCH_DIRTY_SET=1, APS5_TRACE_LATE_LABELS=1, APS5_TRACE_HANDLED_FAULTS=1, and APS5_MEMORY_REPORT=60. Frame capture used APS5_DUMP_FRAMES=100000, APS5_DUMP_FRAMES_EVERY=60, and APS5_DUMP_SCALE=2. A local shader-cache directory was selected with ANYPS5_SHADER_CACHE_DIR. The changed compiler fingerprint meant a cold shader-artifact cache, while an existing approximately 463 MiB Vulkan pipeline cache loaded.

Honest summary

Interactive gameplay is reached, the reference checks above agree, and there is a small subjective performance improvement. The game is still too slow, frame timeouts remain, and neither a controlled performance gain nor complete graphical correctness has been established. This post shares the exact fork revision for further investigation.

AI-assisted: yes.

[fma-rc]

Your fork also gets UFC 6 in game on Linux (Arch, RTX 5080, GCC 16.2), with two things on top.

It doesn't build on Linux as pushed: two size checks in ShaderDiskCache.cpp hold only on MinGW. Here sizeof(BindingAllocationResult) is 200 (check says 152) and sizeof(IrResourcePlan) is 600 (check says 584). I changed the two numbers locally.

Linux also needs #5955. Without it the title stops at 7 s with guest protection or unmap range is not registered, because Linux registers only the main image for mprotect and UFC calls it from code in Engine.Render.Core2.PlatformPs5.prx.

With both and your settings: title screen, the roster download dialog, the accessibility screen, then the octagon. That took Cross plus six Down presses to reach CONTINUE. Over the last 400 s it rendered about 1.2 frames per second, and waitForFrame failed with 0x8002003C 34 times, as on your machine. Resident memory stayed between 3.3 and 5.8 GB in a 600 s run without input. Upstream main with #5955 instead grows past 17 GB within 5 s here, so something in your fork fixes that.

[doublesync]

Awesome work so far, I'm really excited for this!

[mcsilva-dev]

Memory: why UFC 6 dies with std::bad_alloc on 32 GB machines

On Windows 11, i5-14600KF, 32 GB RAM, RX 9070 XT, main bebff8b: the process grew ~8 GB/min during start-up until FATAL: C++ exception St9bad_alloc in the shader recompiler (ValidateProgram, MaskedSelectEliminator), ~570 s in, at ~80 GB of commit. The window stayed black until then.

Counting libSceAgcDriver's new/delete by caller showed two holders (details in #6139):

1. Each queued RegisteredPreparation keeps its decoded RDNA program (~1.5 MB; DecodeRdnaProgram reserves one instruction per code word) although only PlanRegistered reads it: 18.7 GB across ~13,000 queued plans. Releasing it after planning removes it; a pull request will follow.
2. Every registered shader keeps its resource plan resident whether or not it is ever drawn: ~10.5 GB from ShaderDiskCache::DecodePlan plus ~3 GB of IrValue::AddArgument. As a local workaround I send every shader down the existing deferred path, prepared at first use.

With both, the process holds ~9.9 GB (stable), the title screen shows in ~30 s with a warm cache, and the main menu is reachable. That is ~11 presents/s at the title screen; I have not reached a fight yet. Your run peaked at 32 GB of commit on a 64 GB machine, which may be why you never hit this.

@0xcrstn your bring-up changes and these memory fixes look complementary; happy to compare notes on performance next.

AI-assisted: yes (Claude Code).

[mcsilva-dev]

Progress report: memory, title-screen frame time, and a fix for the storage upload path (PR #6197)

Setup. Windows 11 Pro (26200), Intel i5-14600KF, 32 GB RAM, AMD Radeon RX 9070 XT (AMD proprietary driver 26.8.1, LLPC), WinLibs GCC 15.2.0, Release + libs, ANYPS5_ENABLE_SPIRV_TOOLS=ON. Content 01.004.000. Scene for every number below: the title screen ("PRESS ANY BUTTON"), warm shader cache, 10 s summary intervals (APS5_TRACE_SUMMARY_EVERY=10) unless stated. The game reaches the main menu and starts the first cutscene here.

1. Memory (details in #6139)

On main the process grew ~8 GB/min during start-up and died with std::bad_alloc in the shader recompiler at ~80 GB of commit. Counting libSceAgcDriver's new/delete by caller found two holders: the decoded RDNA program kept by every queued RegisteredPreparation (18.7 GB) and the resource plans of registered shaders that are never drawn (~13.5 GB). Preparing registered shaders at first use keeps the process at ~10 GB.

@0xcrstn your ufc6/testing (c222bd2) already solves both independently: decoded is a local unless the plan awaits callees, and the registration preparation stops at APS5_REGISTRATION_PREPARE_COMMIT_GB (half the RAM by default). On this 32 GB machine your fork holds ~10.5 GB at the title screen, stable, with no local change.

2. Where the title-screen frame goes

build	frame p50	GPU busy per present	busiest queue worker
main bebff8b (+ first-use preparation)	~90 ms	19 ms	97 %
fork c222bd2	~71 ms	21.5 ms	93 %

The GPU would allow ~50 FPS; the frame is bound by queue worker 0x0. Sampling it (APS5_SAMPLE_WORKER, symbolized with nm) on main: StorageTexture::Refresh 58 % inclusive, of which upload 28 %, writeBack 19 %, captureGuestBytes 17.5 %, compareUntracked 16 %; about a quarter of the self time is memcpy/memcmp. With APS5_TRACE_FLUSH/APS5_TRACE_UPLOAD over ~60 s: 44,207 flushes (all storage refresh) and 23,603 uploads (guest memory changed), all on 137 surfaces in one region at 0x11c0000000 with 549 overlapping pairs: the transient render targets (960x544, 480x272, 240x136, 1600x900, 1920x1080 chains) alias each other.

On the fork the worker splits differently: Refresh 35.5 %, of which upload 30.4 %; inside upload, CommandBatch::Wait 40 % and GuestMemory::ReadCommitted 37 %, i.e. the CPU upload path. APS5_PROFILE_DRAW=1, per 10 s:

[storage] uploads by path (count/MiB, 10 s): clear 0/0.0 direct 6696/5994.0 cpu 1729/6955.0 alias 3240/2929.5; ...
cpu uploads by cause (count/ms): no import 1729/5135.5
write-backs by reason (count/MiB): fast-clear materialization 216/13.5 flip 4339/11899.9 imported buffer region 294/18.4

So ~5.1 s of every 10 s went to CPU uploads whose cause is "no import".

3. Why those surfaces have no import

APS5_TRACE_MEMORY=1 shows how the title builds the pool:

[memory] reserve 00000011c0000000+0x6f424000 flags=0x0 align=0x40000000
[memory] remap fixed 00000011c0000000+0x800000 prot=0xf3 phys=0xb4200000
[memory] remap fixed 00000011c0800000+0x800000 prot=0xf3 phys=0xc3000000
[memory] remap fixed 00000011c1000000+0x800000 prot=0xf3 phys=0xc3800000
...

A ~1.8 GB reservation mapped in 8 MiB pages, each on unrelated physical memory, and the engine packs surfaces across page boundaries. Only 82 remaps hit the pool, all during start-up, none once the title screen shows. A temporary diagnostic recording the import refusal of each CPU upload named one cause for all of them: not registered, because HostImportFor keeps a run inside one 8 MiB import window and the surface crosses it.

4. The fix: PR #6197

HostImportSpanning keeps HostImportFor's per-window contract and falls back to a joined import over the contiguous ranges the surface covers (crossedRun → importJoined, as buffers already do); the storage texture paths use it. New test importSpanningTests fails on main and passes with the change; agc_driver_graphics_tests passes; conventions pass.

	frame p50 / p90	presents / 10 s	CPU storage uploads / 10 s
main 760ffa6 (+ first-use preparation), APS5_PROFILE_DRAW=1	95 / 102 ms	~104	235
+ #6197	84 / 90 ms	~118	0
fork c222bd2	71 ms	~140	~1,700
fork + #4286 (adapted)	72 ms	—	—
fork + #4286 + #6197	35 ms (~28 FPS)	~280	0

The big step needs both: #4286's alias hand-over only takes a surface's units on the device when the surface is imported, and here the aliased surfaces were exactly the ones crossing a window. #4286 alone was neutral on Windows (as its author measured); with #6197 it removes most of the storage round trips. On main without #4286 the remaining storage cost is ~8,800 storage refresh write-backs (~9.6 GiB) per 10 s.

To apply #4286 on your fork: it conflicts in one line of Texture.cpp (originalValid became layerOriginal); the resolution is if (handingOver || GuestMemory::Watched(...)) layerOriginal.assign(trackedLayers, false); plus replacing the three other originalValid = false with layerOriginal.assign(trackedLayers, false) (source-> in the drop path). WatchedImportsStampPages no longer exists on main.

5. What did not help (so nobody repeats it)

• Skipping AwaitRegistrationPreparation at submit (the wait fix(agc): wait for queued registration preparations before accepting a submission #5007 added): no change, the title was not submitting yet; it was the registration memory, not this wait.
• APS5_NO_LIBRARY_PREBUILD=1: no effect on the memory growth.
• perf(agc): hand aliased storage memory over without the guest round trip #4286 alone on Windows: neutral (72 vs 71 ms), see above.
• Moving the game from a hard disk to an NVMe SSD: start-up is much shorter (the shader cache reads ~300 MB per 10 s and the hard disk spent ~100 s of thread time per 10 s on it), the title-screen frame time is unchanged.

6. Things worth knowing

• Old main (Oct 13, 18c438b era) stopped for good after ~1,050 shaders with SubmissionManagerPs5::waitForFrame 0x8002003C; current main registers past that and presents.
• Cold start: the title registers ~8,600 shaders before its first frame. APS5_SPIRV_OPT=none made cold preparation ~45 % faster here (2,780 vs ~1,900 shaders in the first ~200 s).
• First cutscene: frames of 20–57 s while ~120 new shaders per 10 s are prepared (2,580 in one session), memory stable at ~10.8 GB, no error; it is a cold cache, not a hang.
• EA's own watchdog writes eadp.errorsdata.*_hang.st.dat under download0/.../eadp-sdk/persistence/PROD/ during the long start-up; they list thread names only.
• APS5_STORE_AT_FLIP=1 (from your settings) writes back ~11.9 GB per 10 s at flips on this machine; I have not measured the title without it yet.

7. Launch settings used for the fork rows

APS5_FLIP_INFLIGHT=2 APS5_SPIRV_OPT=none APS5_WORKER_AFFINITY=1 APS5_STORE_AT_FLIP=1 APS5_DRAW_SNAPSHOT_ARENA=1 APS5_DRAW_SNAPSHOT_ARENA_EXTEND_KIB=1024 APS5_BINDING_PLAN=1 APS5_EPOCH_DIRTY_SET=1 APS5_EPOCH_DIRTY_SET_WIDEN_KIB=256 APS5_PIPELINE_COMPILE_AHEAD=1 APS5_PIPELINE_COMPILE_THREADS=2 APS5_NO_GPL=1 APS5_NO_SHARED_FLOAT_FUNCTIONS=1 APS5_LAZY_STAGING_OUT=0 APS5_ARENA_DEVICE_TWINS=0 (your list without the VERIFY switches).

Next

The worker is still ~88 % busy at 35 ms on the fork. I am looking at the remaining storage round trips and the flip write-backs next, and at host memory use; happy to split the work with you.

AI-assisted: yes (Claude Code). All numbers are from runs on this machine.

[semirkabir]

Data point from a smaller card, on @0xcrstn's fork (ufc6/testing c222bd2), Windows 11, i5-12600K, 32 GB RAM, RTX 3070 8 GB, driver 32.0.16.1088, content 01.004.000. Launched with @mcsilva-dev's settings list (no VERIFY switches) plus APS5_MEMORY_REPORT=60.

How far: intro fight, then quit to the main menus. Menus render fully (UI, fighters, offline banner) at 2.6–4.4 FPS. Controller works as long as the game window has focus; with another window focused, SDL drops all input, which looked like a hang at first.

Practice mode works: Max Holloway vs Kamaru Usman at the PI octagon, at 5.2–5.5 FPS. That's the fastest I've measured and faster than the menus, which is odd given the timeouts land on character passes. The practice telemetry HUD works and strikes register damage. The fighters render cleanly: tattoos, shorts, sweat/specular and contact shadows all look right. Two intermittent artifacts on fighters: a small white blotch on Usman's left chest/shoulder in one frame, and a black square that sometimes appears over Carlos Prates' groin/shorts area. Both come and go between frames, so maybe a per-frame resource that's sometimes stale, rather than a broken mesh or texture.

Fight Now: loading into a fight from the menus sat on a black screen until I closed it manually, at ~27 GB commit. I didn't wait it out, so I can't say whether it was shader compile or a hang.

Memory: stayed at ~10–13 GB commit during startup on the fork, against ~24 GB and climbing on main a077a88 at the same point. It reached ~25 GB commit after ~40 min in menus and an intro fight, but it was still running.

Crash after ~45 min:

Failure in SubmissionManagerPs5::waitForFrame with error code 0x8002003C   (16th occurrence)
terminate called after throwing an instance of 'std::runtime_error'
  what():  compute shader 0x7fff7f38b400: AGC graphics: vkWaitForFences recorder: Vulkan result -4

Windows logged 5× nvlddmkm event 153 ("Error occurred on GPUID: 100") in the same second, and TdrDelay is at the 2 s default. Frames here take ~2.5 s, so my guess is a single submission crossed the TDR limit and Windows reset the GPU. That would explain why the 5090/5080 runs see 0x8002003C but never lose the device. I didn't test with a raised TdrDelay, so treat this as a hypothesis.

VRAM spill on 8 GB: in Practice mode the device-local budget reported via VK_EXT_memory_budget is only ~5.7 GB, and the driver log shows the overflow going to host memory type 0: up to 8,056 MiB of device buffers and 14,291 MiB of storage textures placed in host memory. On this card a lot of GPU work reads over PCIe, which could be part of why frames take seconds here and submissions get close to the TDR limit.

Where the timeouts land: Frostbite's own GPU breadcrumbs, printed with each waitForFrame 0x8002003C (21 of them in the first 8 minutes of loading Practice mode), name the pass that was running:

5  SubSurfaceScatteringGenerateTilesCS   (renderPass sssConvHorizontal)
3  WarpClothComputeMeshGeometryNormals   (DamageMaskSink)
2  StrandHairRasterizerFineCs            (addHairResolvePass)
2  AccumScatteringTransmittanceCameraVolumeCS (worldMainForwardEmissive)
1 each: ProceduralSky, SkyPhysicalGetHorizonColor, Tex2d; 4 with no pipeline bound

So mostly fighter skin, cloth, hair and volumetrics, the compute-heavy character passes. That might be a useful lead for whoever is profiling GPU time.

Import audit (tools/import_audit.py over all four registries, with the title's modules): 2,653 unique imports, 0 absent, 84 throwing stubs (PSML MFSR, AJM batch/instance create, VideoRecording, Voice, AudioIn, commerce/web dialogs). None of those stubs threw during the 45 min run, so nothing UFC reached on this path is unimplemented. The PSML MFSR ones look covered by #5651 / #5796 if it ever gets there.

Graphical glitch on the PLAY tab: the 2D UI is clean, but the 3D background behind it is flooded with flat electric blue. The fighter bust is broken into blocky tiles of bright yellow, green, magenta and red, with heavy bloom and stray colored pixels on the left. FPS dropped to ~1.4 on that screen. It depends on the selected item, not the tab. The upper PLAY items (PLAY MODES) rendered their background correctly, with Max Holloway shown cleanly. The corruption only appeared once the selection moved down to the EARN, LEARN AND CREATE section (screenshot is on LEARN). The ONLINE tab background (Pereira/Procházka staredown) also rendered correctly in the same session. So it looks tied to the background scene those lower items load, most likely its lighting/post pass. It might be the same family as the "bright cyan crowd/lighting patches" mentioned in the first post.

AI-assisted: yes.