Re: [gem5-dev] Review Request 3814: misc: Add a CONTRIBUTING document

; Restricting maintainer to be PMC member seems too restrictive. When someone contributes large portions of the code (especially code that adds new features) the contributor will likely be the best person to maintain the code. - Brad Beckmann On Feb. 21, 2017, 5:34 p.m., Jaso

Re: [gem5-dev] Review Request 3824: gpu-compute: Fix Python/C++ object hierarchy discrepancies

> On Feb. 25, 2017, 1:04 a.m., Brad Beckmann wrote: > > src/mem/ruby/system/GPUCoalescer.py, line 50 > > <http://reviews.gem5.org/r/3824/diff/2/?file=66267#file66267line50> > > > > This patch points out that we really should not have an icache or > &g

Re: [gem5-dev] Review Request 3814: misc: Add a CONTRIBUTING document

989> Where is the "Generate Password" option? I don't see it after signing in. Is this password unique to just pushing patches to gerrit and is it independent of your google account password? - Brad Beckmann On Feb. 21, 2017, 5:34 p.m., Jason

Re: [gem5-dev] Review Request 3824: gpu-compute: Fix Python/C++ object hierarchy discrepancies

cl. prefetches) outstanding") - Brad Beckmann On Feb. 22, 2017, 9:28 a.m., Andreas Sandberg wrote: > > --- > This is an automatically generated e-mail. To reply

Re: [gem5-dev] Review Request 3773: ruby: PerfectSwitch add assured access arbitration

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3773/#review9318 --- Ship it! Ship It! - Brad Beckmann On Jan. 25, 2017, 6:49 a.m., Joel

Re: [gem5-dev] Review Request 3773: ruby: PerfectSwitch add assured access arbitration

on? This is quite a complicated, long while loop. It would be nice to break it up and make it more readable. - Brad Beckmann On Dec. 23, 2016, 3:09 p.m., Joel Hestness wrote: > > --- > This is an automatically generated e-ma

Re: [gem5-dev] Review Request 3742: ruby: Fix overflow reported by ASAN in MessageBuffer.

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3742/#review9143 --- Ship it! Ship It! - Brad Beckmann On Nov. 21, 2016, 10:32 p.m

Re: [gem5-dev] Review Request 3689: tests, ruby: Move rubytests from ALPHA (linux) to NULL (none)

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3689/#review9040 --- Ship it! Ship It! - Brad Beckmann On Oct. 27, 2016, 7:50 a.m

[gem5-dev] changeset in gem5: mem: minor dprintf fix to abstract mem

changeset fab5e4523380 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=fab5e4523380 description: mem: minor dprintf fix to abstract mem print number of bytes written as a decimal number, not hex diffstat: src/mem/abstract_mem.cc | 2 +- 1 files changed, 1

[gem5-dev] changeset in gem5: ruby: correct size for partial memory writes

changeset 49cbf4bb0d36 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=49cbf4bb0d36 description: ruby: correct size for partial memory writes Fixed AbstractController::queueMemoryWritePartial to specify the correct size for partial memory writes.

Re: [gem5-dev] Review Request 3591: ruby: Allow multiple outstanding DMA requests

> On Sept. 1, 2016, 3:33 p.m., Jason Lowe-Power wrote: > > What testing did you perform to make sure all of the protocols were > > modified correctly? > > > > Most of these changes seem reasonable to me, but I know from experience > > that even when the SLICC changes seem like they are right,

Re: [gem5-dev] Review Request 3580: cpu, mem, sim: Enable KVM support for Ruby

ccesses should only be > used when the guest system is in rest, but clearly we are not sticking to > that at the moment. > > The MemChecker is a good start in checking that the timing behaviuor > works as expected with respect to the consistency model, but it is not

Re: [gem5-dev] Review Request 3580: cpu, mem, sim: Enable KVM support for Ruby

