GUI design & implementation Phase 1

This document describes first phase of WindowsPerf GUI design and implementation.

Introduction

As designed wperf-gui will be data-driven application. By definition we will not “hardcode” in GUI source any information related to WindowsPerf application workflows. For example we will not store event names, number or descriptions in GUI. GUI will fetch list of events and all relevant data from wperf. wperf application is ready to emit (almost) all information needed to generate user interface. Current limitations are:

  • maximum number of events user can specify with wperf stats's -e <events> command line switch.

    • This can be mitigated to hard limit in GUI for now. In the future wperf test command will emit this value for GUI.

  • Extra description of the event.

Example of wperf commands that GUI should be able to “execute” with Phase 1

>wperf stat -e inst_spec,vfp_spec,ase_spec,dp_spec sleep 1 >wperf stat -e inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec -c 0 sleep 2 >wperf stat -e inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec -c 0,1,3 sleep 3 >wperf stat -e {inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec},{br_immed_spec,crypto_spec} sleep 1 >wperf stat -e {inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec},{br_immed_spec,crypto_spec} -c 0 sleep 1 >wperf stat -e {inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec},{br_immed_spec,crypto_spec} -c 0,1,2 sleep 1 >wperf stat -m imix sleep 1 >wperf stat -m imix -c 0 sleep 1 >wperf stat -m imix -e l1i_cache -c 0 sleep 1 >wperf stat -m l3_cache -e l1i_cache -c 0,1,2 sleep 1 >wperf stat -m ddr_bw -e l1i_cache -c 0 sleep 1

Notes

  • wperf-relay is later called “relay”.

  • wperf-gui is later called “GUI”.

Description of Phase 1

wperf

User Story

Description / TODO

User Story

Description / TODO

CLI-01

Required to maintain control over error states in relay and wperf.

CLI-02

This additional data is required by GUI to control how many elements GUI widgets can include in relay query.

CLI-03

This additional data is required by GUI to print additional information in GUI-13.

wperf-gui

User Story

Description / TODO

User Story

Description / TODO

GUI-01

n/a

GUI-02

Building widget to select host (IP/URL/port) to connect to.

GUI-03

Listing all available events and metrics (wperf list) - for example separate tab.

GUI-04

Listing of wperf version number (wperf -version -json).

  • For example in modal window “about” and

  • in bottom status bar.

GUI-05

Listing additional data about host (wperf test) - for example separate tab.

GUI-06

Building widget to save/load host information.

GUI-07

Building widget to connect to host. This may include indicator if we are connected to host For example small “traffic lights” icon indicating if we are connected, connecting or disconnected).

GUI-08

n/a

GUI-09

Separate text window with scroll option to see consecutive outputs from wperf console.

GUI-10

Building widget to prepare list of events and event groups for wperf stat command line option -e <events>

  • Build list of CORE events and event groups.

  • [Nice-to-have] Widget would also prepare list of DSU and DMC events.

  • Groups are marked with events inside curly braces { }, see example below.

  • Make sure events and groups are sent to relay (as protocol payload) in the same order as defined by user. Please note that group numbers are assigned by wperf from left to right. For example:

    • -e {inst_spec,vfp_spec},ase_spec,{dp_spec,ld_spec,st_spec},br_immed_spec,crypto_spec

      • group 0 (g0) is {inst_spec,vfp_spec}

      • group 1 (g1) is {dp_spec,ld_spec,st_spec}

  • Note: GUI may synthesize <events> as string compatible with wperf CLI.

  • Please note that maximum number of events user can specify will be available with wperf via CLI-02.

  • List of all events: CORE, DSU and DMC are available with GUI-03.

GUI-11

Building widget to prepare list of metrics wperf stat command line option -m <metrics>

  • Note: GUI may synthesize <metrics> as string compatible with wperf CLI.

  • List of all metrics are available with GUI-03.

GUI-12

  • User can specify list of cores: from 0 to MAX-1. List can be:

    • empty - implies all cores.

    • one core.

    • comma separated list of cores. Cores should be unique and sorted in increasing manner. For example 0,3,16,17

  • Number of cores for host is available with GUI-05.

GUI-13

  • Support visualization (table) of output of wperf stat -e <events> -m <metrics> -c <cpu_list> sleep <N>.

  • Building widget which will “send” counting command to relay and wait for response.

  • Building widget which will display table with counting results.

GUI-14

Widget which will show error messages from relay.

This may include messages after each response from relay to GUI.

It may be a widget, modal window etc.

wperf-relay

User Story

Description / TODO

User Story

Description / TODO

RELAY-01

n/a

RELAY-02

This is a protocol payload which will be sent as text from wperf via relay to GUI.

RELAY-03

n/a

RELAY-04

To ease testing and GUI development relay will be able to hide missing WindowsPerf by mocking responses to all GUI requests.

RELAY-05

Basic error handling by relay and GUI.

  • Relay-GUI protocol must be able to send error information to GUI.

  • Relay-GUI protocol must provide “busy” state to GUI from relay.

  • GUI should report errors but is not responsible to error recovery of the relay and wperf.

  • Note: relay will execute and have control over wperf process and will be responsible for executing, stopping and error handling wperf.

Protocol between Relay and GUI

Protocol between Relay and GUI must include communication:

  • Payload for wperf list

  • Payload for wperf test

  • Payload for wperf stat ... -e ... -m ... -c ... sleep ...

  • Payload for wperf -version

  • Payload for console output from wperf.

Goals of Phase 1

  • Building first version of relay.

  • Building first version of GUI.

  • Update wperf with all missing meta-data we want to sent to GUI to enable data driven GUI behaviour.

  • Visualize counting model for one host.

Summary of Phase 1

  • Building initial GUI (wperf-gui).

    • Building widget to select host (IP/URL/port) to connect to.

    • Building widget to save/load host information.

    • Building widget to prepare list of events and event groups for wperf stat command line option -e <events>

      • Build list of CORE events and event groups.

      • [Nice-to-have] Widget would also prepare list of DSU and DMC events.

      • Make sure events and groups are sent to relay (as protocol payload) in the same order as defined by user. Please note that group numbers are assigned by wperf from left to right. For example:

        • -e {inst_spec,vfp_spec},ase_spec,{dp_spec,ld_spec,st_spec},br_immed_spec,crypto_spec

          • group 0 (g0) is {inst_spec,vfp_spec}

          • group 1 (g1) is {dp_spec,ld_spec,st_spec}

    • Building widget to prepare list of metrics wperf stat command line option -m <metrics>

    • Listing all available events and metrics (wperf list) - for example separate tab.

    • Listing additional data about host (wperf test) - for example separate tab.

    • Listing of wperf version number (wperf -version -json).

      • For example in modal window “about” and

      • in bottom status bar.

    • Support visualization (table) of output of wperf stat -e <events> -m <metrics> -c <cpu_list> sleep <N>.

  • Support counting model (wperf pov) JSON output for (below all done):

    • wperf stat -e <events>

    • wperf stat -m <metrics>

    • wperf stat -e <events> -m <metrics>

    • Command line option -c <cpu_list>

    • Command line option sleep <N>

  • Establishing common protocol between relay and GUI.

    • Event and metrics list fetch. Output from wperf list -json.

    • Host system and wperf application configuration. Output from wperf test -json.

    • Counting with wperf stat ... -json.

    • Basic “real time” wperf stdout logging in GUI.

      • We would like to see wperf screen output in GUI during counting execution.

  • Basic error handling by relay and GUI.

    • Relay-GUI protocol must be able to send error information to GUI.

    • Relay-GUI protocol must provide “busy” state to GUI from relay.

    • GUI should report errors but is not responsible to error recovery of the relay and wperf.

    • Note: relay will execute and have control over wperf process and will be responsible for executing, stopping and error handling wperf.

This phase will skip

  • Authentication between relay and GUI.

  • GUI will connect only to one relay. No multiple host connections are part of phase 1.

Draft and ideas for GUI

Below just few examples of GUI (this is just very rough idea)

Example console and JSON dumps from counting model example commands covered by Phase 1

Commands included in dump file:

>wperf list >wperf test >wperf -version >wperf stat -e inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec sleep 1 --output wperf_stat_01.json >wperf stat -e inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec -c 0 sleep 1 --output wperf_stat_02.json >wperf stat -e inst_spec,vfp_spec,ase_spec,dp_spec,ld_spec,st_spec -c 0,1 sleep 1 --output wperf_stat_03.json >wperf stat -e {inst_spec,vfp_spec,ase_spec},dp_spec,ld_spec,st_spec,{br_immed_spec,crypto_spec} -c 0 sleep 1 --output wperf_stat_04.json >wperf stat -e {inst_spec,vfp_spec,ase_spec},dp_spec,ld_spec,st_spec,{br_immed_spec,crypto_spec} -c 0,1 sleep 1 --output wperf_stat_05.json >wperf stat -m imix -e l1i_cache -c 0 sleep 1 --output wperf_stat_06.json >wperf stat -m imix -e l1i_cache -c 0,1 sleep 1 --output wperf_stat_07.json >wperf stat -m l3_cache -e l1i_cache -c 0 sleep 1 --output wperf_stat_08.json >wperf stat -m l3_cache -e l1i_cache -c 0,1,2 sleep 1 --output wperf_stat_09.json >wperf stat -m ddr_bw -e l1i_cache -c 0 sleep 1 --output wperf_stat_10.json >wperf stat -m ddr_bw -e l1i_cache -c 0,1,2 sleep 1 --output wperf_stat_11.json

Dump file with example commands (console and JSON)