There are cases where we need a random number generator engine. The
Random class has such an engine but its interface currently only
allows for generating random numbers. To make sure we can reuse the
same random number generator in as many places as possible this patch
makes the engine in the Random class public.
Change-Id: I80153dd39f5b0d12537e4c0cf54773e7725b2a94
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47859
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 patch adds support for a gfx902 Vega APU, ripping the
appropriate values for device_id from the ROCm Thunk
(src/topology.c).
Note: gfx902 isn't officially supported by ROCm. This
means that it may not work for all programs. In particular,
rocBLAS is incompatible with gfx902, so anything that uses
rocBLAS won't be able to run with gfx902.
Change-Id: I48893e7cc9c7e52275fdfd22314f371a9db8e90a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47530
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Remove the duplicate dmaVirt calls from HSA packet processor and GPU
command processor and move them into their own class. This removes some
duplicate code and allows a DmaVirtDevice to be created which will be
useful for upcoming full system GPU commits.
The DmaVirtDevice is an abstraction of the base DmaDevice but iterates
using ChunkGenerator over virtual addresses. Classes which inherit from
DmaVirtDevice must provide a translation function to translate from
virtual address to physical address. Once translated, the physical
address is passed to DmaDevice to do the work.
Change-Id: Idd59ccb4d9ba21c0b1150ee328ededf5a88d824e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47179
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add an accuracy and coverage stat for the prefetchers.
Accuracy is defined as the ratio of the number of prefetch
request that have been counted as useful over the number
of prefetch request issued.
Accuracy tells whether the prefetcher is producing useful
requests or not.
Coverage is defined as the ratio of of the number of prefetch
request that have been counted as useful over the number of
demand misses if there was no prefetch, which is counted as
the number of useful prefetch request plus the remaining
demand misses. Due to the way stats are defined in the cache,
I have to add a stat to count the number of remaining demand
misses directly in the prefetcher stat. Demand is defined
as being one of this request type: ReadReq, WriteReq,
WriteLineReq, ReadExReq, ReadCleanReq, ReadSharedReq.
Coverage tells what part of misses are covered by the prefetcher.
Change-Id: I3bb8838f87b42665fdd782889f6ba56ca2a802fc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47603
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
Count how many time a prefetch is useful, meaning
a hit has happened on a prefetched cache block.
Another stat (pfUsefulButMiss) has been added to count
the special case where there is a hit on prefetched block
but it is counted as a miss because the block is not in
the requested coherency state.
Change-Id: I253216b9ac96d5f21139b710c489d6eb3fce7136
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47602
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
The apertures for non-gfx801 GPUs are set differently.
If the apertures aren't set properly, ROCm will error out.
This change sets the apertures appropriately based on the
gfx version of the simulated GPU. It also adds in new
functions to set the scratch and lds apertures in GFX9 to mimic
the linux kernel.
Change-Id: I1fa6f60bc20c7b6eb3896057841d96846460a9f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47529
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a unit test for stats/info.
One test has been disabled due to not knowing the
expected behavior.
It is important to notice that Stats::Info can have
duplicate names using the new style. Stats::Group is
responsible for not allowing duplicate names in this
case.
Change-Id: I8b169d34c1309b37ba79fa9cf6895547b7e97fc0
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43009
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
When the Vega ISA got committed, it lacked the request counter
tracking for memory requests that existed in the GCN3 code.
Instead of copying over the same lines from the GCN3 code to the Vega
code, this commit makes the various memory pipelines handle updating the
request counter information instead, as every memory instruction calls a
memory pipeline.
This commit also adds an issueRequest in scalar_memory_pipeline, as
previously, the gpuDynInsts were explicitly placed in the queue of
issuedRequests.
Change-Id: I5140d3b2f12be582f2ae9ff7c433167aeec5b68e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45347
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
vector_register_file uses the exec_mask of a memory instruction in
order to determine if it should mark a register as in-use or not.
Previously, the exec_mask of memory instructions was only set on
execution of that instruction, which occurs after the code in
vector_register_file. This led to the code reading potentially garbage
data, leading to a scenario where a register would be marked used when
it shouldn't be.
This fix sets the exec_mask of memory instructions in schedule_stage,
which works because the only time the wavefront execMask() is updated is
on a instruction executing, and we know the previous instruction will
have executed by the time schedule_stage executes, due to the order the
pipeline is executed in.
This also undoes part of a patch from last year (62ec973) which treated
the symptom of accidental register allocation, without preventing the
registers from being allocated in the first place.
This patch also removes now redundant code that sets the exec_mask in
instructions.cc for memory instructions
Change-Id: Idabd35020000764fb06133ac2458606c1aaf6f04
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45346
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Certain memory writes were reading their registers in
initiateAcc, which lead to scenarios where a subsequent instruction
would execute, clobbering the value in that register before the memory
writes' initiateAcc method was called, causing the memory write to read
wrong data.
This patch moves all register reads to execute, preventing the above
scenario from happening.
Change-Id: Iee107c19e4b82c2e172bf2d6cc95b79983a43d83
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45345
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Alex Dutu <alexandru.dutu@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Instruction fetch should not commence if there already is an
instruction-count event in the queue.
The most conspicuous scenario where this leads to obvious breakage,
is guest debugging. Imagine the first bytes in the program pointed to
by _start are invalid instruction encoding, and we pass the --wait-gdb
flag. Then in GDB we set $pc to point to valid instructions, and we
"continue". gem5 will abort with "invalid instruction".
This is not how real targets behave: neither software- (e.g. ptrace)
based debuggers, nor low-level (e.g. OpenOCD or XMD connected over
JTAG to debug early initialization code eg when the MMU has not been
switched on yet, etc.) Fetching should start from where $pc was set
to. This patch tries to model this behavior.
Change-Id: Ibce6fdbbb082edf1073ae96745bc7867878f99ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27587
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a non-standard extension to the RSP protocol: the "." command
requests a dump of the simulated page table.
The dump consists of concatenated records, one record per page table
entry. Each record contains the entry's "virtual" value written as
hex, followed by a colon (:), followed by the entry's "physical" value
written as hex, followed by a semicolon (;).
At the time of writing, one practical use of this feature (in
combination with the "shared_backstore" parameter) is extremely fast
Miranda-Ingalls simulation of JIT compilers.
Change-Id: I333ed11d4ce671251d0b93cddae3bbcea44ea4ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47719
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