> On Aug. 5, 2016, 7:15 a.m., Andreas Hansson wrote: > > I see how this works as a stop gap, but ultimately I would like to push for > > the removal of the shadow memory as the first option. Is it really that > > much effort? > > David Hashe wrote: > I'm not personally familiar enough

Re: [gem5-dev] Review Request 3574: arm: Don't report the boot ROM as a memory in config tables

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3574/#review8563 --- Ship it! Ship It! - Brad Beckmann On July 22, 2016, 3:04 p.m

Re: [gem5-dev] Review Request 3573: tests: Add regex-based ignore rules for ref files

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3573/#review8562 --- Ship it! Ship It! - Brad Beckmann On July 22, 2016, 3:04 p.m

Re: [gem5-dev] Review Request 3578: ruby: Size the MI_example directory to cover all phys mem

> On July 25, 2016, 2:26 p.m., Jason Lowe-Power wrote: > > This seems like it's OK. The only problem that may crop up is that the > > DirectoryMemory pre-populates an entry for every block in physical memory > > (as configured here). So, if the max physical memory is high, you may run > > out

Re: [gem5-dev] Review Request 3577: arm, config: Add initial support for Ruby

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3577/#review8538 --- Ship it! Ship It! - Brad Beckmann On July 22, 2016, 3:06 p.m

Re: [gem5-dev] Review Request 3576: arm, dev: Add support for listing DMA ports in new platforms

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3576/#review8537 --- Ship it! Ship It! - Brad Beckmann On July 22, 2016, 3:05 p.m

Re: [gem5-dev] Review Request 3575: ruby: Implement support for functional accesses to PIO ranges

patch in our internal patch queue here at AMD. This is a good reminder that we need to get our patches out there publicly. - Brad Beckmann On July 22, 2016, 3:47 p.m., Andreas Sandberg wrote: > > --- > This is an automatically ge

Re: [gem5-dev] Review Request 3449: Add support for McVerSi memory consistency verification framework

> On May 6, 2016, 4:08 p.m., Brad Beckmann wrote: > > Looks good to me. Please check this one in with > > http://reviews.m5sim.org/r/3398/. Thanks! > > Marco Elver wrote: > Thank you! Just to let you know, I do not have commit access, so someone &g

Re: [gem5-dev] Review Request 3449: Add support for McVerSi memory consistency verification framework

ailing whitespace src/sim/pseudo_inst.hh (line 92) <http://reviews.gem5.org/r/3449/#comment7088> align with the beginning '(' src/sim/pseudo_inst.hh (line 97) <http://reviews.gem5.org/r/3449/#comment7089> align with the beginning '(' - Brad Beckmann On April 13, 2016, 7:53

Re: [gem5-dev] Review Request 3428: ruby: pass in block size to ENTRY objects with block size

> On April 6, 2016, 9:46 p.m., Andreas Hansson wrote: > > For the classic memory system, all caches before the point of coherency > > have the same line size, and it is a property of the system. Is this change > > departing from this assumption for Ruby? What is the bigger picture here? > >

Re: [gem5-dev] Review Request 3449: Add support for McVerSi memory consistency verification framework

> On April 13, 2016, 5:49 p.m., Andreas Hansson wrote: > > Really nice to see more work along these lines. > > > > I am keen to make sure we "finish what we started", and for that reason I > > would like to understand how this relates to the existing MemChecker. Also, > > I'd really like to

Re: [gem5-dev] Review Request 3441: ruby: fix MESI_Three_Level protocol

> On April 13, 2016, 7:08 p.m., Joel Hestness wrote: > > configs/ruby/MESI_Three_Level.py, line 153 > > > > > > This change connects the L0 caches to the network rather than > > connecting them directly to the L1 caches.

Re: [gem5-dev] Review Request 3449: Add support for McVerSi memory consistency verification framework

