On Tue, 19 May 2015, Brad Beckmann wrote:
Without changing the queue threshold or providing a feature that allows
one to at least adjust or disable it, we are not resolving the problem,
we are just delaying it.
The RubyPort is not a thin shim. I do not believe the Sequencer has
ever been a thin shim, even in the GEMS days. It has always been a key
component to handling synchronization and gluing cache block memory
requests to instruction granular operations. I do not agree that GPU
coalescing in the RubyPort is a "very bad idea". If we were to
implement it in the other way, we would be arguing over a lot of
extensive changes to packet and request. Furthermore, we would not be
able to implement per-protocol synchronization mechanisms without having
to customize the GPU core for every protocol.
This behavior has very little to do with the ratio of frequencies. If
you are concerned with passing the Ruby clock frequency to the L1
caches, would you be happy if I added a L1 cache frequency parameter to
create_system, a separate L1 freq value to ruby_system, or added logic
that checks for how many cpus are created before trying to reference the
cpu's clk domain value? I'm happy to do any of those options. I'm just
trying to fix the current bug when more than CPU is specified when using
the RubyTester.
Brad, I am surprised that you are proposing that we create another special
case here to handle the problem that exists with tester. I am not it in
favor of it. It is the same approach that AMD is taking with SLICC as
well. Almost everything that AMD wants to do, ends up in a new special
case in the compiler.
Again I am not in favor of putting in special cases in the config files.
I don't think I can convince AMD that this would lead to further problems
in future. I leave it to AMD to do whatever they want to do. I don't
want to continue with the discussion.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
