Previously the LDS bus latency was not configurable in the GPU config
scripts. As a result, the simulations would use the default value from
GPU.py. This commit adds support to change this value as an input
option. The option to use is "--vrf_lm_bus_latency".
Change-Id: I8d8852e6d7b9d03ebec1fe8b392968f396dd3526
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63652
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair.wisc@gmail.com>
Support has been added for SDMA RLC queues which are used for host to
device and device to host "memcpy" calls. Previously the SDMA engine was
disabled which caused GPU BLIT kernels to be called. This removes the
environment variable disabling SDMAs which has two main benefits:
- It will be much easier to debug host/device transfer by using SDMA
debug flag.
- Simulation time is improved since we no longer need detailed GPU
simulation to copy data and instead are doing a simple large DMA
Change-Id: I7524245731d301b5c26394318f2156ed6b4c983a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62717
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
simpoints-se-checkpoint.py & simpoints-se-restore.py:
These are two example scripts to show how to use SimPoints functions with
the stdlib.
se_binary_workload.py:
Allow se_binary_workload to take in SimPoint Class item and schedule
SimPoint exit events.
exit_event.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit events.
simulator.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit event scheduling functions.
They can schedule exit events before or during the simulation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1259
Change-Id: Iaa07a83de9dddc293b9f1a230aba8e35d4f5af6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63154
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The TARGET_ISA variable would let you select one ISA from a list of
possible ISAs. That has now been replaced with USE_ARM_ISA, USE_X86_ISA,
etc, variables which are boolean on or off. That will allow any number
of ISAs to be enabled or disabled individually. Enabling something other
than exactly one of these will probably prevent you from getting a
working gem5 binary, but those problems are being addressed in other,
parallel change series.
I decided to use the USE_ prefix since it was consistent with most other
on/off variables we have in gem5. One noteable exception is the
BUILD_GPU setting which, you could convincingly argue, is a better
prefix than USE_. Another option would be to use CONFIG_, in
anticipation of using a kconfig style config mechanism in gem5.
It seemed premature to start using a CONFIG_ prefix here, and if we
decide to switch to some other prefix like BUILD_, it should be a
purposeful choice and not something somebody just starts using.
Change-Id: I90fef2835aa4712782e6c1313fbf564d0ed45538
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52491
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Glibc requires x86-64-v2 ISA level on newer Linux distributions (e.g.
Debian Bookworm), and running applications in GEM5 will fail with "CPU
ISA level is lower than required" error. It is due to glibc not
detecting CPU features when the vendor string is unknown yet requiring
them to run. For glibc to detect correct CPU features, this commit adds
a command line option to allow user to override x86 cpu vendor string to
well-known ones, e.g. GenuineIntel. It allows glibc to detect more cpu
features and fixes the issue.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1117
Change-Id: I22907e7b983e9aa6122543042af207e35b09badb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62555
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 environment variable HSA_ENABLE_INTERRUPT controls if Interrupt or
busy wait signals are used in the ROCm runtime. Interrupts are not being
sent in gem5 causing simulations to hang indefinitely in certain
situations. To fix this, always disable interrupts to fall back to busy
wait signals. Using interrupts is an old and simple optimization to not
waste CPU cycles, but from the perspective of simulation this is not
important. Disabling interrupt-based HSA signals therefore increases the
number of applications working within gem5.
Change-Id: I1ae21d7ee01548a4d00a8972642079b90278f9a2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61652
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Update the TCP_latency input arg to reflect what it does -- in
combination with the number of banks, it determines the number of
accesses that can happen in the L1 (TCP) in a given cycle. It does
not directly affect the L1 latency as the name implies. Instead,
the mandatory_queue_latency does this.
Change-Id: Ib6cbc8367ce2b1f30005d137384f53650a403b49
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61309
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Update the Part 3 config file examples in learning gem5 to resolve a
warning with int_links. Some files were initializing self.int_links vector
to an empty list of SimObjects. This causes a warning.
The fix resolves this by initializing self.int_links to a pre-declared
int_links variable.
Change-Id: Iaa38a4db9cc42a949879d571d1372f0b0a456f11
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60829
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Make it possible to read any type of reg, assuming it fits in a RegVal.
This avoids assuming building in a dependency on the readIntReg
accessor.
It also avoids setting up a situation where the API could at least
theoretically base the timing expression on the value of *any* int reg,
even ones the instruction does not interact with. The ...ReadIntReg
expression was only ever used with the result of the ...SrcReg
expression, and in my opinion, that's realy the only way it makes sense
to use it. It doesn't seem useful to split that operation into two
parts.
If it actually does make sense (although I doubt this), these operations
can't really be generalized easily since the TimingExpr... classes all
expect to pass around uint64_ts, and a RegId, the *real* value of a
SrcReg index which does not assume a register type, would not fit in
that in the general case.
Change-Id: I253a0a058dc078deeb28ef0babead4c8ffc3b792
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49776
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This change consists of two scripts,
- riscv-hello-save-checkpoint.py: runs the first million ticks of the
simulation and save a checkpoint.
- riscv-hello-load-checkpoint.py: loads the above checkpoint, and runs
the rest of the simulation.
This change also adds the two scripts as part of quick tests.
Change-Id: I7bd97ba953fab52f298cbbcf213f2ea5c185cc38
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58829
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This change splits the default gem5 memory controller into two
memory controllers: MemCtrl (base memory controller which can be
used with only a single memory interface dram/nvm), and
HeteroMemCtrl (heterogeneous memory controller which inherits from
MemCtrl and requires a dram and an nvm memory interface).
New arguments are added to many of the base class (MemCtrl) functions
(for example memory inteface to use that function for) which helps
in easier use of these in the inherited class (HeteroMemCtrl).
Change-Id: Ifa4e9f9f1560c47063d1a8159a8c94add2e670bb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59731
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
This changes adds a new board to the gem5 stdlib, which is capable
of simulating an ARM based full system. It also adds an example
config script to perform a boot-test using an Ubuntu 18.04 disk
image. A test has been added in the gem5-library-example for the
same.
Change-Id: Ic95ee56084a444c7f1cf21cdcbf40585dcf5274a
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58910
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The supported version of ROCm in GPUFS only supports the DKMS build of
the amdgpu driver. However, since a gem5 user can potentially pass in
any Linux kernel as a parameter, it is possible that the DKMS package
for that kernel was not installed on the disk image. This would result
in the simulation appearing to work when in reality it is just spinning
waiting for commands from the driver. This check exits gem5 early in the
simulation and outputs an error on the console to sanity check the
correct driver is being used.
Change-Id: I708912e5625e47eba15dcb2f722772a3b2928b98
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58129
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