does not display correctly. Did you post it from a Mecrurail repo using the "hg postreview -o" command? I know your patch applies to an earlier version of the repo, but I believe it should still display correclty if you use the '-o' option. Thanks. - Brad Beckmann On April 13,

Re: [gem5-dev] Review Request 3443: garnet: fix bug where multiple enqueues happen on same tick

> On April 6, 2016, 9:37 p.m., Andreas Hansson wrote: > > How is that logically possible? Doesn't that suggest something is > > fundamentally wrong? > > Brandon Potter wrote: > I need to reproduce this problem and reconfirm how I arrived at this > solution. I felt confident enough to

Re: [gem5-dev] Review Request 3363: pwr: Add power states to ClockedObject

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3363/#review8110 --- Ship it! Ship It! - Brad Beckmann On March 5, 2016, 12:21 a.m

Re: [gem5-dev] Review Request 3338: gpu-compute: fix gpu memfence

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3338/#review8020 --- Ship it! Ship It! - Brad Beckmann On Feb. 23, 2016, 12:40 a.m., Marc

Re: [gem5-dev] Review Request 3337: gpu-compute: fix uninitialized value error.

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3337/#review8021 --- Ship it! Ship It! - Brad Beckmann On Feb. 23, 2016, 12:39 a.m., Marc

Re: [gem5-dev] Review Request 3283: ruby: Make MessageBuffers actually finite sized

tarved by younger ones. There is already comments in the .cc file that effectively say this, but if you are going to added detailed comments to this file as well, I think it is important to make that point. - Brad Beckmann On Jan. 17, 2016, 11:47 p.m., Joel Hestness

Re: [gem5-dev] Review Request 3273: gpu: parametrize Wavefront size

. Thanks - Brad Beckmann On Jan. 14, 2016, 9:59 p.m., John Kalamatianos wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem

[gem5-dev] changeset in gem5: ruby: removed Write_Only AccessPermission

changeset 01e65448c425 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=01e65448c425 description: ruby: removed Write_Only AccessPermission diffstat: src/mem/protocol/RubySlicc_Exports.sm | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diffs (11 lines):

[gem5-dev] changeset in gem5: ruby: changed all references to numCPs to num-cp

changeset b4bbf540d1a7 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=b4bbf540d1a7 description: ruby: changed all references to numCPs to num-cp diffstat: configs/example/ruby_gpu_random_test.py | 2 +- configs/ruby/GPU_RfO.py | 2 +-

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Jan. 14, 2016, 6:26 p.m., Andreas Hansson wrote: > > configs/ruby/GPU_RfO.py, line 80 > > > > > > there seems to be an awful lot of repetition of boilerplate code > > involved in these scripts, can the common parts not

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Jan. 13, 2016, 10:47 p.m., Andreas Hansson wrote: > > ...and yes, please split the patch to make it reviewable (if that is a > > word). > > Brad Beckmann wrote: > Andreas, we simply do not have the time and resources to do so. We have > spent a lot of tim

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Jan. 14, 2016, 6:26 p.m., Andreas Hansson wrote: > > configs/common/GPUTLBConfig.py, line 76 > > > > > > the location of the file, and the name of the functions make it seem > > quite generic, when in fact it is very

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Jan. 14, 2016, 6:41 p.m., Andreas Hansson wrote: > > src/mem/ruby/structures/CacheMemory.cc, line 38 > > > > > > This seems like a piece of functionality that is independent from the > > compute-gpu. A patch on its

Re: [gem5-dev] Review Request 3185: mem: misc flags for AMD gpu model

