Skip to content

Improve GPU profiling/debugging tooling #3005

Description

@bruno-dasilva

we've run into some player reported issues recently that were difficult to debug.
They were:

When an issue is reproducible, we can rely on tooling like nvidia nsight to debug frames. Thankfully we have labels/zones for attribution which makes this a pretty nice experience. But the common player can't use this and its a PITA to setup (you must start the spring process with the nsight profiler).

There are a few ways we could improve this experience:

  • provide gpu-side time profiling, similar to what we have today with /debug but on the gpu-side (for when we have some expensive gpu calls like with the ghost buildings issue). This is what the common player can use
  • enable Tracy opengl support! so enthusiasts and devs can more easily track whats going on with the gpu via tracy.
  • track gpu memory allocs/deallocs so we can track vram usage? maybe possible just with tracy like we do with regular mallocs.

Not sure how this fits with wupgets using the opengl apis, it may be that this is just focused on the engine-side opengl things and then we let wupgets be profiled by their own tooling (eg. a lua side gpu profiler, like in https://github.com/bruno-dasilva/Beyond-All-Reason/blob/f3ce84323445edab7bdcda587c69dd8ff4de5594/luaui/Widgets/dbg_gpu_profiler.lua)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions