This change adds support for HSA devices, which are
DMA devices that have an HSA packet processor (HSAPP).
An HSA packet processor model is also included. The
HSAPP is a DMA device that matains AQL packet queues
and handles extraction of AQL packets, scheduling
of AQL queues, and initiates kernel launch for HSA
devices.
Because these devices directly interact with low-level
software and aid in the implementation of the HSA ABI
we also include some headers from the ROCm runtime:
the hsa.h and kfd_ioctl.h headers. These aid with
support ROCm for the HSA devices and drivers.
Change-Id: I24305e0337edc6fa555d436697b4e607a1e097d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28128
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Decoder: gpu_decoder.hh and decoder.cc:
The decoder is defined in these files. The decoder
is implemented as a lookup table of function pointers
where each decode function will decode to a unique
ISA instruction, or do some sub-decoding to infer
the next decode function to call.
The format for each OP encoding is defined in the
header file.
Registers:
registers.[hh|cc] define the special registers and
operand selector values, which are used to map
operands to registers/special values. many
convenience functions are also provides to determine
the source/type of an operand, for example vector
vs. scalar, register operand vs. constant, etc.
GPU ISA:
Some special GPU ISA state is maintained in gpu_isa.hh
and isa.cc. This class is used to hold some special
registers and values that can be used as operands
by ISA instructions. Eventually more ISA-specific
state should be moved here, and out of the WF class.
Vector Operands:
The operands for GCN3 instructions are defined in
operand.hh. This file defines both scalar and
vector operands wth GCN3 specific semantics. The
vector operand class is desgned around the generic
vec_reg.hh that is already present in gem5.
Instructions:
The GCN3 instructions are defined and implemented
throughout gpu_static_inst.[hh|cc], instructions.[hh|cc],
op_encodings.[hh|cc], and inst_util.hh. GCN3 instructions
all fall under one of the OP encoding types; for example
scalar memory operands are of the type SMEM, vector
ALU instructions can be VOP3, VOP2, etc. The base code
common to all instructions of a certain OP encoding type
is implemented in the OP encodings files, which includes
operand information, disassembly methods, encoding type,
etc.
Each individual ISA isntruction is implemented as
a class object in instructions.[hh|cc] and are derived
from one of the OP encoding types. The instructions.cc
file is primarily for the execute() methods of each
individual instruction, and the header file provides
the class definition and a few instruction specific
API calls.
Note that these instruction classes were auto-generated
but not using the gem5 ISA description language. A
custom ISA description was used and that cannot be released
publicly, therefore we are providing them already in C++.
Change-Id: I14d2a02d6b87109f41341c8f50a69a2cca9f3d14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28127
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Sometimes when using the GuestABI mechanism, gem5 wants to know that a
function was called and with what arguments to do its own processing,
but doesn't want to return its own value since it will still let the
simulated system execute its own function. There are also situations
where gem5 wants to return a value, but not through the normal
mechanism. That happens when, for instance, a gem5 op is triggered by a
memory access, and that access is what should return the value, not a
particular fixed register.
This option is a template parameter rather than a function argument so
that if it's not going to be used, no "Return" type needs to be defined
since it's not present at all in the chain of functions invokeSimcall
expands to.
This will also make it easier to reuse generic ABIs in those situations
without having to make custom wrappers.
Change-Id: I969e78495c8f4e73f4de1a3dfb4d74c9b30f5af5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28288
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
PowerDomains group multiple objects together to regulate their power
state. There are 2 types of objects in a PowerDomain: leaders and
followers. The power state of a PowerDomain is the most performant
power state of any of the leaders. The power state of the followers is
determined by the power state of the PowerDomain they belong to: they
need to be in a power state which is more or equally performant to the
power state of the PowerDomain.
Leaders can be ClockedObjects or other PowerDomains. Followers can
only be ClockedObjects. PowerDomains can be be nested but a
PowerDomain can only be a leader of another PowerDomain, NOT a
follower. PowerDomains are not present in the hierarchy by default,
the user needs to create and configure them in the configuration file.
The user can add an hierachy by setting the led_by parameter. gem5
will then create leaders and followers for each domain and calculate
the allowed power states for the domain.
Objects in a PowerDomain need to have at least the ON state in the
possible_states.
An example of a powerDomain config is:
pd = PowerDomain()
cpu0 = BaseCPU()
cpu1 = BaseCPU()
shared_cache = BaseCache()
cache.power_state.led_by = pd
pd.led_by = [cpu0, cpu1]
This will create a PowerDomain, where the CPUs determine their own
power states and the shared cache (via the PowerDomain) follows those
power states (when possible).
Change-Id: I4c4cd01f06d45476c6e0fb2afeb778613733e2ff
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28051
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit adds the concept of possible power states to the
PowerState SimObject. This is a list of the power states a specific
object can be in. Before transitioning to a power state, a PowerState
object will first check if the requested power states is actually an
allowed state. The user can restricted the power states a
ClockedObject can go to during configuration. In addition, this change
sets the power states, a CPU can be in.
Change-Id: Ida414a87554a14f09767a272b54b5d19bfc8e911
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28050
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit does not make any functional changes but just rearranges
the existing code with regard to the power states. Previously, all
code regarding power states was in the ClockedObjects. However, it
seems more logical and cleaner to move this code into a separate
class, called PowerState. The PowerState is a now SimObject. Every
ClockedObject has a PowerState but this patch also allows for objects
with PowerState which are not ClockedObjects.
Change-Id: Id2db86dc14f140dc9d0912a8a7de237b9df9120d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28049
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
fs_power.py is an example script that demonstrates how power models
can be used with gem5. Previously, the formulas used to calculate the
dynamic and static power of the cores and the L2 cache were using
stats in equations as determined by their path relative to the
SimObject where the power model is attached to or full paths. This CL
changes these formulas to refer to the stats only by their full paths.
Change-Id: I91ea16c88c6a884fce90fd4cd2dfabcba4a1326c
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27893
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
With the introduction of StatGroups the organization of stats has
changed and the power modeling framework has been broken. This CL uses
the new function Stats::resolve to retrieve pointers to the necesary
stats and use them in the power estimation formulas.
Change-Id: Iedaa97eeddf51f7a0a1f222918715da309943be3
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27892
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This change adds a member function to the Group class that returns a
stat given its name. The function will go through all stats in the
group and its subgroups and will return the stat that matches the
name. For example, if g is the Group system.bigCluster.cpus then a
call to
p = g.resolveStat("ipc")
will return a pointer to the stat system.bigCluster.cpus.ipc.
Change-Id: I5af8401b38b41aee611728f6d1a595f99d22d9de
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27890
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
New tests were added for:
- garnet_synth_traffic.py
- ruby_random_test.py
- ruby_direct_test.py
These tests are factored out with the tests for:
- memcheck.py
- ruby_mem_test.py
Each new test was calibrated to last about 5 seconds on a Lenovo ThinkPad
P51.
Change-Id: Ie13d3963e1163cffae5dce329b623fbebbf2b983
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26808
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 file was raising due to the undefined constant `verifiers`, leading
the test to be ignored.
./main.py list -v
would show this as:
```
Traceback (most recent call last):
File "/gem5/tests/../ext/testlib/loader.py", line 239, in load_file
execfile(path, newdict, newdict)
File "/gem5/tests/gem5/memcheck/test_memcheck.py", line 32, in <module>
verifiers=verifiers,
NameError: name 'verifiers' is not defined
Exception thrown while loading "/gem5/tests/gem5/memcheck/test_memcheck.py"
Ignoring all tests in this file.
```
The test has been modified to have an empty verifiers list, which should
still catch bugs since src/mem/mem_checker.cc has several asserts already
which would be caught by the test system due to the exit status.
Also make the following changes to the test:
- move it to tests/gem5/memory/test.py with other memory tests.
This makes it easier to see all the tests in the source in one go, and
might make it easier to factor certain memory things out later on.
- reduce --maxtick to a value that finishes in 7 seconds on a Lenovo
ThinkPad P51.
The previous value would take 50x longer, which feels too long for a
single test.
- enable --prefetchers to also stress a prefetcher in the test
Change-Id: I58bd598b1142f349d25fa4fa4a8e41529e61a9ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26807
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this change, running:
./build/NULL/gem5.opt configs/example/ruby_mem_test.py -m 20000000 \
--functional 10
would only print warning for memory errors such as:
warn: Read access failed at 0x107a00
and there was no way to make the simulation fail.
This commit makes those warnings into errors such as:
panic: Read access failed at 0x107a00
unless --suppress-func-errors is given.
This will be used to automate MemTest testing in later commits.
Change-Id: I1840c1ed1853f1a71ec73bd50cadaac095794f91
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26804
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
According to the debugging spec (page 47), a debugger can test which
triggers are enabled by writing 0 to TSELECT and reading it back. If a
different value is read, the trigger is not supported.
Therefore, we currently always set a different value to indicate that
we do not support any triggers.
Change-Id: If222e913c4517adb2da4f6f0ffeedb4e4808a586
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25659
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
According to the privileged ISA spec, SEPC[0]/MEPC[0] reads always 0
and SEPC[1]/MEPC[1] reads 0 if the compressed extension is disabled.
Additionally, the compressed extension can only be disabled if the next
instruction is 4-byte aligned.
Change-Id: I590c05e4000b59a5ba283f47933f7a92959d8e38
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25658
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
According to page 57 in the RISC-V manual, CSR accesses "need to be
performed in program order with respect to those instructions whose
execution behavior is affected by the state of the accessed CSR".
Thus, we need to make them SerializeAfter to ensure that the following
instructions are executed with the potential changes to the CSR. In
theory, we could be smarter here by only considering write accesses to
CSRs and considering the following instructions, but for now we simply
serialize for every CSR access.
Change-Id: I69391fccaec31c34d944c55bac2f04d37947ebfe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25655
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
That is, RISC-V has now a TLB and page table walker for Sv39 paging
according to the privileged ISA 1.11.
Both the TLB and PT walker are based on x86 (the code duplication of the
page table walkers will be reduced by a separate commit).
Change-Id: I5e29683bdd40c0d32c06e4d75a8382bf313f2086
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25647
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 test covers the templates which attempt to classify types, but not the
actual gathering of arguments of distribution of return values. As before, we
can't really use standard C++ to accurately test for HFAs and HVAs, so we stick
with approximating them by detecting arrays of the right types.
For example, I think technically we should also accept a struct with only 4
float members, but c++ templates aren't able to match against types in that way
as far as I know.
Change-Id: I1d7756a964a86c0c5ea13e068a5fc74603e14e30
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28268
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The templates which checked for short vectors, and our approximation of
HFA, HVA and HXA types were not correct. This change actually simplifies
them along with getting them to produce correct results. In the case of
HXA, there was a logic bug where an && was used where an || was
intended.
There may still be bugs in the actual collection of arguments and
setting of return values since those aspects are harder to test.
Change-Id: Ice3177205a98c678ecb43ba600813b3909c44e6b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28267
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
