Skip to content

Integrate optick profiler#262

Merged
themrdemonized merged 6 commits intothemrdemonized:optickfrom
Lander-Modding:optick
Jun 20, 2025
Merged

Integrate optick profiler#262
themrdemonized merged 6 commits intothemrdemonized:optickfrom
Lander-Modding:optick

Conversation

@ProfLander
Copy link
Contributor

@ProfLander ProfLander commented Jun 19, 2025

Based on the IX-Ray implementation by @ForserX

anomaly-optick

Summary of changes

  • Add optick-git submodule, expose to solution via optick VS sub-project

    • Allows easy version control, explicit code ownership
  • Remove old xrGame profiler.h / profiler.cpp

    • Existing call sites are covered by new START_PROFILE / END_PROFILE wrappers
  • Implement xrCore profiler.h wrapping optick macros

    • Separates implementation, potential to hook in other profiling backends in future
  • Add xrCore to appropriate include paths, normalize relative profiler.h includes

  • Instrument main loop in device.cpp on_idle

  • Hook spawn_thread into profiler machinery

    • Causes spawned threads to automatically show in optick
    • Avoids using PROF_THREAD in every thread callsite
  • Instrument various device.cpp functions and some downstream callsites

Usage

Locally modify profiler.h or the solution's preprocessor definitions to set XRCORE_PROFILER to 1 (PROFILER_OPTICK) before creating your development build.

After reaching the title screen, Optick's standalone client will be able to attach to it and gather profiling data.

Further work

  • Increase profiling coverage by instrumenting more callsites with PROF_EVENT, START_PROFILE / STOP_PROFILE as the need arises

  • Allow profiling of before-main-loop code

    • Standalone optick relies on the main loop to connect and hook in
    • Need to start profiling from inside the engine, write out a file
  • Console commands to manually start / stop profile recording at runtime, save .opt files for offline loading

  • Hook into xrCPU_Pipe to visualize worker threads

    • Attempted during this PR, but wasn't successful; may be down to occurring before the main loop

Optick API

Closing notes

Opening as draft for now, as I need to figure out an appropriate solution to runtime overhead; as-is, the new preprocessor define is set on all project configurations, and exhibits noticeable overhead when running VerifiedDX11. I'll test DX11AVX and think on it some, but suggestions would be most welcome 👍

@ProfLander ProfLander mentioned this pull request Jun 19, 2025
@ProfLander
Copy link
Contributor Author

ProfLander commented Jun 19, 2025

Still some solution-side work to do so the buildbot will work, from the look of it - unsurprising, will investigate later.

@ProfLander
Copy link
Contributor Author

ProfLander commented Jun 20, 2025

This should be good to go now; I've extended the buildbot to deal in git submodules, and made some preprocessor definitions that were previously done by hand in my local checkout.

Profiling backend is now selected by the XRCORE_PROFILER preprocessor variable, leaving obvious scaffold for other backend implementations.

Since profiling has a runtime performance overhead (nominal in DX*-* builds, extremely noticeable in Verified*) I've opted for a conservative approach and set it to PROFILER_NONE instead of PROFILER_OPTICK by default.

As-is, developers needing to profile can locally modify profiler.h or the solution's preprocessor definitions to set the appropriate backend before creating their build.

Exposing this via a new ProfiledDX11 configuration for convenience is a possibility, though that requires setting XRCORE_PROFILER on all subprojects that require profiler.h (as visualized by the project dropdown at the top-left of its editor window,) and the build matrix is already quite complex and hard to maintain for newly-added library dependencies.

Exposing it dynamically via cvar might also be worth considering, but that would add a conditional branch to the top of every instrumented function. May or may not be worth the tradeoff; would need to be tested. Maybe concerning for compiler optimization of tight loops / other hot codepaths.

(Also it looks like I forgot to mark this as draft in the first place? Whoops...)

@themrdemonized themrdemonized changed the base branch from all-in-one-vs2022-wpo to optick June 20, 2025 06:10
@themrdemonized themrdemonized merged commit 6ea698f into themrdemonized:optick Jun 20, 2025
9 of 10 checks passed
@themrdemonized
Copy link
Owner

I think the best solution would be new ProfiledDx11 configuration, based on DX11 with profiler enabled and required defines. Maybe disable LTCG and WPO in project settings

@themrdemonized
Copy link
Owner

themrdemonized commented Jun 20, 2025

ProfiledDX11 configuration commit
Broken for now, there are linker problems, the paths are screwed up
3a7f678

@themrdemonized
Copy link
Owner

Alrihgt, kinda fixed it, at least it compiles

xrPhysics dont have Profiling yet, Link error when trying to use Profiled config on that project, so it uses Release config

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants