This test includes,
- A dockerfile creating a Docker image containing SST-Core
and SST-Elements installed. The image also contains the
bbl-busybox-boot-exit binary from gem5-resources.
- A nightly test involving compiling gem5 as a library, and
booting a linux kernel without a disk image using SST where
gem5 TimingSimpleCPU is the CPU core.
Change-Id: I2bf90b4121ed0d38300451648f2e358a7c3fffe2
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52564
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This allows us to set a high number of threads for gem5 compilation
tasks, and a lower number of threads for running gem5. The latter is
more memory intensive and, therefore, we cannot always use the maximum
number of threads in a system.
Change-Id: I699d9f74b21d31841bf31e3589d323b007cb4601
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53483
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Without this verbose flag, there is no information output on the tests
currently running. Output is only given on the pass/fail status of a
test after completion. This is unhelpful if the tests fail due to a
timeout (e.g., a test has stalled).
The '-vv' verbose flags sets up the TestLib package to output when a
test has started execution. This information can help in figuring out
which test caused a timeout event to occur.
Change-Id: I14e6752d40a7c8d7189211584073ba79c88ed7d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53305
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
In order to fix several regression failures [1] the master/slave
terminology in src/cpu/BaseCPU.py was reintroduced [2].
This patch is addressing the issue by providing 2 different
ways of connecting cpu ports:
*) connectBus: The method assumes an object with a bus interface is
passed as an argument, therefore it tries to bind cpu ports to the
bus.mem_side_ports and bus.cpu_side_ports
*) connectAllPorts: No assumption on the port owning device is made.
The method simply accepts ports as arguments which will be directly
connected to the peer cpu ports
This will be used for example by ruby Sequencers
[1]: https://gem5.atlassian.net/browse/GEM5-775
[2]: https://gem5-review.googlesource.com/c/public/gem5/+/34495
Change-Id: I715ab8471621d6e5eb36731d7eaefbedf9663a71
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52584
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Two tests, one in test_kvm_fork_run.py and another in
test_kvm_cpu_switch.py, were trying to run the MI_Example protocol as
part of the quick/kokoro run. MI_Example requires the building of X86,
though we try to use GCN3_X86 exclusively to avoid compiling an
additional target. As such, these MI_Example tests have been moved to
the long/nightly run.
Change-Id: I3c196e7e336148a1b7a124b5810348a2e587fe24
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52563
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This enables an SE mode execution of binary if added a Board's
superclass.
This has been abstracted from the SimpleBoard.
The 'set_workload' function has been renamed 'set_se_binary_workload'.
This is clearer on its purpose and doesn't overlap with other
'set_workload' functions.
Change-Id: I714425a3b6b98b91e762ad076eba583bc5953ddd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52186
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This patch moves 'connect_things' to the AbstractBoard constructor,
thereby meaning it does not need to be called directly in gem5
configuration scripts. This method has been changed to private as a
result.
As boards that inherit from AbstractBoard require certain things to be
setup prior to `connect_things` being called, a new abstract function,
`_setup_board` has been created. This is called in the AbstractBoard
constructor before `connect_things` and can be overridden by boards to
setup board properties as required.
Change-Id: I558a4321b850a6b19e20b7d56d0bcae5805114b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52184
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The override parameter in the constructor has been renamed to to
'download_md5_mismatch'. This makes the purpose of this parameter
clearer.
The default value has been changed from False to True. We found in most
cases we want to re-download files if the md5 values have changes. Not
wanting to do so is the corner case. This allows us to remove a lot of
parameters from test and example scripts, included in this patch.
Change-Id: I99fc7743f5adf78bf6f4f8efc6222e6df83ac6da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52086
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The purpose of this class is to:
* Create a standard way to set a typical kernel/disk image workload.
* Cleans up the manner in which readfile values/contents are set.
* Allows a user to specify their own kernel arguments, but still sets
sensible defaults.
As of this commit, this interface has been added to the X86Board and the
RISCVBoard.
Change-Id: I34f4c2b829f1ae5c1cae12039436cbb345a89d09
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51949
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some confusion about usage of 'Optional'. In some areas
of the codebase it was assumed this specifies an optional parameter
(i.e., one which may or may not set, as it has a default value). This is
incorrect. 'Optional[<type>]' is shorthand for 'Union[<type>, None]',
i.e., it is used to state the value may be 'None'. This patch corrects
this throughout the gem5 codebase.
Change-Id: I77a6708dee448e8480870d073e128aed3d6ae904
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52143
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GPU models support a simple register allocation policy (1 WF/CU at a
time) and a dynamic register allocation policy (up to max WF/CU at a
time). By default, the simple policy is used. However, the dynamic
policy is much more realistic relative to real hardware and thus much
more important to ensure it works in the regressions. This commit
updates the nightly and weekly regressions accordingly to run the
dynamic register allocation policy.
Change-Id: Id263d3d5e19e4ff47f0eb6d9b08cbafdf2177fb9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52163
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Add the Pannotia benchmarks to the weekly regression suite. These
applications do a good job of testing the GPU support for irregular
access patterns of various kinds. All inputs have been sized to use
relatively small graphs to avoid increasing runtime too much. However,
even with small input sizes Pannotia does run for a while.
Note that the Pannotia benchmarks also use m5ops in them. Thus, this
commit also adds support into the weekly regression for compiling the
m5ops (for x86, since that is what the GPU model assumes for the CPU).
Change-Id: I1f68b02b38ff24505a2894694b7544977024f8fa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51968
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
66a056b8 changed the weekly regression to use a single docker for
all GPU tests, to reduce how many times gem5 needed to be compiled.
However, in my local testing of that patch, gem5-resources was not
deleted until after the docker was created -- which causes a problem
when gem5-resources does not exist already from a prior run, since
the creation of the dockerfile requires it for HACC. This commit
fixes this problem by moving the pull of gem5-resources to be before
anything else related to the GPU happens.
Change-Id: I006860204d03807d95628aa5dcf6e82d202fef9c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51907
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This tests forking gem5 and simulating the child with a different cpu.
The test boots linux with the KVM cpu and then forks gem5. Each child
simulation switches to the specified cpu and simulates to completion
while the parents waits for the children to finish before also
simulating to completion.
Change-Id: I68d7515bf125c855eefc62ba4798cd7c745ef2b0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50467
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This commit adds HACC (a GPU HPC workload) to the weekly regression
tests. HACC requires a number of environment variables to be set, so
to avoid setting all of them manually, we use a specific Dockerfile for
it. To avoid compiling gem5 once for this docker and once for the other
GPU tests in the weekly regression, this commit also updates the weekly
regression such that all GPU weekly regression tests use HACC's docker
for their tests.
Change-Id: I9adabbca01537f031cbc491ddf1d3e7dd155f3f2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51708
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
DNNMark and LULESH were both cloning and removing gem5-resources as part
of their tests, since they were committed separately/in parallel. Clean
this up so we only remove and pull gem5-resources once now in the weekly
regression script.
Change-Id: I5ab1410b0934bf20ed817e379f4e494aa53bfa44
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51707
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Square and HeteroSync's pre-built binaries were downloaded into the
tests folder in the nightly regression script, but the docker
command running them assumed we were in GEM5_ROOT. This commit
fixes this problem by specificying the benchmark root for the
applications.
Change-Id: I905c8bde7231bc708db01bff196fd85d99c7ceac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51247
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
DNNMark is representative of several simple (fast) layers within ML
applications, which are heavily used in modern GPU applications. Thus,
we want to make sure support for these applications are tested. This
commit updates the weekly regression to run three variants: fwd_softmax,
bwd_bn, and fwd_pool -- ensuring we test both inference and training as
well as a variety of ML layers.
Change-Id: I38bfa9bd3a2817099ece46afc2d6132ce346e21a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51187
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
LULESH is a popular GPU HPC application that acts as a good test
for several memory and compute patterns. Thus, including it in
the weekly regressions will help verify correctness and
functionality for code that affects the GPU. The default LULESH
input runs 10 iterations and takes 3-4 hours. Hence, it is not
appropriate for nightly regressions.
Change-Id: Ic1b73ab32fdd5cb1b973f2676b272adb91b2a98e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50952
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
HeteroSync does a good job of testing the GPU memory system and
atomics support, without requiring a long runtime. Thus, this
commit adds a mutex and barrier test from HeteroSync to the
nightly regression to ensure these components are tested.
Change-Id: I65998a0a63d41dd3ba165c3a000cee7e42e9034a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50951
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
The x86-boot-exit resource is being deprecated for the more versatile
x86-ubuntu-img resource. The latter attempts to run `m5 readfile`,
allowing a user to specify a script to be run. If no script is specified
`m5 exit` is run. Therefore it can be used in the x86-boot-exit tests.
Change-Id: I7fecb314bd0e1d4be4f1181e57046e4621199b64
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50647
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Austin Harris <mail@austin-harris.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