> On Jan. 13, 2016, 10:06 p.m., Andreas Hansson wrote: > > src/mem/protocol/RubySlicc_Exports.sm, line 44 > > > > > > seems unrelated These functions are modified an used by patch 3206. Ideally this change should've been

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> reason for this? > > Tony Gutierrez wrote: > That is the license required by our legal team. It's BSD-style, so it > shouldn't be an issue. > > Andreas Hansson wrote: > I just picked up on the fact that it's different, and was not sure why. > It should not be a problem

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Jan. 13, 2016, 10:47 p.m., Andreas Hansson wrote: > > ...and yes, please split the patch to make it reviewable (if that is a > > word). Andreas, we simply do not have the time and resources to do so. We have spent a lot of time addressing Joel's changes and we have and will address the

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Nov. 13, 2015, 11:03 p.m., Joel Hestness wrote: > > src/mem/protocol/RubySlicc_Exports.sm, line 243 > > > > > > Please describe these more clearly. What is a CorePair? What do "TCP", > > "TCC", "SQC" stand for? Etc. >

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Nov. 20, 2015, 7:59 p.m., Joel Hestness wrote: > > src/mem/protocol/RubySlicc_Types.sm, line 136 > > > > > > These don't appear to be defined or used anywhere. Can you please > > remove them? Sure thing. These can

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Nov. 10, 2015, 7:51 p.m., Andreas Sandberg wrote: > > This is indeed very impressive! However, as it is, this patch is basically > > the definition of unreviewable. Could you split it into a handful of > > different patches for review purposes? ReviewBoard makes all kinds of > >

Re: [gem5-dev] Review Request 3205: mem: support for gpu-style RMWs in ruby

> On Jan. 6, 2016, 9:39 p.m., Andreas Hansson wrote: > > I still find that the design needs a far better explanation, and at least > > one simple example. I would suggest implementing the SwapReq as an atomic > > op (as I guess it is our only example). Also, surely we need to impose > >

Re: [gem5-dev] Review Request 3177: ruby: slicc: have a static MachineType

. Can you please update these and > > provide clearer comments as appropriate? > > Sooraj Puthoor wrote: > I do not know the history behind this change. This is originally a patch > from Nilay (http://reviews.gem5.org/r/2551) and I think Nilay will be the > best person to answer thi

Re: [gem5-dev] Review Request 3244: sim: Add an option to forward work items to Python

, gem5 will execute the entire application and only stops prematurely if the user explicitly asks to exit when work items are encountered. - Brad Beckmann On Dec. 5, 2015, 12:29 a.m., Andreas Sandberg wrote: > > --- > This is a

[gem5-dev] changeset in gem5: regress: updates required for the compute-gpu...

changeset aa32b0639ee2 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=aa32b0639ee2 description: regress: updates required for the compute-gpu patches diffstat: tests/configs/rubytest-ruby.py | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-)

[gem5-dev] changeset in gem5: ruby: more flexible ruby tester support

changeset 452e10b868ea in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=452e10b868ea description: ruby: more flexible ruby tester support This patch allows the ruby random tester to use ruby ports that may only support instr or data requests. This

Re: [gem5-dev] Review Request 3192: ruby: split CPU and GPU latency stats

" or "coalescer". The interfaces for > > these types appear nearly identical, and this would keep the modifications > > to SLICC to a minimum (e.g. these changes would not be necessary). > > Brad Beckmann wrote: > There is a difference between the GP

Re: [gem5-dev] Review Request 3192: ruby: split CPU and GPU latency stats

" or "coalescer". The interfaces for > > these types appear nearly identical, and this would keep the modifications > > to SLICC to a minimum (e.g. these changes would not be necessary). > > Brad Beckmann wrote: > There is a difference between the GP

Re: [gem5-dev] Review Request 3192: ruby: split CPU and GPU latency stats

> On Nov. 12, 2015, 8:08 p.m., Joel Hestness wrote: > > src/mem/slicc/symbols/StateMachine.py, line 313 > > > > > > Not sure if this should be fixed before commit, but I feel it should be > > fixed at some point: > >

Re: [gem5-dev] Review Request 3178: ruby: cleaner ruby tester support

> On Nov. 2, 2015, 5:18 p.m., Jason Lowe-Power wrote: > > configs/ruby/MESI_Three_Level.py, line 104 > > > > > > I hate to be picky, but could you use this code instead: > > > > if len(system.cpu) == 1: > >

[gem5-dev] changeset in gem5: mem: add boolean to disable PacketQueue's siz...

changeset 7b7e352f8d7f in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=7b7e352f8d7f description: mem: add boolean to disable PacketQueue's size sanity check the sanity check, while generally useful for exposing memory system bugs, may be spurious

[gem5-dev] changeset in gem5: ruby: added stl vector of ints to be used by ...

OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + * Authors: Brad Beckmann + */ + +#include "mem/ruby/common/IntVec.hh" + +#include +#include + +std::ostream& operator<<(std::ostream& os, const

Re: [gem5-dev] Review Request 3177: ruby: imported from reviewboard patch 2551

> On Nov. 2, 2015, 8:56 p.m., Joel Hestness wrote: > > src/mem/protocol/RubySlicc_Exports.sm, line 189 > > > > > > I don't understand the reason for distinguising _wCC types. Should > > L1Cache/L2Cache types not provide

Re: [gem5-dev] Review Request 3183: mem: increase arbitrary limit on the packet queue

> On Oct. 30, 2015, 10:17 p.m., Andreas Hansson wrote: > > src/mem/packet_queue.cc, line 117 > > > > > > That is 64 kB of implicit storage! As I've already mentioned many > > times, this check has been instrumental in

Re: [gem5-dev] Review Request 3177: ruby: imported from reviewboard patch 2551

