We want to insist that the fast model libraries are the static versions
so they don't have to be found on non-system paths at run time, but we
don't need or want to do the same for system libraries which are from
standard paths on the host system.
Split the set of libraries fast model adds to the build into ones that
come from fast model itself, and ones it needs which should be
provided by the system. The ones from fast model itself should still
go through staticify, but the system libraries should be passed to the
compiler generically so it can pick which version it wants.
Change-Id: I222c94f8117143b86377150e686a4af669a994fe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51627
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code which generated SimObject related param wrappers, cxx wrappers,
enum headers, etc was organized strangely. All the functions which
were used as SCons Actions were listed next to each other, and then all
the code which would set up each of those types of files and actually
use the Actions were next to each other.
This change rearranges that code so that the Action function is
immediately before the code which applies it. Or in other words, this
section of the SConscript is now grouped by the files being created,
rather than the type of the piece of machinery being defined to do that.
Change-Id: Ideee7bd44dac89c51840ec5970d95f6ccbbd1c8f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49402
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
GFX7 (not supported in gem5) and GFX8 have a bug with how virtual
addresses are calculated for their HSA queues. The ROCr component of
ROCm solves this problem by doubling the HSA queue size that is
requested, then mapping all virtual addresses in the second half of the
queue to the same virtual addresses as the first half of the queue.
This commit fixes gem5's support to mimic this behavior.
Note that this change does not affect Vega's HSA queue support, because
according to the ROCm documentation, Vega does not have the same problem
as GCN3.
Change-Id: I133cf1acc3a00a0baded0c4c3c2a25f39effdb51
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51371
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
All syscalls with the "at" suffix rely on a directory file descriptor
(dirfd) and a pathname, provided as arguments to the syscall
If the pathname is relative, then it is interpreted relative to the
directory referred to by the file descriptor dirfd (rather than relative
to the current working directory of the calling process)
Prior to this patch, only the openat syscall was properly implemented.
Other syscalls were discarding the dirfd argument and producing
a warning instead
JIRA: https://gem5.atlassian.net/browse/GEM5-1098
Change-Id: I0cc20c6ef79fca8c8d1c2c9a52eb54ede3d51312
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51048
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
Align allocation requests in Process::allocateMem to page boundaries,
rather than assume that they already are. This frees the caller from
having to know what boundary to align things to. The older version would
make the caller more aware of the extent of the allocation in theory,
but in reality the caller would just blindly perform the alignment like
this function is anyway.
Change-Id: I897714d4481d961255a9e44ae080135e507be199
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50757
Reviewed-by: Matthew Poremba <matthew.poremba@amd.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>
Currently, if a maintainer is removed from a change, the maintainer
will be added again. This change prevents the bot from adding the
removed maintainer again.
The bot will query all updates related to reviewer addition/removal
for each new change. If a reviewer has ever been added/removed
from a change, that reviewer won't be added to that change again.
Change-Id: Ifaab5ebd7ebf3e6453b2551d3e37c1b9e214c906
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50187
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The LSQSenderState that was attached to Request was not useful.
All the fields were either a duplicate of information in the
LSQRequest or totally unused.
The LSQRequest class now inherits from Packet::SenderState and is
attached to the Packet that are sent to memory. We do not need
anymore the indirection Packet->SenderState->LSQRequest.
This helps making the code clearer as it was sometimes hard to
follow the difference between what the LSQRequest and
LSQSenserState was doing
(ex: number of outstanding requests in the memory).
Change-Id: I5b21e007e6d183c6aa79c27c1787ca56dcbc3fb0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50733
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the GPU VIPER TCC protocol handles races between atomics in
the triggerQueue_in. This in_port does not check for resource
availability, which can cause the trigger queue to execute multiple
times. Although this is the expected behavior, the code for handling
atomic races decrements the atomicDoneCnt flag in the trigger queue,
which is not safe since resource contention may cause it to execute
multiple times.
To resolve this issue, this commit moves the decrementing of this
counter to a new action that is called in an event that happens only
when the race between atomics is detected.
Change-Id: I552fd4f34fdd9ebeec99fb7aeb4eeb7b150f577f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51368
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In the GPU VIPER TCC, programs with mixes of atomics and data
accesses to the same address, in the same kernel, can experience
deadlock when large applications (e.g., Pannotia's graph analytics
algorithms) are running on very small GPUs (e.g., the default 4 CU GPU
configuration). In this situation, deadlocks occur due to resource
stalls interacting with the behavior of the current implementation for
handling races between atomic accesses. The specific order of events
causing this deadlock are:
1. TCC is waiting on an atomic to return from directory
2. In the meantime it receives another atomic to the same address -- when
this happens, the TCC increments number of atomics to this address
(numAtomics = 2) that are pending in TBE, and does a write through of the
atomic to the directory.
3. When the first atomic returns from the Directory, it decrements the
numAtomics counter. numAtomics was at 2 though, because of step #2. So
it doesn't deallocate the TBE entry and calls Event:AtomicNotDone.
4. Another request (a LD) to the same address comes along for the same
address. The LD does z_stall since the second atomic is pending –- so the
LD retries every cycle until the deadlock counter times out (or until the
second atomic comes back).
5. The second atomic returns to the TCC. However, because there are so
many LD's pending in the cache, all doing z_stall's and retrying every cycle,
there are a lot of resource stalls. So, when the second atomic returns, it is
forced to retry its operation multiple times -- and each time it decrements
the atomicDoneCnt flag (which was added to catch a race between atomics
arriving and leaving the TCC in 7246f70bfb) repeatedly. As a result
atomicDoneCnt becomes negative.
6. Since this atomicDoneCnt flag is used to determine when Event:AtomicDone
happens, and since the resource stalls caused the atomicDoneCnt flag to become
negative, we never complete the atomic. Which means the pending LD can never
access the line, because it's stuck waiting for the atomic to complete.
7. Eventually the deadlock threshold is reached.
To fix this issue, this commit changes the VIPER TCC protocol from using
z_stall to using the stall_and_wait buffer method that the
Directory-level of the SLICC already uses. This change effectively
prevents resource stalls from dominating the TCC level, by putting
pending requests for a given address in a per-address stall buffer.
These requests are then woken up when the pending request returns.
As part of this change, this change also makes two small changes to the
Directory-level protocol (MOESI_AMD_BASE-dir):
1. Updated the names of the wakeup actions to match the TCC wakeup actions,
to avoid confusion.
2. Changed transition(B, UnblockWriteThrough, U) to check all stall buffers,
as some requests were being placed later in the stall buffer than was
being checked. This mirrors the changes in 187c44fe44 to other Directory
transitions to resolve races between GPU and DMA requests, but for
transitions prior workloads did not stress.
Change-Id: I60ac9830a87c125e9ac49515a7fc7731a65723c2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51367
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
