[gem5-users] Re: Expose C++ enum in SLICC

[Sampad Mohapatra via gem5-users]

Hi Gabriel,

Thanks for the detailed information. My enum is small, so I think this will
work just fine.

Regards,
Sampad

On Mon, Nov 8, 2021 at 6:43 AM Gabriel Busnot via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Sampad,
>
> I don't think that you can import C++ enums in SLICC in a general and sage
> way. SLICC does not support "external enums" so any enum declared in SLICC
> will result in a C++ enum being generated under the gem5::ruby namespace.
>
> One way of safely using external enums (any namespace, scoped enums, etc.)
> is to:
>- define functions that return the enum values you want to use (1
> function per enum value, ideally)
>- declare these functions in a file included in RubySlicc_includes.hh
>- declare the enum name as an external primitive type in SLICC (see
> RubySlicc_Exports.sm for an example)
>- decalre the functions returning enum values in SLICC before using
> them.
>
> You won't be able to use the SLICC enum syntax but you should remain type
> and value safe accross C++ and SLICC.
>
> Regards,
> Gabriel
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Expose C++ enum in SLICC

[Sampad Mohapatra via gem5-users]

Hi All,

Is there a way to expose an enum defined outside SLICC to be used within
SLICC ?
An example of my use case:

*some_src.hh:*

*-*
enum MyEnum { A, B, C};
class MyClass{
  void someFunc( MyEnum) {}
}
...

*some_slicc.sm :*

*---*
structure(MyClass, external='yes')
{
void someFunc( MyEnum);
}
...

Thanks and regards,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Duplicate MessageBuffer creation in GPU_VIPER.py

[Sampad Mohapatra via gem5-users]

Hi All,

The dir_cntrl.requestToMemory is initialized twice in GPU_VIPER.py.
Could this potentially lead to two MessageBuffers being added or the
previous one will just be overwritten ? Is this correct functionality?

https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/configs/ruby/GPU_VIPER.py#448

https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/configs/ruby/GPU_VIPER.py#457

Thanks and regards,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm Correctness Check

[Sampad Mohapatra via gem5-users]

Hi Matt,

The following condition is missing in t_allocateTBE, but the corepair sends
a message with VicDirty - CoherenceRequestType.

if (in_msg.Type == CoherenceRequestType:VicDirty) {
  tbe.DataBlk = in_msg.DataBlk;
}

P.S.: I am not sure whether the complete block should be replaced or just
partially copied.

Thanks,
Sampad

On Sat, Oct 23, 2021 at 2:44 PM Matt Sinclair 
wrote:

> (Resending to mailing list)
>
> Hi Sampad,
>
> There are lines directly below the one I pointed to that do potentially
> overwrite the data there.  But I am not 100% sure -- Brad and Matt P, CC'd
> may know better or see something I'm missing.
>
> Matt
>
> On Sat, Oct 23, 2021 at 1:37 PM Sampad Mohapatra  wrote:
>
>> Yes, but the data is coming from the directory and not the incoming
>> message, which has the actual data.
>>
>> Should it not be:
>> *tbe.DataBlk := in_msg.DataBlk;*
>>
>> i.e., store the dirty victim block data in the tbe.
>>
>> Thanks,
>> Sampad
>>
>> On Sat, Oct 23, 2021 at 1:00 PM Matt Sinclair <
>> mattdsinclair.w...@gmail.com> wrote:
>>
>>> I am not sure I understand completely what you're getting at, but it
>>> appears the allocation of the TBE entry does store the data:
>>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm#878
>>>
>>> Matt
>>>
>>> On Thu, Oct 21, 2021 at 11:08 PM Sampad Mohapatra via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hello All,
>>>>
>>>> I was looking at the MOESI_AMD_Base-CorePair.sm and
>>>> MOESI_AMD_Base-dir.sm and am not quite sure if the following sequence of
>>>> events are correct or not. Can you please verify?
>>>>
>>>> /
>>>> At CorePair -> invokes action "vd_victim", which sends a data block
>>>> with outgoing message.
>>>>
>>>> At Directory -> undergoes "transition(U, VicDirty, BL)" on message
>>>> reception, but doesn't store the received data block in the generated TBE
>>>> and the message is popped out/discarded.
>>>> /
>>>>
>>>> Is the above expected behaviour ?
>>>>
>>>> Thanks and regards,
>>>> Sampad Mohapatra
>>>> ___
>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm Correctness Check

[Sampad Mohapatra via gem5-users]

Hello All,

I was looking at the MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm
and am not quite sure if the following sequence of events are correct or
not. Can you please verify?

/
At CorePair -> invokes action "vd_victim", which sends a data block with
outgoing message.

At Directory -> undergoes "transition(U, VicDirty, BL)" on message
reception, but doesn't store the received data block in the generated TBE
and the message is popped out/discarded.
/

Is the above expected behaviour ?

Thanks and regards,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Pseudo Instruction - m5_reset_stats() - Body Modification

[Sampad Mohapatra via gem5-users]

I see. Thanks for the clarification. Will see if DPRINTF works, otherwise
will write to a file, which should be ok as I am calling m5_stat_reset only
once.

On Tue, Oct 12, 2021 at 10:57 AM Jason Lowe-Power 
wrote:

> I would suggest using DPRINTF instead of cout. It's possible that some
> print statements aren't being flushed.
>
> Jason
>
> On Mon, Oct 11, 2021 at 7:16 AM Sampad Mohapatra  wrote:
>
>> Hi Jason,
>>
>> I have added a std::cout statement to the resetstats()'s body and I am
>> calling m5_reset_stats from my GPU benchmarks.
>> The GPU kernels are launched right after reset is called. I pipe the
>> output of simulations to a file. But, strangely enough
>> some outputs show the std::cout statements while others don't. What could
>> be the reason ?
>>
>> Thanks,
>> Sampad
>>
>> On Mon, Oct 4, 2021 at 12:08 PM Jason Lowe-Power 
>> wrote:
>>
>>> Hi Sampad,
>>>
>>> Here is where m5_reset_stats is implemented in the simulator:
>>> https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/src/sim/pseudo_inst.cc#303
>>>
>>> There are a large number of steps between when the guest code calls
>>> m5_reset_stats and when the above function executes, but this should help
>>> you start hacking :).
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Sat, Oct 2, 2021 at 4:05 AM Sampad Mohapatra via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I need to set a bool variable in src/cpu/simple/base.(hh|cc) to be true
>>>> when m5_reset_stats() is *explicitly *called from some binary
>>>> executing on gem5. Using this bool and instruction count, I want to exit
>>>> the simulation.
>>>>
>>>> How can I modify the body (hack) of m5_reset_stats() to call other
>>>> functions ? Where is its body defined ?
>>>> If not possible, then is there any alternative way to set the bool
>>>> variable when m5_reset_stats() is *explicitly* called ?
>>>>
>>>> Thank You,
>>>> Sampad Mohapatra
>>>>
>>>>
>>>> ___
>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Pseudo Instruction - m5_reset_stats() - Body Modification

[Sampad Mohapatra via gem5-users]

 Hi Jason,

I have added a std::cout statement to the resetstats()'s body and I am
calling m5_reset_stats from my GPU benchmarks.
The GPU kernels are launched right after reset is called. I pipe the output
of simulations to a file. But, strangely enough
some outputs show the std::cout statements while others don't. What could
be the reason ?

Thanks,
Sampad

On Mon, Oct 4, 2021 at 12:08 PM Jason Lowe-Power 
wrote:

> Hi Sampad,
>
> Here is where m5_reset_stats is implemented in the simulator:
> https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/src/sim/pseudo_inst.cc#303
>
> There are a large number of steps between when the guest code calls
> m5_reset_stats and when the above function executes, but this should help
> you start hacking :).
>
> Cheers,
> Jason
>
> On Sat, Oct 2, 2021 at 4:05 AM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All,
>>
>> I need to set a bool variable in src/cpu/simple/base.(hh|cc) to be true
>> when m5_reset_stats() is *explicitly *called from some binary executing
>> on gem5. Using this bool and instruction count, I want to exit the
>> simulation.
>>
>> How can I modify the body (hack) of m5_reset_stats() to call other
>> functions ? Where is its body defined ?
>> If not possible, then is there any alternative way to set the bool
>> variable when m5_reset_stats() is *explicitly* called ?
>>
>> Thank You,
>> Sampad Mohapatra
>>
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: GCN3 - Polybench GPU - SPEC 17 - Errors

[Sampad Mohapatra via gem5-users]

Hi Matt,

Thanks for the quick reply.

I am running the benchmarks on research clusters where running docker is
not permitted and hence I have to build everything and install locally.
I have made modifications to the coherence protocol and porting it to a
newer Gem5 version may take some time and hence I am stuck with v21.0.0 for
now.
Although the modifications are basically flags to identify certain packet
types, so I am assuming that I haven't broken the protocol.
Also, I have run the *square *benchmark and *2DConvolution, FDTD-2D *to
completion (compared with cpu execution result) for smaller input sizes.
If this version of GEM5 supports anything higher than rocm 1.6.x, I will
try to build and use it.

To build hcc, I have used the following command. I looked at the
CMakelist.txt of other dependencies, but, they don't seem to be using
HSA_AMDGPU_GPU_TARGET  variable:
cmake -DCMAKE_INSTALL_PREFIX=rocm/hcc -DROCM_ROOT=rocm
-DHSA_AMDGPU_GPU_TARGET="gfx801" -DCMAKE_BUILD_TYPE=Release ..

And I build polybench using:
hipcc --amdgpu-target=gfx801 -O2 2DConvolution.cpp -Igem5/include
-Lgem5/util/m5/build/x86/out -Lgcc/lib64 -o 2DConvolution.exe -lm5

I do remember that while compiling HCC, *bin/cmake-tests* build was failing
because it was using the generated *clang++* which was unable to find
*libstdc++.so.*
LIBRARY_PATH is ignored (compile time) by the generated clang++ maybe.
So, I modified the generated CMake file to add a " -Lgcc/lib64" to it so
that it completes *make* and *make install*. The downside is I have to
explicitly place *" -Lgcc/lib64 *"
while compiling benchmarks using hipcc. Also, *square  *completes, so I
think LD_LIBRARY_PATH works(runtime).

I did see the commits you recently merged, but I wasn't sure whether I can
retroactively add them to v21.0.0 which also has my own modifications.
Should I go ahead and make the VIPER_TCC changes ?

Also, I will definitely try to submit the benchmarks if they work out.

Regards,
Sampad

On Sat, Oct 9, 2021 at 12:34 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Sampad,
>
> I have not seen anyone attempt to run workloads in a way you are
> attempting, so I can't offer every solution, but here are a few things I
> noticed:
>
> - Why are you still using ROCm 1.6.x?  And why did you build it from
> source?  I strongly recommend using the built-in docker support (which
> supports ROCm 4.0 now).  The error #4 you are having is almost definitely
> because something you built from source is not built correctly. But the
> possible causes of this error are disparate, so I can't suggest anything
> specific about how to fix it.  Basically, that error means something went
> wrong when running the application, which almost always (in my experience)
> is due to not installing ROCm correctly.  If you need to continue on with
> ROCm 1.6.x, I would recommend looking at the old commits before ROCm 4.0
> support was added, and use the docker support there.
>
> - Error #3 likely comes from how you are compiling the program with
> hipcc/hcc.  Depending on which commit you are using, you need to only use
> gfx801, gfx803, gfx900, or gfx902.  Since you seem to be using a slightly
> older setup, probably the issue is you are compiling for something other
> than gfx801 (also if you are compiling for gfx803 or gfx900, did you use
> the -dgpu flag on the command line?).  It is likely error #1 is related to
> this too.
>
> - Error #2 will require getting a Ruby trace and looking at what's
> happening with those addresses (ProtocolTrace debug flag is the most
> important flag to use).  You may find the following useful:
> https://www.gem5.org/documentation/learning_gem5/part3/MSIdebugging/.
> Having said that, note that I recently merged two fixes to the VIPER TCC
> that may be relevant/useful:
> https://gem5-review.googlesource.com/c/public/gem5/+/51368,
> https://gem5-review.googlesource.com/c/public/gem5/+/51367
>
> Finally, Polybench is not officially supported.  If you get them working,
> it would be great if you submit them to gem5-resources (
> resources.gem5.org/) to allow others to also use them!
>
> Thanks,
> Matt
>
> On Sat, Oct 9, 2021 at 9:47 AM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All,
>>
>> I am running gem5 v21.0.0.0, rocm v1.6.x (built from source). The
>> simulations run one host CPU (its pair runs a tiny binary and ends exec
>> quickly) to launch GPU benchmark (hipified Polybench GPU) and one CPU of a
>> separate core-pair(its 2nd core runs a lightweight binary and ends exec
>> quickly) to launch a SPEC-17 CPU benchmark on a 3x3 Mesh network. And I am
>> facing 4 different kinds of errors and am requesting some help regarding
>> them. The GPU benchmarks do "malloc"

[gem5-users] GCN3 - Polybench GPU - SPEC 17 - Errors

[Sampad Mohapatra via gem5-users]

Hi All,

I am running gem5 v21.0.0.0, rocm v1.6.x (built from source). The
simulations run one host CPU (its pair runs a tiny binary and ends exec
quickly) to launch GPU benchmark (hipified Polybench GPU) and one CPU of a
separate core-pair(its 2nd core runs a lightweight binary and ends exec
quickly) to launch a SPEC-17 CPU benchmark on a 3x3 Mesh network. And I am
facing 4 different kinds of errors and am requesting some help regarding
them. The GPU benchmarks do "malloc"s of  size ranging from 2GB - 10GB. The
errors appear on various combination of CPU and GPU benchmarks.

