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
Associated requirements |
System.Fundamentals.Graphics.DisplayRender.Performance |
Platforms |
Windows RT (ARM-based) Windows 8 (x64) Windows 8 (x86) Windows Server 2012 (x64) Windows RT 8.1 Windows 8.1 x64 Windows 8.1 x86 Windows Server 2012 R2 |
Expected run time |
~2 minutes |
Categories |
Certification Functional |
Type |
Automated |
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
| Command option | Description |
|---|---|
AutoShell.exe Memorywlk.xml |
Runs the test for WHCK |
Note
For command line help for this test binary, type /h.
File list
| File | Location |
|---|---|
AutoShell.exe |
[WTT\TestBinRoot]\nttest\windowstest\graphics\perfx2\ |
Memorywlk.xml |
[WTT\TestBinRoot]\nttest\windowstest\graphics\perfx2\ |
Perl.exe |
[WTT\OSBinRoot]\Perl\perl.exe |
TestX.man |
[WTT\TestBinRoot]\nttest\windowstest\graphics\perfx2\ |
setup.pl |
[WTT\TestBinRoot]\nttest\windowstest\graphics\perfx2\MemoryBenchmark |