Description

While @emilk was investigating a (separate) crashing issue with wgpu, they reported that wgpu-hal and wgpu-core's logging at the INFO level were so verbose as to hinder debugging.

Repro steps

See this comment.

Expected vs observed behavior

In @emilk's words:

I think INFO should be used sparingly to inform users of important and rare events. Currently I cannot even resize my window without four log lines for each resize event:

2022-11-11T13:18:11.813326Z  INFO wgpu_core::device: configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8Unorm, width: 1889, height: 2135, present_mode: AutoVsync, alpha_mode: Auto }    
2022-11-11T13:18:11.813387Z  INFO wgpu_core::device: Automatically choosing presentation mode by rule AutoVsync. Chose Fifo    
2022-11-11T13:18:11.813391Z  INFO wgpu_core::device: Automatically choosing alpha mode by rule Auto. Chose Opaque    
2022-11-11T13:18:11.813397Z  INFO wgpu_hal::metal::surface: build swapchain SurfaceConfiguration { swap_chain_size: 3, present_mode: Fifo, composite_alpha_mode: Opaque, format: Bgra8Unorm, extent: Extent3d { width: 1889, height: 2135, depth_or_array_layers: 1 }, usage: COLOR_TARGET }

This is not interesting to me. This should be at the TRACE or DEBUG level imho.

Out of the box, we'd like INFO-level and higher severities of logging to have a high ratio of useful information.

Extra materials

-

Platform

-

Remaining action items

• Determine log levels going forward; reconcile the following opinions:

  • @cwfitzgerald's opinion(s): 1 (consensus from @kvark)

  • @kpreid's opinion(s): 1

  • @emilk's opinion(s): 1

  • @ErichDonGubler's opinion(s): 1

  • Current apparent consensus, with open questions noted in bold:

    Term	Definition
    Recoverability	@emilk: Whether an issue can be resolved automatically. A “recoverable” issue has good automatic fallback within wgpu, but should still be resolved. An “unrecoverable” issue requires end-user or developer intervention to resolve.
    Severity	The significance of a consequence associated with an issue. High severity (or "more severe") potentially thwarts wgpu's usage. Low severity ("less severe") may result in degraded performance or scope of functionality, but is not likely to threaten overall usage.

    Level	Description
    ERROR	High-severity unrecoverable issues. @emilk: Ideally, we avoid these in favor of returning Errors to user code.
    WARN	Issues that are one of (@emilk) recoverable (viz., has “good” automatic fallback), (@cwfitzgerald) unrecoverable, but of low severity, or (@ErichDonGubler) conditions that are unexpected and whose consequence is (1) potentially severe but (2) require further information to triage.
    INFO	@emilk, @kpreid: High-level summary of infrequent wgpu operations. Currently unclear whether there are any non-problematic per-frame events that are acceptable to report here.
    DEBUG	High-level indications of wgpu's inner workings. Intended only to contextualize other logs or span elements.
    TRACE	Fine-grained reporting of execution that is only expected to be interesting when wgpu itself is being scrutinized heavily for bugs.

• Move log statements that “only” acknowledge API calls to DEBUG level.
  • Move per-frame tracing to DEBUG or lower, in general.
    • TODO: Concrete things to move?