AutoMemoryBenchmark

This test consists of multiple scenarios where a driver is evaluated for memory being consumed in the scenario. The benchmark aggregates results from different memory metrics to arrive to a final score for the scenario. This score is the key metric developer should optimize and the metric which is evaluated for Windows Hardware certification.

The memory benchmark is currently comprised of the following six scenarios:

• Idle

• Present

• Textures

• Buffers

• Surfaces

• Upload

For each of the rendering scenarios (all scenarios except Idle), the goals for the scenario are established such that:

• 2MB allowed for OS overhead.

• +2MB allowed for driver overhead per GPU in a link for x86 and x64 systems, +1MB per GPU in a link allowed for ARM systems. The number of linked GPUs on a system is determined and multiplied by the system-determined size per GPU to give the total driver overhead allowed.

• +Size of surfaces explicitly created by application + 7.5% for alignment/padding in the case of non-power of 2 surfaces.

• +4KB overhead per surface created on 32-bit systems, +8KB overhead per surface on 64-bit systems.

• Except for the Present scenario, the rendering scenario targets are rounded to the next half-megabyte boundary.

Test details

Running the test

Before you run the test, complete the test setup as described in the test requirements: WDTF System Fundamentals Testing Prerequisites.

Known issues

With the current build of the tool, aperture pages that are marked non-CPU visible by the graphics driver will not be matched to the process that generated the workload for the driver. Instead, it will be found in the DWM process, which attaches to the originating process to perform its work on the surfaces. Because of this lack of matching, they will not be found in the UserModeReferenceSetAdjustment metric, and those aperture pages will be counted twice by the tool. To fix this, the pages referenced while attached should be assigned to the process that is attached to, since it is the virtual address space that is affected, which has been addressed but has not made to the release branch. When this fix reaches WinMain, IHVs with access to that version build or later will see the double counting disappear. As a workaround, IHVs can set their pages to CPU-visible when running the benchmark to understand where they are at.

Troubleshooting

A stack that does not go all the way to thread creation indicates that ETW is having a problem walking the stack when the event is fired. ETW will log a maximum of 96 stack frame, but that limit is rarely hit. Typically the problem is a driver compiled with FPO optimization causing the stack walk to end abruptly.

If you do not have a stack, ensure that you are running the benchmark with the –details option.

For additional troubleshooting information, see Troubleshooting System Fundamentals Testing.

More information

Command syntax

Note  

For command line help for this test binary, type /h.

File list

Send comments about this topic to Microsoft