(1) The below error appears and disappears on different simulation runs
"
fdtd2d: ../ROCR-Runtime/src/core/runtime/amd_gpu_agent.cpp:577: virtual
void amd::GpuAgent::InitDma(): Assertion `queues_[QueueBlitOnly] != __null
&& "Queue creation failed"' failed.
"

(2) Similar errors with varying values
"
panic: Possible Deadlock detected. Aborting!
version: 4 request.paddr: 0x190b80c uncoalescedTable: 4 current time:
12393604096000 issue_time: 12393350811000 difference: 253285000
Request Tables:

Listing pending packets from 4 instructions Addr: [0x2379b, line
0x23780] with 0 pending packets
Addr: [0x237ae, line 0x23780] with 64 pending packets
Addr: [0x237b0, line 0x23780] with 56 pending packets
Addr: [0x237b5, line 0x23780] with 61 pending packets
Memory Usage: 57420616 KBytes
"

(3) The below error appears and disappears on different simulation runs:
"
There is no device can be used to do the computation
"

(4) The below error appears and disappears on different simulation runs:
"
fatal: syscall mincore (#27) unimplemented.
"

Thanks and Regards,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Pseudo Instruction - m5_reset_stats() - Body Modification

[Sampad Mohapatra via gem5-users]

Hi All,

I need to set a bool variable in src/cpu/simple/base.(hh|cc) to be true
when m5_reset_stats() is *explicitly *called from some binary executing on
gem5. Using this bool and instruction count, I want to exit the simulation.

How can I modify the body (hack) of m5_reset_stats() to call other
functions ? Where is its body defined ?
If not possible, then is there any alternative way to set the bool variable
when m5_reset_stats() is *explicitly* called ?

Thank You,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Out of Memory while running GPU Benchmark

[Sampad Mohapatra via gem5-users]

Hi Muhammet,

Yes, the gpu benchmark itself mallocs around 3GB.
But then why does the memory usage show 30305260 KBytes ~ 29 GB ?
What does this value indicate ?

Thank you,
Sampad

On Mon, Sep 14, 2020 at 3:30 PM Muhammet Abdullah Soytürk <
muhammetabdullahsoyt...@gmail.com> wrote:

> Hi,
>
> Is there any chance that the input you provide is bigger than 2GB? If the
> input size is bigger than the memory size, you cannot simulate it in SE
> mode (since there is no paging support for SE mode). As you can understand
> from the error message, you need to increase the size of the memory.
>
> Best,
> Muhammet
>
> Sampad Mohapatra via gem5-users , 14 Eyl 2020 Pzt,
> 21:49 tarihinde şunu yazdı:
>
>> Hi All,
>>
>> I am running 2DConvolution (polybench-gpu) and leela (SPEC 17) using the
>> AMD GCN3 model on a research cluster with around 4 TB of memory. But the
>> simulation ended with the following message:
>>
>> fatal: Out of memory, please increase size of physical memory.
>> Memory Usage: 30305260 KBytes
>>
>> I had passed 2GB as mem-size. What could be the problem and how can I
>> mitigate it?
>>
>> Thank you,
>> Sampad Mohapatra
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Out of Memory while running GPU Benchmark

[Sampad Mohapatra via gem5-users]

Hi All,

I am running 2DConvolution (polybench-gpu) and leela (SPEC 17) using the
AMD GCN3 model on a research cluster with around 4 TB of memory. But the
simulation ended with the following message:

fatal: Out of memory, please increase size of physical memory.
Memory Usage: 30305260 KBytes

I had passed 2GB as mem-size. What could be the problem and how can I
mitigate it?

Thank you,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - X86KvmCPU usage - Segfault encountered

[Sampad Mohapatra via gem5-users]

Thanks for the heads up Matt.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Sep 7, 2020 at 1:05 PM Matt Sinclair 
wrote:

> Matt P (CC'd) will likely know better than me, but I don't believe
> KVM/fast-forwarding works with GCN3 yet.
>
> Matt
>
> On Mon, Sep 7, 2020 at 9:36 AM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All,
>>
>> I am using the staging branch GCN3. While using the KvmCPU to fast
>> forward execution till my
>> GPU kernel launches using m5_switch_cpu(), I am encountering a segfault
>> at the following location:
>>
>> src/cpu/kvm/vm.cc:562 : long KvmVM::allocVCPUID() { return nextVCPUID++; }
>>
>> For some reason the memory location for nextVCPUID is inaccessible.
>>
>> Does the fast forwarding functionality work with the GCN3 model ?
>> If yes, then what could be wrong ?
>>
>>
>> Thanks and regards,
>> Sampad Mohapatra
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_-4153070545425854346_m_-8667493547968458291_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] AMD GCN3 - X86KvmCPU usage - Segfault encountered

[Sampad Mohapatra via gem5-users]

Hi All,

I am using the staging branch GCN3. While using the KvmCPU to fast forward
execution till my
GPU kernel launches using m5_switch_cpu(), I am encountering a segfault at
the following location:

src/cpu/kvm/vm.cc:562 : long KvmVM::allocVCPUID() { return nextVCPUID++; }

For some reason the memory location for nextVCPUID is inaccessible.

Does the fast forwarding functionality work with the GCN3 model ?
If yes, then what could be wrong ?


Thanks and regards,
Sampad Mohapatra


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Garnet - Query regarding Faux-Filesystem

[Sampad Mohapatra via gem5-users]

Hi All,

Why was the following piece of code added to Mesh_XY.py and not to
Cluster.py ?

# Register nodes with filesystem
def registerTopology(self, options):
for i in xrange(options.num_cpus):
FileSystemConfig.register_node([i],
MemorySize(options.mem_size) / options.num_cpus, i)

Is this a correct expression: MemorySize(options.mem_size) /
options.num_cpus, where a MemorySize
object is being divided by an Integer ? Also,
FileSystemConfig.register_node() expects a numerical type
argument being passed to the mem parameter, whereas currently a
MemorySize() argument is being
passed. This is resulting in a type error at the following line in
FileSystemConfig.register_node().

file_append((nodedir, 'meminfo'),
 'Node %d MemTotal: %dkB' % (node_number,
 toMemorySize(str(mem))/kibi))

Perhaps MemorySize should be changed to toMemorySize() ?

Thanks and regards,
Sampad Mohapatra


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: SLICC - Help modify MemoryMsg

[Sampad Mohapatra via gem5-users]

To clarify, I have added a bool and setter and getter functions to
message.hh|cc.
And I was able to solve the problem by declaring the following in SLICC.

structure(Message, external="yes") {
  void setFlag(bool);
  bool getFlag();
}


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Sep 1, 2020 at 11:25 AM Sampad Mohapatra  wrote:

> Hi All,
>
> I am trying to add a bool variable to MemoryMsg and set() and get() it in
> SLICC.
> But when I try to build gem5, I get the following errors.
>
> AttributeError: 'NoneType' object has no attribute 'methods':
>   File "/i3c/hpcl/sum94/local/ROCM_SRC/gem5/SConstruct", line 1257:
> SConscript('src/SConscript', variant_dir = variant_path, exports =
> 'env')
>   File "/i3c/hpcl/sum94/local/SCons/lib/scons/SCons/Script/SConscript.py",
> line 614:
> return method(*args, **kw)
> ...
>
> Other messages such as FifoMsg, DMARequestMsg, CPURequestMsg etc. are
> declared in a .sm file
> and I can declare a function (originally part of Message.hh/cc) inside
> these structures in SLICC and
> utilize them in the SLICC actions. But, since MemoryMsg is not declared in
> a .sm file and is
> autogenerated, I am unable to add and access any functions/variables.
>
> Please advise.
>
> Thank You,
> Sampad Mohapatra
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-2456735834608789332_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] SLICC - Help modify MemoryMsg

[Sampad Mohapatra via gem5-users]

Hi All,

I am trying to add a bool variable to MemoryMsg and set() and get() it in
SLICC.
But when I try to build gem5, I get the following errors.

AttributeError: 'NoneType' object has no attribute 'methods':
  File "/i3c/hpcl/sum94/local/ROCM_SRC/gem5/SConstruct", line 1257:
SConscript('src/SConscript', variant_dir = variant_path, exports =
'env')
  File "/i3c/hpcl/sum94/local/SCons/lib/scons/SCons/Script/SConscript.py",
line 614:
return method(*args, **kw)
...

Other messages such as FifoMsg, DMARequestMsg, CPURequestMsg etc. are
declared in a .sm file
and I can declare a function (originally part of Message.hh/cc) inside
these structures in SLICC and
utilize them in the SLICC actions. But, since MemoryMsg is not declared in
a .sm file and is
autogenerated, I am unable to add and access any functions/variables.

Please advise.

Thank You,
Sampad Mohapatra


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - Virtual network type correctness in MOESI_AMD_Base-dir.sm

[Sampad Mohapatra via gem5-users]

Hi Matt,

I have posted the patch.

https://gem5-review.googlesource.com/c/public/gem5/+/33755

Thank You,
Sampad

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Aug 31, 2020 at 1:27 AM Matt Sinclair 
wrote:

> Hi Sampad,
>
> If possible, can you please submit a patch for this?  That way Srikant and
> the others who are experts with Garnet can review and validate.
>
> Thanks,
> Matt
>
> On Sun, Aug 30, 2020 at 10:37 PM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Srikant,
>>
>> It is used to send both data and acks.
>> For now I am changing it to response type till a counter argument is
>> presented.
>>
>> Thanks,
>> Sampad
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_-8575368387529271265_m_-3382899564790013684_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sun, Aug 30, 2020 at 10:37 PM Srikant Bharadwaj via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi Sampad,
>>> The vnet_type 'request' and 'response' in vnet is consumed by Garnet for
>>> setting the message size. In general, if a message has data that will be
>>> transmitted it should be marked as a 'response' type. I am not sure about
>>> the GPU_VIPER protocol, but if both the message buffers in question carry a
>>> data type they should be marked as a 'response' type.
>>>
>>> Thanks,
>>> Srikant
>>>
>>> On Sun, Aug 30, 2020 at 6:49 PM Sampad Mohapatra via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hi All,
>>>>
>>>> The *vnet_type* of the MessageBuffer *responseToDMA* is set as
>>>> *request* and
>>>> the virtual network number is set as 3.
>>>>
>>>> MessageBuffer * responseToDMA, network="To", virtual_network="3",
>>>> vnet_type="request";
>>>>
>>>> But in other slicc files such as *GPU_VIPER_TCC.sm* the vnet_type of
>>>> vn number 3 is set as response.
>>>>
>>>> MessageBuffer * responseToCore, network="To", virtual_network="3",
>>>> vnet_type="response";
>>>>
>>>> Shouldn't the vnet_type of responseToDMA be "response" ?
>>>>
>>>> Thanks and regards,
>>>> Sampad Mohapatra
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>>>  Virus-free.
>>>> www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>>>> <#m_-8575368387529271265_m_-3382899564790013684_m_-8833927310015265666_m_6814462151260302366_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>> ___
>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - Virtual network type correctness in MOESI_AMD_Base-dir.sm

[Sampad Mohapatra via gem5-users]

Hi Matt,

I will post a patch as soon as possible.

Thank you,
Sampad

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Aug 31, 2020 at 1:27 AM Matt Sinclair 
wrote:

> Hi Sampad,
>
> If possible, can you please submit a patch for this?  That way Srikant and
> the others who are experts with Garnet can review and validate.
>
> Thanks,
> Matt
>
> On Sun, Aug 30, 2020 at 10:37 PM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Srikant,
>>
>> It is used to send both data and acks.
>> For now I am changing it to response type till a counter argument is
>> presented.
>>
>> Thanks,
>> Sampad
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_-8575368387529271265_m_-3382899564790013684_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sun, Aug 30, 2020 at 10:37 PM Srikant Bharadwaj via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi Sampad,
>>> The vnet_type 'request' and 'response' in vnet is consumed by Garnet for
>>> setting the message size. In general, if a message has data that will be
>>> transmitted it should be marked as a 'response' type. I am not sure about
>>> the GPU_VIPER protocol, but if both the message buffers in question carry a
>>> data type they should be marked as a 'response' type.
>>>
>>> Thanks,
>>> Srikant
>>>
>>> On Sun, Aug 30, 2020 at 6:49 PM Sampad Mohapatra via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hi All,
>>>>
>>>> The *vnet_type* of the MessageBuffer *responseToDMA* is set as
>>>> *request* and
>>>> the virtual network number is set as 3.
>>>>
>>>> MessageBuffer * responseToDMA, network="To", virtual_network="3",
>>>> vnet_type="request";
>>>>
>>>> But in other slicc files such as *GPU_VIPER_TCC.sm* the vnet_type of
>>>> vn number 3 is set as response.
>>>>
>>>> MessageBuffer * responseToCore, network="To", virtual_network="3",
>>>> vnet_type="response";
>>>>
>>>> Shouldn't the vnet_type of responseToDMA be "response" ?
>>>>
>>>> Thanks and regards,
>>>> Sampad Mohapatra
>>>>
>>>>
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>>>  Virus-free.
>>>> www.avast.com
>>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>>>> <#m_-8575368387529271265_m_-3382899564790013684_m_-8833927310015265666_m_6814462151260302366_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>> ___
>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - Virtual network type correctness in MOESI_AMD_Base-dir.sm

[Sampad Mohapatra via gem5-users]

Hi Srikant,

It is used to send both data and acks.
For now I am changing it to response type till a counter argument is
presented.

Thanks,
Sampad

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Aug 30, 2020 at 10:37 PM Srikant Bharadwaj via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Sampad,
> The vnet_type 'request' and 'response' in vnet is consumed by Garnet for
> setting the message size. In general, if a message has data that will be
> transmitted it should be marked as a 'response' type. I am not sure about
> the GPU_VIPER protocol, but if both the message buffers in question carry a
> data type they should be marked as a 'response' type.
>
> Thanks,
> Srikant
>
> On Sun, Aug 30, 2020 at 6:49 PM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All,
>>
>> The *vnet_type* of the MessageBuffer *responseToDMA* is set as *request*
>> and
>> the virtual network number is set as 3.
>>
>> MessageBuffer * responseToDMA, network="To", virtual_network="3",
>> vnet_type="request";
>>
>> But in other slicc files such as *GPU_VIPER_TCC.sm* the vnet_type of vn
>> number 3 is set as response.
>>
>> MessageBuffer * responseToCore, network="To", virtual_network="3",
>> vnet_type="response";
>>
>> Shouldn't the vnet_type of responseToDMA be "response" ?
>>
>> Thanks and regards,
>> Sampad Mohapatra
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_-8833927310015265666_m_6814462151260302366_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] AMD GCN3 - Virtual network type correctness in MOESI_AMD_Base-dir.sm

[Sampad Mohapatra via gem5-users]

Hi All,

The *vnet_type* of the MessageBuffer *responseToDMA* is set as *request* and
the virtual network number is set as 3.

MessageBuffer * responseToDMA, network="To", virtual_network="3",
vnet_type="request";

But in other slicc files such as *GPU_VIPER_TCC.sm* the vnet_type of vn
number 3 is set as response.

MessageBuffer * responseToCore, network="To", virtual_network="3",
vnet_type="response";

Shouldn't the vnet_type of responseToDMA be "response" ?

Thanks and regards,
Sampad Mohapatra


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] AMD GCN3 - More virtual networks initialized than required

[Sampad Mohapatra via gem5-users]

Hi All,

I am using the staging branch.
The Viper protocol sets the number of VN to be 11.

In GPU_VIPER.py:
ruby_system.network.number_of_virtual_networks = 11

But the actual number of VN used is 5. SQC, TCC (has an unused VN #5), TCP,
Corepair, Dir all use 0,1,2,3 and 4. The generated stats also show that the
VNs are unused. Can I safely ignore the VNs from 5-10 ?

Thanks and regards,
Sampad Mohapatra



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: GCN3 - SLICC - GPU_VIPER-TCC.sm and GPU_TCP-TCP.sm Correctness

[Sampad Mohapatra via gem5-users]

That works for me. I am snooping messages in the Network Interface.
As long as the message size is correct, all is well.

Thanks a lot.


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Aug 25, 2020 at 12:56 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Sampad,
>
> I believe this relates to the fact that the coherence protocol is not
> actually sending out the data, but instead gem5 uses the backing store to
> functionally read/write data.  Essentially, in a real system, yes we would
> need to send the data, which is why the message size accounts for this.
> But in a simulator we don't pass the data along to simplify things (i.e.,
> we don't send the data, but we do account for it).
>
> However, Alex and Brad (CC'd) know a lot more about the state of the
> backing store than I do, so they should comment to confirm.
>
> Matt
>
> On Tue, Aug 25, 2020 at 10:23 AM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hello,
>>
>> In GPU_VIPER-TCC.sm and GPU_TCP-TCP.sm, in action *at_atomicThrough*
>> present in both files,
>> the out message Type is *CoherenceRequestType:Atomic* and the message
>> size is *MessageSizeType:Data*,
>> but there is *no data* being sent. Is this correct behaviour ?
>>
>> Either data is not being sent or the message size should be some other
>> type.
>> Please advise.
>>
>> Thank you,
>> Sampad Mohapatra
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_2631715586352646059_m_7456722988425397407_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] GCN3 - SLICC - GPU_VIPER-TCC.sm and GPU_TCP-TCP.sm Correctness

[Sampad Mohapatra via gem5-users]

Hello,

In GPU_VIPER-TCC.sm and GPU_TCP-TCP.sm, in action *at_atomicThrough*
present in both files,
the out message Type is *CoherenceRequestType:Atomic* and the message size
is *MessageSizeType:Data*,
but there is *no data* being sent. Is this correct behaviour ?

Either data is not being sent or the message size should be some other type.
Please advise.

Thank you,
Sampad Mohapatra


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] How are SLICC in_port and out_port connected ?

[Sampad Mohapatra via gem5-users]

Hello,

I am not clear as to how an out_port (let's say from cache) and an in_port
(to directory)
are connected.

For example in learning gem5 book:

MSI-Cache.sm:
  MessageBuffer * requestToDir, network="To", virtual_network="0",
vnet_type="request";
  out_port(request_out, RequestMsg, requestToDir);

MSI-dir.sm:
  MessageBuffer *requestFromCache, network="From", virtual_network="0",
vnet_type="request";
  in_port(request_in, RequestMsg, requestFromCache)

What all conditions/logic specify that the above two ports should be
connected ?

Thank You,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Missing L1 and L2 Hit stats/actions in MOESI AMD Base - CorePair.sm

[Sampad Mohapatra via gem5-users]

Hey Daniel,

Thanks for the patch. I am using the staging branch.
If you have added any stats to the L3, can you please provide a patch for
that as well ?

Thanks again,
Sampad

On Tue, Aug 18, 2020 at 12:06 PM Daniel Gerzhoy 
wrote:

> Sampad,
>
> I thought the L3 would be inclusive too, but the code reads otherwise, it
> only caches entries on a writeback (always) or writethrough (if enabled).
>
> I am considering changing it to be inclusive for my own purposes (I don't
> know if that is something the community would want or not). Which I guess
> would just entail caching on reads as well as WB/WT.
>
> I've attached the patch. I've run it on the gcn3-staging branch (+some of
> my own changes) but I haven't run it on the develop branch (this patch is
> on top of the develop branch for your convenience).
>
> You will notice some comments about certain hitsProfiling calls for stores
> not being right.
> From what i can tell when the corepair has ownership (M/O/E states) of a
> block, when one of the cores stores to that block even if the block isn't
> in that corepair's L1, it instantaneously puts that cache block into
> Modified state for that core's L1.
> I didn't want to fix the instantaneousness when I was working on this, so
> since performance-wise it's a hit, I just profiled it as such.
> You could split those transitions up for a storeMiss and a storeHit (they
> could be the same save for the profiling action call)
>
> Let me know if this works for you.
>
> Cheers,
>
> Dan
>
> On Tue, Aug 18, 2020 at 11:09 AM Sampad Mohapatra  wrote:
>
>> Hi Daniel,
>>
>> I am just starting out so it would be really helpful if you could kindly
>> provide your patches.
>> Have you verified the changes, otherwise I will try to verify them.
>>
>> Also, isn't the L3 inclusive ?
>>
>> Thank you,
>> Sampad
>>
>> On Tue, Aug 18, 2020 at 9:57 AM Daniel Gerzhoy 
>> wrote:
>>
>>> Hi Sampad,
>>>
>>> I've added corepair profiling to MOESI_AMD_BASE-CorePair.sm if you
>>> haven't already done so. I can create a patch for you (or I'd be happy to
>>> review if you end up submitting one).
>>>
>>> I was confused about the L3Cache in the <...>-dir.sm file as well.
>>> The MOESI_AMD_Base-L3cache.sm file doesn't actually do anything. The L3
>>> Cache file is implemented alongside the directory.
>>> It acts as a victim cache for the L2s.
>>>
>>> I also noticed that the MRU isn't being updated for the L3, so I added
>>> thatexcept it's all commented out in my code right now and I'm not sure
>>> why, so I am going to investigate that.
>>>
>>> Cheers,
>>>
>>> Dan Gerzhoy
>>>
>>> On Tue, Aug 18, 2020 at 12:04 AM Matt Sinclair via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hi Sampad,
>>>>
>>>> The AMD folks that are CC'd are better people to comment than me, but I
>>>> believe the L3 cache is a "memory side" cache, and thus doesn't need to
>>>> maintain coherence.
>>>>
>>>> If you have a fix to add hits/misses for any of these files, and are
>>>> willing to contribute it back, it would be great if you could submit a
>>>> patch for it.
>>>>
>>>> Matt
>>>>
>>>> On Mon, Aug 17, 2020 at 11:00 PM Sampad Mohapatra 
>>>> wrote:
>>>>
>>>>> Hi Matt,
>>>>>
>>>>> I am currently trying to add the stats by myself. I also noticed that
>>>>> neither hit nor miss stats are updated for L3 Cache.
>>>>>
>>>>> But, I am facing a different issue now. The directory ctrl (DirCntrl)
>>>>> in GPU_VIPER.py has a L3 cache (L3Cache).
>>>>> But, there is also a separate L3Cntrl class which inherits from
>>>>> L3Cache_Controller, but it is unused.
>>>>> The L3Cache_Controller is generated from MOESI_AMD_Base-L3cache.sm,
>>>>> which is a part of the Viper protocol.
>>>>>
>>>>> If the L3Cache_Controller isn't used, then why is it a part of the
>>>>> Viper protocol ?
>>>>> Does the L3 Cache not maintain any coherency ?
>>>>> Is this the intended behaviour of the default configuration ?
>>>>>
>>>>> Thanks and Regards,
>>>>> Sampad
>>>>>
>>>>> On Thu, Aug 13, 2020 at 5:40 PM Matt Sinclair via gem5-users <
>>>>> gem5-users@gem5.org> wrote:
>>>>>
&

[gem5-users] Re: Missing L1 and L2 Hit stats/actions in MOESI AMD Base - CorePair.sm

[Sampad Mohapatra via gem5-users]

Hi Daniel,

I am just starting out so it would be really helpful if you could kindly
provide your patches.
Have you verified the changes, otherwise I will try to verify them.

Also, isn't the L3 inclusive ?

Thank you,
Sampad

On Tue, Aug 18, 2020 at 9:57 AM Daniel Gerzhoy 
wrote:

> Hi Sampad,
>
> I've added corepair profiling to MOESI_AMD_BASE-CorePair.sm if you haven't
> already done so. I can create a patch for you (or I'd be happy to review if
> you end up submitting one).
>
> I was confused about the L3Cache in the <...>-dir.sm file as well.
> The MOESI_AMD_Base-L3cache.sm file doesn't actually do anything. The L3
> Cache file is implemented alongside the directory.
> It acts as a victim cache for the L2s.
>
> I also noticed that the MRU isn't being updated for the L3, so I added
> thatexcept it's all commented out in my code right now and I'm not sure
> why, so I am going to investigate that.
>
> Cheers,
>
> Dan Gerzhoy
>
> On Tue, Aug 18, 2020 at 12:04 AM Matt Sinclair via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi Sampad,
>>
>> The AMD folks that are CC'd are better people to comment than me, but I
>> believe the L3 cache is a "memory side" cache, and thus doesn't need to
>> maintain coherence.
>>
>> If you have a fix to add hits/misses for any of these files, and are
>> willing to contribute it back, it would be great if you could submit a
>> patch for it.
>>
>> Matt
>>
>> On Mon, Aug 17, 2020 at 11:00 PM Sampad Mohapatra  wrote:
>>
>>> Hi Matt,
>>>
>>> I am currently trying to add the stats by myself. I also noticed that
>>> neither hit nor miss stats are updated for L3 Cache.
>>>
>>> But, I am facing a different issue now. The directory ctrl (DirCntrl) in
>>> GPU_VIPER.py has a L3 cache (L3Cache).
>>> But, there is also a separate L3Cntrl class which inherits from
>>> L3Cache_Controller, but it is unused.
>>> The L3Cache_Controller is generated from MOESI_AMD_Base-L3cache.sm,
>>> which is a part of the Viper protocol.
>>>
>>> If the L3Cache_Controller isn't used, then why is it a part of the Viper
>>> protocol ?
>>> Does the L3 Cache not maintain any coherency ?
>>> Is this the intended behaviour of the default configuration ?
>>>
>>> Thanks and Regards,
>>> Sampad
>>>
>>> On Thu, Aug 13, 2020 at 5:40 PM Matt Sinclair via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hi Sampad,
>>>>
>>>> I'm not aware of a patch for this.  There was recently a patch to add
>>>> similar support for the VIPER protocol:
>>>> https://gem5-review.googlesource.com/c/public/gem5/+/30174.  If the
>>>> AMD folks (CC'd) don't have a patch, then the next best thing would be to
>>>> do something similar to the VIPER patch (although yes, the Core Pair
>>>> changes would be a little more complicated).
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>>> On Tue, Aug 4, 2020 at 4:53 PM Sampad Mohapatra via gem5-users <
>>>> gem5-users@gem5.org> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> MOESI AMD Base - CorePair state machine is missing the actions for L1
>>>>> and L2 hit statistics.
>>>>> The stats are present, but since no "action" is created nor used
>>>>> (actions to update misses are present for both L1 and L2), the stats stay
>>>>> at 0.
>>>>>
>>>>> I am not clear as to which state transitions should
>>>>> update the hit stats. Is there a patch for this ?
>>>>>
>>>>> Thank You,
>>>>> Sampad Mohapatra
>>>>>
>>>>>
>>>>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>>>  Virus-free.
>>>>> www.avg.com
>>>>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>>> <#m_-1553455650359693535_m_5415016674414042555_m_-7676868930208282950_m_-8358212102347321869_m_-6648754351699623829_m_1723920294658796898_m_-8550086026140872479_m_-203124547492808951_m_-2486225155787835700_m_2217726199504402898_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>> ___
>>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>
>>>> ___
>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Missing L1 and L2 Hit stats/actions in MOESI AMD Base - CorePair.sm

[Sampad Mohapatra via gem5-users]

Hi Matt,

I am currently trying to add the stats by myself. I also noticed that
neither hit nor miss stats are updated for L3 Cache.

But, I am facing a different issue now. The directory ctrl (DirCntrl) in
GPU_VIPER.py has a L3 cache (L3Cache).
But, there is also a separate L3Cntrl class which inherits from
L3Cache_Controller, but it is unused.
The L3Cache_Controller is generated from MOESI_AMD_Base-L3cache.sm, which
is a part of the Viper protocol.

If the L3Cache_Controller isn't used, then why is it a part of the Viper
protocol ?
Does the L3 Cache not maintain any coherency ?
Is this the intended behaviour of the default configuration ?

Thanks and Regards,
Sampad

On Thu, Aug 13, 2020 at 5:40 PM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Sampad,
>
> I'm not aware of a patch for this.  There was recently a patch to add
> similar support for the VIPER protocol:
> https://gem5-review.googlesource.com/c/public/gem5/+/30174.  If the AMD
> folks (CC'd) don't have a patch, then the next best thing would be to do
> something similar to the VIPER patch (although yes, the Core Pair changes
> would be a little more complicated).
>
> Thanks,
> Matt
>
> On Tue, Aug 4, 2020 at 4:53 PM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hello All,
>>
>> MOESI AMD Base - CorePair state machine is missing the actions for L1 and
>> L2 hit statistics.
>> The stats are present, but since no "action" is created nor used (actions
>> to update misses are present for both L1 and L2), the stats stay at 0.
>>
>> I am not clear as to which state transitions should
>> update the hit stats. Is there a patch for this ?
>>
>> Thank You,
>> Sampad Mohapatra
>>
>>
>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>  Virus-free.
>> www.avg.com
>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>> <#m_-6648754351699623829_m_1723920294658796898_m_-8550086026140872479_m_-203124547492808951_m_-2486225155787835700_m_2217726199504402898_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - Can't use single CPU - fatal no spare thread context

[Sampad Mohapatra via gem5-users]

Thanks Matt. Thats a lot of helpful information.
I will investigate further.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Aug 8, 2020 at 2:06 AM Matt Sinclair 
wrote:

> I don't know the answer to this, and would need to look just the same as
> you.
>
> My guess is that a) the thread contexts do not necessarily require running
> on different CPUs and b) after the check I described, the one thread won't
> be doing anything more after that point, so its effect on subsequent
> coherence, memory traffic, etc. would be 0.  In the experiments I was
> running at the time, I believe I was only using a single CPU and a single
> GPU, and was able to run multiple thread contexts, so I don't think
> multiple CPUs is a problem.  You could probably even use the m5stats to
> reset stats after this startup stuff is done, since I think the check that
> requires the additional thread context happens at the very beginning when
> ROCm is initialized.
>
> These are all guesses though, and if you wanted absolute answers, you'd
> have to use gdb as I explained previously.
>
> Matt
>
> On Sat, Aug 8, 2020 at 12:47 AM Sampad Mohapatra  wrote:
>
>> Hi Matt,
>>
>> Thanks for the clarification.
>>
>> My issue is I need more than 1 cpu. In this scenario what will be the
>> effect of this extra cpu
>> on the coherence traffic, i.e. does it become part of a Core Pair and
>> take part in coherence exchanges ?
>> When I am placing cpus in a garnet topology, how do I ignore this
>> particular cpu ?
>>
>> Regards,
>> Sampad
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_5953135400297621280_m_8951653715473613158_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sat, Aug 8, 2020 at 1:08 AM Matt Sinclair via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi Sampad,
>>>
>>> To literally answer the clone error part: this happens when your
>>> application needs multiple thread contexts to run.  The failure happens
>>> when -n 1 is used because the simulator doesn't have enough thread contexts
>>> to fulfill what the application needs.
>>>
>>> Of course, the next logical question is why ROCm needs 2 thread
>>> contexts.  I haven't looked at this specific behavior in several years, but
>>> when I dug into this in ~2018, I remember this happening because the ROCm
>>> stack was spawning a thread to check on some details about the system
>>> (e.g., it was checking if the HCC version was at least version X, because
>>> starting with that version, the HCC behavior was different).  If you are
>>> interested in finding the exact call that does this, you can build a debug
>>> version of the ROCm stack and step through the ROCm stack with gdb while
>>> the simulator is running.  Eventually you'll get to the instruction in the
>>> ROCm stack that is doing checks like the one I described above, and you
>>> could potentially remove that call and return true/false instead as
>>> appropriate for the check it's doing.  This is what I did previously,
>>> although I don't think that ROCm patch has been merged into develop or the
>>> AMD staging branch yet (although like some of the other ROCm patches, it
>>> would actually need to be placed elsewhere like gem5-resources, not
>>> directly in the gem5 repo, since it doesn't affect gem5 code).
>>>
>>> Alternatively, you can just run with -n 2, as you've found already.  It
>>> should have very minimal impact on running the application.
>>>
>>> Matt
>>>
>>> On Fri, Aug 7, 2020 at 11:46 PM Sampad Mohapatra via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Why does the GCN3 model require at least 2 CPUs ?
>>>> Every time I use a single CPU, gem5 crashes with the following error:
>>>> *fatal: clone: no spare thread context in system*
>>>>
>>>> In contrast, I was able to run the HSAIL model with a single CPU.
>>>>
>>>> Thank You,
>>>> Sampad Mohapatra
>>>>
>>>>
&

[gem5-users] Re: AMD GCN3 - Can't use single CPU - fatal no spare thread context

[Sampad Mohapatra via gem5-users]

Hi Matt,

Thanks for the clarification.

My issue is I need more than 1 cpu. In this scenario what will be the
effect of this extra cpu
on the coherence traffic, i.e. does it become part of a Core Pair and take
part in coherence exchanges ?
When I am placing cpus in a garnet topology, how do I ignore this
particular cpu ?

Regards,
Sampad

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Aug 8, 2020 at 1:08 AM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Sampad,
>
> To literally answer the clone error part: this happens when your
> application needs multiple thread contexts to run.  The failure happens
> when -n 1 is used because the simulator doesn't have enough thread contexts
> to fulfill what the application needs.
>
> Of course, the next logical question is why ROCm needs 2 thread contexts.
> I haven't looked at this specific behavior in several years, but when I dug
> into this in ~2018, I remember this happening because the ROCm stack was
> spawning a thread to check on some details about the system (e.g., it was
> checking if the HCC version was at least version X, because starting with
> that version, the HCC behavior was different).  If you are interested in
> finding the exact call that does this, you can build a debug version of the
> ROCm stack and step through the ROCm stack with gdb while the simulator is
> running.  Eventually you'll get to the instruction in the ROCm stack that
> is doing checks like the one I described above, and you could potentially
> remove that call and return true/false instead as appropriate for the check
> it's doing.  This is what I did previously, although I don't think that
> ROCm patch has been merged into develop or the AMD staging branch yet
> (although like some of the other ROCm patches, it would actually need to be
> placed elsewhere like gem5-resources, not directly in the gem5 repo, since
> it doesn't affect gem5 code).
>
> Alternatively, you can just run with -n 2, as you've found already.  It
> should have very minimal impact on running the application.
>
> Matt
>
> On Fri, Aug 7, 2020 at 11:46 PM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All,
>>
>> Why does the GCN3 model require at least 2 CPUs ?
>> Every time I use a single CPU, gem5 crashes with the following error:
>> *fatal: clone: no spare thread context in system*
>>
>> In contrast, I was able to run the HSAIL model with a single CPU.
>>
>> Thank You,
>> Sampad Mohapatra
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_-8468723184678421553_m_4482362651241885149_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] AMD GCN3 - Can't use single CPU - fatal no spare thread context

[Sampad Mohapatra via gem5-users]

Hi All,

Why does the GCN3 model require at least 2 CPUs ?
Every time I use a single CPU, gem5 crashes with the following error:
*fatal: clone: no spare thread context in system*

In contrast, I was able to run the HSAIL model with a single CPU.

Thank You,
Sampad Mohapatra


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Missing L1 and L2 Hit stats/actions in MOESI AMD Base - CorePair.sm

[Sampad Mohapatra via gem5-users]

Hello All,

MOESI AMD Base - CorePair state machine is missing the actions for L1 and
L2 hit statistics.
The stats are present, but since no "action" is created nor used (actions
to update misses are present for both L1 and L2), the stats stay at 0.

I am not clear as to which state transitions should
update the hit stats. Is there a patch for this ?

Thank You,
Sampad Mohapatra


Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] AMD GCN3 - HSA Memory Mapping

[Sampad Mohapatra via gem5-users]

Hi All,

I have two queries related to apu_se.py.

(1)
In both AMD staging and public/develop, apu_se.py has two unused variables:

  hsapp_gpu_map_vaddr = 0x2
  hsapp_gpu_map_size = 0x1000

Are they unnecessary or should they actually be used somewhere ?

(2)
The following is passed as pioAddr to the HSAPacketProcessor.
  hsapp_gpu_map_paddr = int(Addr(options.mem_size))

And then the following assignment is done.
  # Map workload to this address space
  host_cpu.workload[0].map(0x1000, 0x2, 4096)

Should the physical address to the workload map be the same as pioAddr of
HSAPacketProcessor, i.e. greater than physical memory size and should the
virtual address of the workload map remain 0x1000 ?

As a whole, are the above mentioned variables related ? If yes, then how ?
Are some of them accidentally hardcoded and should actually be variables?
Please give me some advice.

Thank you,
Sampad
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - HIP Compile m5_exit() issue

[Sampad Mohapatra via gem5-users]

Sorry for the confusion. Compiling with gcc works. I am able to use
m5_exit() after following the steps in my last reply.

Though I will also test your given steps.

Thank you Daniel.

On Sat, Aug 1, 2020, 3:51 PM Daniel Gerzhoy 
wrote:

> What errors are you getting?
>
> I would separate that out further though.
>
> Steps 1-3: Compile Each one separately
> g++ -O2 -I/sam/gem5/util/m5/../../include -o m5op_x86.o -c m5op_x86.S
> g++ -O2 -I/sam/gem5/util/m5/../../include -o m5_mmap.o -c m5_mmap.c
> hipcc -g -O2 -I/sam/gem5/include -o 2DConvolution.o  2DConvolution.cpp
>
> #Step 4: Use hipcc to link
> hipcc -g -O2  -o 2DConvolution.exe m5op_x86.o m5_mmap.o 2DConvolution.o
> --amdgpu-target=gfx801
>
> On Sat, Aug 1, 2020 at 3:39 PM Sampad Mohapatra  wrote:
>
>> Hi Daniel,
>>
>> Actually compiling m5op_x86.o and m5_mmap.o fails with hipcc.
>> Gcc works fine. Here's my steps.
>>
>> *Compilation Steps:*
>> g++ -O2 -I/sam/gem5/util/m5/../../include -o m5op_x86.o -c m5op_x86.S
>> g++ -O2 -I/sam/gem5/util/m5/../../include -o m5_mmap.o -c m5_mmap.c
>>
>> /opt/rocm/hip/bin/hipcc --amdgpu-target=gfx801 -g -O2 2DConvolution.cpp
>> -I/sam/gem5/include /sam/gem5/util/m5/m5op_x86.o
>> /sam/gem5/util/m5/m5_mmap.o -o 2DConvolution.exe
>>
>> Thanks,
>> Sampad
>>
>> On Sat, Aug 1, 2020 at 3:17 PM Daniel Gerzhoy 
>> wrote:
>>
>>> Sorry, using hipcc* to link them together.
>>>
>>> On Sat, Aug 1, 2020 at 2:15 PM Daniel Gerzhoy 
>>> wrote:
>>>
>>>> I would suggest compiling M5op with gcc or g++ with a -c flag and then
>>>> using M5op to link them together.
>>>>
>>>> On Sat, Aug 1, 2020 at 2:13 PM Sampad Mohapatra via gem5-users <
>>>> gem5-users@gem5.org> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> While trying to compile polybench benchmarks with m5_exit(0) using the
>>>>> HIP compiler ()
>>>>> I am getting a lot of errors (m5ops.h was included).
>>>>> Please give me some advice.
>>>>>
>>>>> *Compile Command:*
>>>>>
>>>>> /opt/rocm/hip/bin/hipcc --amdgpu-target=gfx801 -g -O2
>>>>> 2DConvolution.cpp -I/sam/gem5/include /sam/gem5/util/m5/m5op_x86.S -o
>>>>> 2DConvolution.exe
>>>>>
>>>>> *Error:*
>>>>>
>>>>> /sam/gem5/util/m5/m5op_x86.S:78:16: error: unknown directive
>>>>> .globl m5_arm; .func m5_arm; m5_arm: .byte 0x0F, 0x04; .word 0x00;
>>>>> ret; .endfunc;
>>>>>^
>>>>> /sam/gem5/util/m5/m5op_x86.S:78:73: error: unknown directive
>>>>> .globl m5_arm; .func m5_arm; m5_arm: .byte 0x0F, 0x04; .word 0x00;
>>>>> ret; .endfunc;
>>>>>
>>>>>   ^
>>>>> /sam/gem5/util/m5/m5op_x86.S:79:20: error: unknown directive
>>>>> .globl m5_quiesce; .func m5_quiesce; m5_quiesce: .byte 0x0F, 0x04;
>>>>> .word 0x01; ret; .endfunc;
>>>>>^
>>>>> /sam/gem5/util/m5/m5op_x86.S:79:85: error: unknown directive
>>>>> .globl m5_quiesce; .func m5_quiesce; m5_quiesce: .byte 0x0F, 0x04;
>>>>> .word 0x01; ret; .endfunc;
>>>>>
>>>>> ...
>>>>>
>>>>> Thank You,
>>>>> Sampad Mohapatra
>>>>>   ^
>>>>> ___
>>>>> gem5-users mailing list -- gem5-users@gem5.org
>>>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>
>>>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - HIP Compile m5_exit() issue

[Sampad Mohapatra via gem5-users]

Hi Daniel,

Actually compiling m5op_x86.o and m5_mmap.o fails with hipcc.
Gcc works fine. Here's my steps.

*Compilation Steps:*
g++ -O2 -I/sam/gem5/util/m5/../../include -o m5op_x86.o -c m5op_x86.S
g++ -O2 -I/sam/gem5/util/m5/../../include -o m5_mmap.o -c m5_mmap.c

/opt/rocm/hip/bin/hipcc --amdgpu-target=gfx801 -g -O2 2DConvolution.cpp
-I/sam/gem5/include /sam/gem5/util/m5/m5op_x86.o
/sam/gem5/util/m5/m5_mmap.o -o 2DConvolution.exe

Thanks,
Sampad

On Sat, Aug 1, 2020 at 3:17 PM Daniel Gerzhoy 
wrote:

> Sorry, using hipcc* to link them together.
>
> On Sat, Aug 1, 2020 at 2:15 PM Daniel Gerzhoy 
> wrote:
>
>> I would suggest compiling M5op with gcc or g++ with a -c flag and then
>> using M5op to link them together.
>>
>> On Sat, Aug 1, 2020 at 2:13 PM Sampad Mohapatra via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hello,
>>>
>>> While trying to compile polybench benchmarks with m5_exit(0) using the
>>> HIP compiler ()
>>> I am getting a lot of errors (m5ops.h was included).
>>> Please give me some advice.
>>>
>>> *Compile Command:*
>>>
>>> /opt/rocm/hip/bin/hipcc --amdgpu-target=gfx801 -g -O2 2DConvolution.cpp
>>> -I/sam/gem5/include /sam/gem5/util/m5/m5op_x86.S -o 2DConvolution.exe
>>>
>>> *Error:*
>>>
>>> /sam/gem5/util/m5/m5op_x86.S:78:16: error: unknown directive
>>> .globl m5_arm; .func m5_arm; m5_arm: .byte 0x0F, 0x04; .word 0x00; ret;
>>> .endfunc;
>>>^
>>> /sam/gem5/util/m5/m5op_x86.S:78:73: error: unknown directive
>>> .globl m5_arm; .func m5_arm; m5_arm: .byte 0x0F, 0x04; .word 0x00; ret;
>>> .endfunc;
>>> ^
>>> /sam/gem5/util/m5/m5op_x86.S:79:20: error: unknown directive
>>> .globl m5_quiesce; .func m5_quiesce; m5_quiesce: .byte 0x0F, 0x04; .word
>>> 0x01; ret; .endfunc;
>>>^
>>> /sam/gem5/util/m5/m5op_x86.S:79:85: error: unknown directive
>>> .globl m5_quiesce; .func m5_quiesce; m5_quiesce: .byte 0x0F, 0x04; .word
>>> 0x01; ret; .endfunc;
>>>
>>> ...
>>>
>>> Thank You,
>>> Sampad Mohapatra
>>> ^
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] AMD GCN3 - HIP Compile m5_exit() issue

[Sampad Mohapatra via gem5-users]

Hello,

While trying to compile polybench benchmarks with m5_exit(0) using the HIP
compiler ()
I am getting a lot of errors (m5ops.h was included).
Please give me some advice.

*Compile Command:*

/opt/rocm/hip/bin/hipcc --amdgpu-target=gfx801 -g -O2 2DConvolution.cpp
-I/sam/gem5/include /sam/gem5/util/m5/m5op_x86.S -o 2DConvolution.exe

*Error:*

/sam/gem5/util/m5/m5op_x86.S:78:16: error: unknown directive
.globl m5_arm; .func m5_arm; m5_arm: .byte 0x0F, 0x04; .word 0x00; ret;
.endfunc;
   ^
/sam/gem5/util/m5/m5op_x86.S:78:73: error: unknown directive
.globl m5_arm; .func m5_arm; m5_arm: .byte 0x0F, 0x04; .word 0x00; ret;
.endfunc;
^
/sam/gem5/util/m5/m5op_x86.S:79:20: error: unknown directive
.globl m5_quiesce; .func m5_quiesce; m5_quiesce: .byte 0x0F, 0x04; .word
0x01; ret; .endfunc;
   ^
/sam/gem5/util/m5/m5op_x86.S:79:85: error: unknown directive
.globl m5_quiesce; .func m5_quiesce; m5_quiesce: .byte 0x0F, 0x04; .word
0x01; ret; .endfunc;

...

Thank You,
Sampad Mohapatra
^
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: AMD GCN3 - Garnet Support

[Sampad Mohapatra via gem5-users]

Thanks Matt and Srikant.

On Wed, Jul 29, 2020, 3:08 AM Matt Sinclair via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Sampad,
>
> Srikant is the expert on Garnet, but his post to gem5-users is not
> working, so I'm forwarding his reply.
>
> Hope this helps,
> Matt
>
> --
>
> GCN3 APU model supports Garnet topologies. You will have to enable garnet
> using --network=garnet2.0 and use an appropriate topology file using the
> --topology option.
> The hsaTopology creates the required files for ROCm driver and is not
> related to the network topology specified for garnet in gem5.
>
> Thanks,
> Srikant
>
> On Tue, Jul 28, 2020 at 7:47 PM Sampad Mohapatra via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi All,
>>
>> Does the GCN3 APU model support garnet network and topologies ?
>> Also, what is the hsaTopology ? Are garnet topologies and hsaTopology
>> related in some way ?
>>
>> Thank you,
>> Sampad Mohapatra
>>
>>
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] AMD GCN3 - Garnet Support

[Sampad Mohapatra via gem5-users]

Hi All,

Does the GCN3 APU model support garnet network and topologies ?
Also, what is the hsaTopology ? Are garnet topologies and hsaTopology
related in some way ?

Thank you,
Sampad Mohapatra
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s