. Can you please update these and > > provide clearer comments as appropriate? > > Sooraj Puthoor wrote: > I do not know the history behind this change. This is originally a patch > from Nilay (http://reviews.gem5.org/r/2551) and I think Nilay will be the > best person to answer thi

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

The GPU is a fully coherent compute module, and the only thing > that is device-like about it is the fact that it takes commands from the CPU > via ioctl() driver calls. It doesn't, e.g., have memory-mapped registers, etc. > > Brad Beckmann wrote: > Furthermore, our GPU is f

Re: [gem5-dev] Review Request 3189: gpu: AMD's baseline GPU model

> On Oct. 30, 2015, 10:27 p.m., Andreas Hansson wrote: > > Impressive! > > > > Should it not be src/dev/gpu rather than src/gpu? > > > > Also, could you please make it a subdirectory in the gpu dir (as from > > above). There are more GPUs in this world...in fact there is already the > >

Re: [gem5-dev] Review Request 3121: ruby: block size in RubySystem to be object specific

> On Sept. 17, 2015, 5:43 p.m., Brad Beckmann wrote: > > Do *not* check in this patch. I know I've already saidy this, but I will > > repeat, do not make further changes to the sm files until we check in our > > GPU patches. > > > > Even after we check in

Re: [gem5-dev] Review Request 3134: ruby: combine RubyPort and Sequencer and rename as FirstLevelController

> On Sept. 24, 2015, 11:32 p.m., Brad Beckmann wrote: > > Do not check this in. I suggest you stop going in this direction. Any > > performance benefits provided by this patch do not justify the resulting > > duplicate code and downstream re-correlation an

Re: [gem5-dev] Review Request 3134: ruby: combine RubyPort and Sequencer and rename as FirstLevelController

> On Sept. 24, 2015, 11:32 p.m., Brad Beckmann wrote: > > Do not check this in. I suggest you stop going in this direction. Any > > performance benefits provided by this patch do not justify the resulting > > duplicate code and downstream re-correlation an

Re: [gem5-dev] Review Request 3134: ruby: combine RubyPort and Sequencer and rename as FirstLevelController

synchronization and coalescing that assumes a RFO coherence protocol. The DMA sequencer is a simple interface that handles large, multi-line access. We will be posting the GPU coalescer that assumes weaker GPU coherence and coalesces memory requests across a wavefront. - Brad Beckmann On Sept. 24, 2015

Re: [gem5-dev] Review Request 2987: ruby: consumer: move away from Consumer class

, or an issue with the format of your diff. Please try again, and if you still have trouble, contact support - Brad Beckmann On Sept. 19, 2015, 12:32 a.m., Nilay Vaish wrote: > > --- > This is an auto

Re: [gem5-dev] Review Request 3121: ruby: block size in RubySystem to be object specific

> On Sept. 17, 2015, 5:43 p.m., Brad Beckmann wrote: > > Do *not* check in this patch. I know I've already saidy this, but I will > > repeat, do not make further changes to the sm files until we check in our > > GPU patches. > > > > Even after we check in

Re: [gem5-dev] Review Request 3119: ruby: copy data to TBE only when required

> On Sept. 17, 2015, 5:32 p.m., Brad Beckmann wrote: > > The description of this patch scares me. Is your plan to allocate the data > > block seperately from the cache entry data structures? Why don't we move > > all the creation of the cache entires and data bl

Re: [gem5-dev] Review Request 3118: ruby: bloom filters: refactor code

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3118/#review7203 --- Ship it! Ship It! - Brad Beckmann On Sept. 17, 2015, 1:18 a.m

Re: [gem5-dev] Review Request 3119: ruby: copy data to TBE only when required

does not allow defining constructors that can take input arguments". Doesn't SLICC support "constructor_hacks"? - Brad Beckmann On Sept. 17, 2015, 1:18 a.m., Nilay Vaish wrote: > > --- > This is an automatically ge

Re: [gem5-dev] Review Request 3121: ruby: block size in RubySystem to be object specific

. First off, there are many, many unrelated style changes in this patch. Second, you cannot remove the Subblock object. The Subblock object is an important data structure for all testers. Beyond the RubyTester, we have internal testers that rely on the Subblock object. - Brad Beckmann

Re: [gem5-dev] Review Request 3013: ruby: convert global statistical variables to local ones.

> On Sept. 9, 2015, 12:20 a.m., Nilay Vaish wrote: > > Any comments on this patch? Planning to push it in a week. Do not push this patch. Brandon Potter has a patch that removes global variables and does so without eliminated the generated Ruby stats. - Brad

Re: [gem5-dev] Review Request 3013: ruby: convert global statistical variables to local ones.

013/#comment6039> These aggregated statistics are essential for Protocol performance debugging. It is hard enough that these stats are not as concise as they used to be with ruby.stats. We cannot get rid of them. - Brad Beckmann On Aug. 9, 2015, 6:26 p.m., Nilay Vaish

Re: [gem5-dev] Review Request 3002: ruby: slicc: fix naming of variables

> On Sept. 4, 2015, 11:34 p.m., Brad Beckmann wrote: > > So there has been a lot of discussion on this patch, including splitting > > the patch up, but I have not seen a new version of the patch reposted. > > > > Again I really dislike these patches wh

Re: [gem5-dev] Review Request 3095: ruby: remove unused function removeRequest()

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3095/#review7158 --- Ship it! Ship It! - Brad Beckmann On Sept. 5, 2015, 12:19 a.m

Re: [gem5-dev] Review Request 3013: ruby: convert global statistical variables to local ones.

> On Aug. 14, 2015, 10:05 p.m., Joel Hestness wrote: > > Looks good to me. > > > > Though I haven't often found use for these aggregated stats, do we have an > > aim or plan for adding them back? Could we use the Python stats > > post-processing capabilities? > > Nilay Vaish wrote: > I

Re: [gem5-dev] Review Request 3094: ruby: sequencer: remove commented out function printProgress()

in the past for protocol debugging. It obviously would need to be updated to work in today's gem5. I don't see the harm in keeping this code around, but I'm not going to fight for it. Go ahead if you think it is important to remove this code. - Brad Beckmann On Sept. 5, 2015, 12:19 a.m

Re: [gem5-dev] Review Request 3079: ruby: perfect switch: refactor code

. There shouldn't be many conflicts with this patch. - Brad Beckmann On Sept. 9, 2015, 7:25 p.m., Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem

Re: [gem5-dev] Review Request 2787: ruby: Fixed pipeline squashes caused by aliased requests

> the max_outstanding_requests greater than the LSQ depth fixes this, but > > this performance bug indicates that the coalescing in the sequencer > > introduces more non-trivial configuration to get reasonable MLP. > > > > Overall, I feel that this patch needs to b

Re: [gem5-dev] Review Request 3083: ruby: slicc: remove nextLineHack from Type.py

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3083/#review7119 --- Ship it! Ship It! - Brad Beckmann On Sept. 2, 2015, 12:52 a.m

Re: [gem5-dev] Review Request 2787: ruby: Fixed pipeline squashes caused by aliased requests

> the max_outstanding_requests greater than the LSQ depth fixes this, but > > this performance bug indicates that the coalescing in the sequencer > > introduces more non-trivial configuration to get reasonable MLP. > > > > Overall, I feel that this patch needs to b

Re: [gem5-dev] Review Request 3083: ruby: slicc: remove nextLineHack from Type.py

> On Sept. 2, 2015, 7:41 p.m., Jason Lowe-Power wrote: > > Do you know what this was used for? I've never encountered this, but it > > probably had a good reason to be there at some point... > > Nilay Vaish wrote: > None of the current protocols use it. The line has seen not any changes

Re: [gem5-dev] Review Request 3006: ruby: simple network: store Switch* in PerfectSwitch and Throttle

> On Sept. 2, 2015, 12:52 a.m., Nilay Vaish wrote: > > Does any one has any comments on this patch? I don't have any problems with this patch, but I'm curious what is the motivation? - Brad --- This is an automatically generated

Re: [gem5-dev] Review Request 2787: ruby: Fixed pipeline squashes caused by aliased requests

> On Aug. 30, 2015, 6:01 p.m., Joel Hestness wrote: > > Hi guys, > > > > I'm not sure of the status of or plans for this patch, but I wanted to test > > it out and provide some feedback. I've merged and tested this with the > > current gem5 head (11061). First, there are a number of things

Re: [gem5-dev] Review Request 3002: ruby: slicc: fix naming of variables

On Aug. 13, 2015, 5:59 p.m., Brad Beckmann wrote: Recently we discarded patch 2786 because it optionally allowed SLICC programs to specify whether an object is a pointer or not. Our patch was motivated because PerfectCacheMemory differed from CacheMemory and was a pretty special

Re: [gem5-dev] Review Request 2987: ruby: consumer: move away from Consumer class

thought it existed just to make sure that a single event was only scheduled on a single event queue. It seems like the code requires the event to be set as well. Perhaps this is why you say the patch is incomplete and that Garnet will not work. - Brad Beckmann On July 24, 2015, 4:45

Re: [gem5-dev] Review Request 3001: ruby: declare all protocol message buffers as parameters

On Aug. 14, 2015, 8:50 p.m., Joel Hestness wrote: Wow... wish I had thought to do this so it could have been checked in with the rest of the MessageBuffer SimObject patch. I hope we can get it in soon. @Brad and/or AMD crew: If you see this review, I'd recommend checking out this

Re: [gem5-dev] Review Request 3001: ruby: declare all protocol message buffers as parameters

this patch soon, since it could save some time merging with MessageBuffer changes I just pushed. Brad Beckmann wrote: Can you explain how this makes it easier to merge with your changes? Joel Hestness wrote: Just so you don't have to merge twice. If we were to wait for this patch, we

Re: [gem5-dev] Review Request 3002: ruby: slicc: fix naming of variables

://reviews.gem5.org/r/3002/#comment5963 Is moving the global fwd_set variable to a local variable orthogonal to the rest of this patch? - Brad Beckmann On Aug. 3, 2015, 12:15 a.m., Nilay Vaish wrote: --- This is an automatically

Re: [gem5-dev] Review Request 3002: ruby: slicc: fix naming of variables

/3002/#comment5966 this is a lot of code change just to eliminate these few lines of code. - Brad Beckmann On Aug. 3, 2015, 12:15 a.m., Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http

Re: [gem5-dev] Review Request 3002: ruby: slicc: fix naming of variables

On Aug. 13, 2015, 5:59 p.m., Brad Beckmann wrote: Recently we discarded patch 2786 because it optionally allowed SLICC programs to specify whether an object is a pointer or not. Our patch was motivated because PerfectCacheMemory differed from CacheMemory and was a pretty special

[gem5-dev] changeset in gem5: slicc: fix error in conflicing symbol declara...

changeset d87a25259254 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=d87a25259254 description: slicc: fix error in conflicing symbol declaration diffstat: src/mem/slicc/symbols/SymbolTable.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12

[gem5-dev] changeset in gem5: slicc: improved stalling support in protocols

changeset b300dcda5896 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=b300dcda5896 description: slicc: improved stalling support in protocols Adds features to allow protocols to reschedule controllers when conditionally stalling within inport logic

[gem5-dev] changeset in gem5: slicc: enable overloading in functions not in...

changeset a86f453a7caa in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=a86f453a7caa description: slicc: enable overloading in functions not in classes For many years the slicc symbol table has supported overloaded functions in external classes. This

[gem5-dev] changeset in gem5: ruby: improved stall and wait debugging

changeset 4fbe4b0adb4d in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=4fbe4b0adb4d description: ruby: improved stall and wait debugging Added dprintfs and asserts for identifying stall and wait bugs. diffstat: src/mem/ruby/network/MessageBuffer.cc

[gem5-dev] changeset in gem5: ruby: add useful dprints to sequencer

changeset 255ebb0b32b4 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=255ebb0b32b4 description: ruby: add useful dprints to sequencer Added two data block dprints that are useful when tracking down data check failures in the ruby random tester.

[gem5-dev] changeset in gem5: util: added .mk makefile extension to file_ty...

changeset c6c28616a57c in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=c6c28616a57c description: util: added .mk makefile extension to file_types.py diffstat: util/file_types.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (11 lines): diff -r

[gem5-dev] changeset in gem5: ruby: re-added the addressToInt slicc interfa...

changeset 19515f842044 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=19515f842044 description: ruby: re-added the addressToInt slicc interface function This helper function is very useful converting address offsets to integers that can be used for

[gem5-dev] changeset in gem5: util: added .cl OpenCL extension to file_type.py

changeset 30c2e8004c0a in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=30c2e8004c0a description: util: added .cl OpenCL extension to file_type.py diffstat: util/file_types.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (11 lines): diff -r

[gem5-dev] changeset in gem5: slicc: fatal-panic on invalid transitions

changeset 7233a5f7ac8f in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=7233a5f7ac8f description: slicc: fatal-panic on invalid transitions diffstat: src/mem/slicc/symbols/StateMachine.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12 lines):

Re: [gem5-dev] Review Request 2787: ruby: Fixed pipeline squashes caused by aliased requests

On July 31, 2015, 11:13 p.m., Joel Hestness wrote: Thanks for updating this and apologies for the delayed review. Besides the comments below, this looks a lot more agreeable. We are just hours away from checking our code in, so we won't be able to address your comments. We did put a

Re: [gem5-dev] Review Request 2988: ruby: slicc: have c++ code in action blocks

On July 24, 2015, 3:13 p.m., Brad Beckmann wrote: I'm surprised you moved forward on this patch. I thought I had communicated over email a few weeks ago that we should not go down this path before a lot of careful thought and debate on whether this is a good thing to do. Personally

  1   2   3   >