[gem5-users] Re: When gem5 is debugged, how to judge the current position of data?

[Daniel Gerzhoy via gem5-users]

Hey,

I've tried my hand at this problem before and it can be a bit tricky but
with patience and some python scripts you can get what you want.

First, depending on what memory address you are interested in, you will
probably need to extract the physical address. Or if you can just pick an
address from a DPRINTF trace.
I needed a specific address from the program I was running so I created a
magic instruction like m5_exit() etc `uint64_t  m5_paddr(uint64_t vaddr)`
that passes in a virtual address to the simulator
and returns the physical address (if that vaddr is not yet mapped, this
will map it, so that might change behavior, be careful).

Then use whatever trace flags you are interested in. I wanted to trace the
address through the cache coherence system so I used RubySlicc and/or
ProtocolTrace. This will generate
HUGE traces, so make sure you set the debug-start and debug-end flags for
the region you are interested in.

>From here the trace is usually still too large, so I run it through a
python script to filter out the addresses I am interested in.

Good luck!

Dan

On Fri, Nov 13, 2020 at 8:47 AM Hoa Nguyen via gem5-users <
gem5-users@gem5.org> wrote:

> Hi,
>
> I assume that you want to keep track of a piece of data at a specific
> virtual/physical address. I don't know a definite answer to this, but
> one thing you can do is to use the gem5 logging system (i.e. DPRINTF
> and the like) and figure out what flags you should enable to keep
> track of transactions in the memory hierarchy. Also, I believe
> `Packet` objects are the ones that handle data transferring.
>
> Regards,
> Hoa Nguyen
>
> On 11/12/20, yujiecui--- via gem5-users  wrote:
> > In the process of step-by-step debugging of gem5, how can I know whether
> a
> > data currently exists in cache or in memory, and what level of cache it
> is?
> > I think gem5 should provide such a method?
> > Thanks for answer.
> > ___
> > 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: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

t;>>>>> Jira?
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy <
>>>>>>> daniel.gerz...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Let me further say that I know that the magic instructions are
>>>>>>>> being called. I am just getting bogus return values.
>>>>>>>>
>>>>>>>> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy <
>>>>>>>> daniel.gerz...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Matt,
>>>>>>>>>
>>>>>>>>> Thanks for this, it's very helpful. However after following the
>>>>>>>>> instructions (I had to extrapolate a little because of the directory
>>>>>>>>> structure changes you mentioned) I get the same result: Nill returns 
>>>>>>>>> from
>>>>>>>>> the magic instructions.
>>>>>>>>> Actually It isn't nill, but a constant no matter what. If I
>>>>>>>>> compile my program with -O0 its nill, if with -O2 its: 4198192, which 
>>>>>>>>> is
>>>>>>>>> suspicious.
>>>>>>>>>
>>>>>>>>> To clarify, are these updated instructions specifically meant to
>>>>>>>>> fix this issue I am running into? Or just general instructions to 
>>>>>>>>> build
>>>>>>>>> m5op.o
>>>>>>>>>
>>>>>>>>> Here are the specific changes I made according to the link you
>>>>>>>>> provided, the supplemental instructions, and extrapolating based on 
>>>>>>>>> the
>>>>>>>>> directory structure change.
>>>>>>>>>
>>>>>>>>> 1. In SConsopts I commented both:
>>>>>>>>>
>>>>>>>>> --- a/util/m5/src/abi/x86/SConsopts
>>>>>>>>> +++ b/util/m5/src/abi/x86/SConsopts
>>>>>>>>> @@ -27,8 +27,8 @@ Import('*')
>>>>>>>>>
>>>>>>>>>  env['ABI'] = 'x86'
>>>>>>>>>  get_abi_opt('CROSS_COMPILE', '')
>>>>>>>>> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>>>>>>>> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>>>>>>>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>>>>>>>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>>>>>>>>
>>>>>>>>>  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>>>>>>>>>  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>>>>>>>>>
>>>>>>>>> 2. In SConstruct I added:
>>>>>>>>>
>>>>>>>>> --- a/util/m5/SConstruct
>>>>>>>>> +++ b/util/m5/SConstruct
>>>>>>>>> @@ -44,7 +44,9 @@ def abspath(d):
>>>>>>>>>
>>>>>>>>>  # Universal settings.
>>>>>>>>>  main.Append(CXXFLAGS=[ '-O2' ])
>>>>>>>>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>>>>>>>>>  main.Append(CCFLAGS=[ '-O2' ])
>>>>>>>>>  main.Append(CPPPATH=[ common_include ])
>>>>>>>>>
>>>>>>>>> The compilation process compiles m5op.S with gcc though, so c++11
>>>>>>>>> doesn't have any effect on it. Not sure if that matters.
>>>>>>>>>
>>>>>>>>> 3. Finally I linked both m5_mmap.o and m5op.o as per the
>>>>>>>>> instructions but I am a little wary of m5_mmap
>>>>>>>>>
>>>>>>>>> What does m5_mmap actually do if I don't have M5OP_ADDR defined.
>>>>>>>>> It looks like nothing? Do I need to link it?
>>>>>>>>>
>>>>>>>>> *Is there something inside the program I need to do before calling
>>>>>>>>> magic instructions that has to do with m5_mmap?*
>>>>>>>>>
>>>>>>>>> Thanks for your help,
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair <
>>>>>>>>> mattdsincl...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Dan,
>>>>>>>>>>
>>>>>>>>>> In recent weeks, Gabe (if I recall correctly) updated how the
>>>>>>>>>> m5ops are created.  I had created a homework assignment for my 
>>>>>>>>>> course about
>>>>>>>>>> it:
>>>>>>>>>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>>>>>>>>>> (see #2), but this is now already out of date as the location of 
>>>>>>>>>> some files
>>>>>>>>>> changed.  The updated instructions are:
>>>>>>>>>>
>>>>>>>>>> 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between
>>>>>>>>>> the current lines 46 and 47:
>>>>>>>>>>
>>>>>>>>>> main.Append(CXXFLAGS=[ '-O2' ])
>>>>>>>>>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>>>>>>>>>
>>>>>>>>>> main.Append(CCFLAGS=[ '-O2' ])
>>>>>>>>>>
>>>>>>>>>> 2.  Now run the same command you ran in step 2 of the above link:
>>>>>>>>>>
>>>>>>>>>> scons build/x86/out/m5
>>>>>>>>>>
>>>>>>>>>> 3.  This will create the same two .o files in step 2 of the above
>>>>>>>>>> link, in the same places (although the location of m5op.o may
>>>>>>>>>> have changed to include/gem5 util/m5/build/x86/abi/x86/
>>>>>>>>>> according to some of the students in my course).
>>>>>>>>>> Matt
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>>>>>>>>>> gem5-users@gem5.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey all,
>>>>>>>>>>>
>>>>>>>>>>> I've recently updated to using the dev branch for my GCN3
>>>>>>>>>>> simulations. I've noticed that I am now getting return values of 0 
>>>>>>>>>>> for
>>>>>>>>>>> every magic instruction (m5_rpns for instance).
>>>>>>>>>>>
>>>>>>>>>>> Is there a special way I need to be compiling/linking m5ops.S to
>>>>>>>>>>> get the return values to show up correctly? Or might this be a bug?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>> ___
>>>>>>>>>>> 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 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: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

>>> I found the issue and fixed it.
>>>>>
>>>>> The return value wasn't being put into the Rax register in
>>>>> src/arch/x86/isa/decoder/two_byte_opcodes.isa
>>>>>
>>>>> 0x4: BasicOperate::gem5Op({{
>>>>> uint64_t ret;
>>>>> bool recognized =
>>>>> PseudoInst::pseudoInst(
>>>>> xc->tcBase(), IMMEDIATE, ret);
>>>>> if (!recognized)
>>>>> fault = std::make_shared();
>>>>> Rax = ret;
>>>>>
>>>>> //<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>> }}, IsNonSpeculative);
>>>>>
>>>>>   This code was simplified with the new abi stuff and the Rax = ret;
>>>>> must have been lost in the shuffle.
>>>>>
>>>>> I could push the fix to develop, or should I just make an issue on
>>>>> Jira?
>>>>>
>>>>> Best,
>>>>>
>>>>> Dan
>>>>>
>>>>> On Mon, Nov 9, 2020 at 2:50 PM Daniel Gerzhoy <
>>>>> daniel.gerz...@gmail.com> wrote:
>>>>>
>>>>>> Let me further say that I know that the magic instructions are being
>>>>>> called. I am just getting bogus return values.
>>>>>>
>>>>>> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy <
>>>>>> daniel.gerz...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Matt,
>>>>>>>
>>>>>>> Thanks for this, it's very helpful. However after following the
>>>>>>> instructions (I had to extrapolate a little because of the directory
>>>>>>> structure changes you mentioned) I get the same result: Nill returns 
>>>>>>> from
>>>>>>> the magic instructions.
>>>>>>> Actually It isn't nill, but a constant no matter what. If I compile
>>>>>>> my program with -O0 its nill, if with -O2 its: 4198192, which is 
>>>>>>> suspicious.
>>>>>>>
>>>>>>> To clarify, are these updated instructions specifically meant to fix
>>>>>>> this issue I am running into? Or just general instructions to build 
>>>>>>> m5op.o
>>>>>>>
>>>>>>> Here are the specific changes I made according to the link you
>>>>>>> provided, the supplemental instructions, and extrapolating based on the
>>>>>>> directory structure change.
>>>>>>>
>>>>>>> 1. In SConsopts I commented both:
>>>>>>>
>>>>>>> --- a/util/m5/src/abi/x86/SConsopts
>>>>>>> +++ b/util/m5/src/abi/x86/SConsopts
>>>>>>> @@ -27,8 +27,8 @@ Import('*')
>>>>>>>
>>>>>>>  env['ABI'] = 'x86'
>>>>>>>  get_abi_opt('CROSS_COMPILE', '')
>>>>>>> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>>>>>> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>>>>>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>>>>>>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>>>>>>
>>>>>>>  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>>>>>>>  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>>>>>>>
>>>>>>> 2. In SConstruct I added:
>>>>>>>
>>>>>>> --- a/util/m5/SConstruct
>>>>>>> +++ b/util/m5/SConstruct
>>>>>>> @@ -44,7 +44,9 @@ def abspath(d):
>>>>>>>
>>>>>>>  # Universal settings.
>>>>>>>  main.Append(CXXFLAGS=[ '-O2' ])
>>>>>>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>>>>>>>  main.Append(CCFLAGS=[ '-O2' ])
>>>>>>>  main.Append(CPPPATH=[ common_include ])
>>>>>>>
>>>>>>> The compilation process compiles m5op.S with gcc though, so c++11
>>>>>>> doesn't have any effect on it. Not sure if that matters.
>>>>>>>
>>>>>>> 3. Finally I linked both m5_mmap.o a

[gem5-users] Re: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

I found the issue and fixed it.

The return value wasn't being put into the Rax register in
src/arch/x86/isa/decoder/two_byte_opcodes.isa

0x4: BasicOperate::gem5Op({{
uint64_t ret;
bool recognized = PseudoInst::pseudoInst(
xc->tcBase(), IMMEDIATE, ret);
if (!recognized)
fault = std::make_shared();
Rax = ret;

//<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
wrote:

> Let me further say that I know that the magic instructions are being
> called. I am just getting bogus return values.
>
> On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
> wrote:
>
>> Hi Matt,
>>
>> Thanks for this, it's very helpful. However after following the
>> instructions (I had to extrapolate a little because of the directory
>> structure changes you mentioned) I get the same result: Nill returns from
>> the magic instructions.
>> Actually It isn't nill, but a constant no matter what. If I compile my
>> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>>
>> To clarify, are these updated instructions specifically meant to fix
>> this issue I am running into? Or just general instructions to build m5op.o
>>
>> Here are the specific changes I made according to the link you provided,
>> the supplemental instructions, and extrapolating based on the directory
>> structure change.
>>
>> 1. In SConsopts I commented both:
>>
>> --- a/util/m5/src/abi/x86/SConsopts
>> +++ b/util/m5/src/abi/x86/SConsopts
>> @@ -27,8 +27,8 @@ Import('*')
>>
>>  env['ABI'] = 'x86'
>>  get_abi_opt('CROSS_COMPILE', '')
>> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
>> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>>
>>  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>>  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>>
>> 2. In SConstruct I added:
>>
>> --- a/util/m5/SConstruct
>> +++ b/util/m5/SConstruct
>> @@ -44,7 +44,9 @@ def abspath(d):
>>
>>  # Universal settings.
>>  main.Append(CXXFLAGS=[ '-O2' ])
>> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>>  main.Append(CCFLAGS=[ '-O2' ])
>>  main.Append(CPPPATH=[ common_include ])
>>
>> The compilation process compiles m5op.S with gcc though, so c++11 doesn't
>> have any effect on it. Not sure if that matters.
>>
>> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but
>> I am a little wary of m5_mmap
>>
>> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
>> like nothing? Do I need to link it?
>>
>> *Is there something inside the program I need to do before calling magic
>> instructions that has to do with m5_mmap?*
>>
>> Thanks for your help,
>>
>> Dan
>>
>> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair 
>> wrote:
>>
>>> Hi Dan,
>>>
>>> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
>>> created.  I had created a homework assignment for my course about it:
>>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>>> (see #2), but this is now already out of date as the location of some files
>>> changed.  The updated instructions are:
>>>
>>> 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
>>> current lines 46 and 47:
>>>
>>> main.Append(CXXFLAGS=[ '-O2' ])
>>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>>
>>> main.Append(CCFLAGS=[ '-O2' ])
>>>
>>> 2.  Now run the same command you ran in step 2 of the above link:
>>>
>>> scons build/x86/out/m5
>>>
>>> 3.  This will create the same two .o files in step 2 of the above link,
>>> in the same places (although the location of m5op.o may have changed to
>>> include/gem5 util/m5/build/x86/abi/x86/ according to some of the
>>> students in my course).
>>> Matt
>>>
>>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>>> Hey all,
>>>>
>>>> I've recently updated to using the dev branch for my GCN3 simulations.
>>>> I've noticed that I am now getting return values of 0 for every magic
>>>> instruction (m5_rpns for instance).
>>>>
>>>> Is there a special way I need to be compiling/linking m5ops.S to get
>>>> the return values to show up correctly? Or might this be a bug?
>>>>
>>>> Thanks,
>>>>
>>>> Dan
>>>> ___
>>>> 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: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Let me further say that I know that the magic instructions are being
called. I am just getting bogus return values.

On Mon, Nov 9, 2020 at 2:18 PM Daniel Gerzhoy 
wrote:

> Hi Matt,
>
> Thanks for this, it's very helpful. However after following the
> instructions (I had to extrapolate a little because of the directory
> structure changes you mentioned) I get the same result: Nill returns from
> the magic instructions.
> Actually It isn't nill, but a constant no matter what. If I compile my
> program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.
>
> To clarify, are these updated instructions specifically meant to fix
> this issue I am running into? Or just general instructions to build m5op.o
>
> Here are the specific changes I made according to the link you provided,
> the supplemental instructions, and extrapolating based on the directory
> structure change.
>
> 1. In SConsopts I commented both:
>
> --- a/util/m5/src/abi/x86/SConsopts
> +++ b/util/m5/src/abi/x86/SConsopts
> @@ -27,8 +27,8 @@ Import('*')
>
>  env['ABI'] = 'x86'
>  get_abi_opt('CROSS_COMPILE', '')
> -env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
> -env.Append(CCFLAGS='-DM5OP_ADDR=0x')
> +#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
> +#env.Append(CCFLAGS='-DM5OP_ADDR=0x')
>
>  env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
>  env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)
>
> 2. In SConstruct I added:
>
> --- a/util/m5/SConstruct
> +++ b/util/m5/SConstruct
> @@ -44,7 +44,9 @@ def abspath(d):
>
>  # Universal settings.
>  main.Append(CXXFLAGS=[ '-O2' ])
> +main.Append(CXXFLAGS=[ '-std=c++11' ])
>  main.Append(CCFLAGS=[ '-O2' ])
>  main.Append(CPPPATH=[ common_include ])
>
> The compilation process compiles m5op.S with gcc though, so c++11 doesn't
> have any effect on it. Not sure if that matters.
>
> 3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but
> I am a little wary of m5_mmap
>
> What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
> like nothing? Do I need to link it?
>
> *Is there something inside the program I need to do before calling magic
> instructions that has to do with m5_mmap?*
>
> Thanks for your help,
>
> Dan
>
> On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair 
> wrote:
>
>> Hi Dan,
>>
>> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
>> created.  I had created a homework assignment for my course about it:
>> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
>> (see #2), but this is now already out of date as the location of some files
>> changed.  The updated instructions are:
>>
>> 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
>> current lines 46 and 47:
>>
>> main.Append(CXXFLAGS=[ '-O2' ])
>> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>>
>> main.Append(CCFLAGS=[ '-O2' ])
>>
>> 2.  Now run the same command you ran in step 2 of the above link:
>>
>> scons build/x86/out/m5
>>
>> 3.  This will create the same two .o files in step 2 of the above link,
>> in the same places (although the location of m5op.o may have changed to
>> include/gem5 util/m5/build/x86/abi/x86/ according to some of the
>> students in my course).
>> Matt
>>
>> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hey all,
>>>
>>> I've recently updated to using the dev branch for my GCN3 simulations.
>>> I've noticed that I am now getting return values of 0 for every magic
>>> instruction (m5_rpns for instance).
>>>
>>> Is there a special way I need to be compiling/linking m5ops.S to get the
>>> return values to show up correctly? Or might this be a bug?
>>>
>>> Thanks,
>>>
>>> Dan
>>> ___
>>> 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: Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Hi Matt,

Thanks for this, it's very helpful. However after following the
instructions (I had to extrapolate a little because of the directory
structure changes you mentioned) I get the same result: Nill returns from
the magic instructions.
Actually It isn't nill, but a constant no matter what. If I compile my
program with -O0 its nill, if with -O2 its: 4198192, which is suspicious.

To clarify, are these updated instructions specifically meant to fix
this issue I am running into? Or just general instructions to build m5op.o

Here are the specific changes I made according to the link you provided,
the supplemental instructions, and extrapolating based on the directory
structure change.

1. In SConsopts I commented both:

--- a/util/m5/src/abi/x86/SConsopts
+++ b/util/m5/src/abi/x86/SConsopts
@@ -27,8 +27,8 @@ Import('*')

 env['ABI'] = 'x86'
 get_abi_opt('CROSS_COMPILE', '')
-env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
-env.Append(CCFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CXXFLAGS='-DM5OP_ADDR=0x')
+#env.Append(CCFLAGS='-DM5OP_ADDR=0x')

 env['CALL_TYPE']['inst'].impl('m5op.S', 'verify_inst.cc')
 env['CALL_TYPE']['addr'].impl('m5op_addr.S', default=True)

2. In SConstruct I added:

--- a/util/m5/SConstruct
+++ b/util/m5/SConstruct
@@ -44,7 +44,9 @@ def abspath(d):

 # Universal settings.
 main.Append(CXXFLAGS=[ '-O2' ])
+main.Append(CXXFLAGS=[ '-std=c++11' ])
 main.Append(CCFLAGS=[ '-O2' ])
 main.Append(CPPPATH=[ common_include ])

The compilation process compiles m5op.S with gcc though, so c++11 doesn't
have any effect on it. Not sure if that matters.

3. Finally I linked both m5_mmap.o and m5op.o as per the instructions but I
am a little wary of m5_mmap

What does m5_mmap actually do if I don't have M5OP_ADDR defined. It looks
like nothing? Do I need to link it?

*Is there something inside the program I need to do before calling magic
instructions that has to do with m5_mmap?*

Thanks for your help,

Dan

On Mon, Nov 9, 2020 at 12:12 PM Matt Sinclair 
wrote:

> Hi Dan,
>
> In recent weeks, Gabe (if I recall correctly) updated how the m5ops are
> created.  I had created a homework assignment for my course about it:
> https://pages.cs.wisc.edu/~sinclair/courses/cs752/fall2020/handouts/hw3.html
> (see #2), but this is now already out of date as the location of some files
> changed.  The updated instructions are:
>
> 1.  Update $GEM5_ROOT/util/m5/SConstruct, add a new line between the
> current lines 46 and 47:
>
> main.Append(CXXFLAGS=[ '-O2' ])
> *+main.Append(CXXFLAGS=[ '-std=c++11' ])*
>
> main.Append(CCFLAGS=[ '-O2' ])
>
> 2.  Now run the same command you ran in step 2 of the above link:
>
> scons build/x86/out/m5
>
> 3.  This will create the same two .o files in step 2 of the above link, in
> the same places (although the location of m5op.o may have changed to
> include/gem5 util/m5/build/x86/abi/x86/ according to some of the students
> in my course).
> Matt
>
> On Mon, Nov 9, 2020 at 9:25 AM Daniel Gerzhoy via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hey all,
>>
>> I've recently updated to using the dev branch for my GCN3 simulations.
>> I've noticed that I am now getting return values of 0 for every magic
>> instruction (m5_rpns for instance).
>>
>> Is there a special way I need to be compiling/linking m5ops.S to get the
>> return values to show up correctly? Or might this be a bug?
>>
>> Thanks,
>>
>> Dan
>> ___
>> 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] Magic instructions with GCN3 Model/hipcc return 0

[Daniel Gerzhoy via gem5-users]

Hey all,

I've recently updated to using the dev branch for my GCN3 simulations. I've
noticed that I am now getting return values of 0 for every magic
instruction (m5_rpns for instance).

Is there a special way I need to be compiling/linking m5ops.S to get the
return values to show up correctly? Or might this be a bug?

Thanks,

Dan
___
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: gem5 GCN3 GPU model running issues

[Daniel Gerzhoy via gem5-users]

I'm using the gcn3 docker, so Ubuntu 16.04 I believe

On Fri, Nov 6, 2020 at 5:44 PM Matt Sinclair 
wrote:

> Hi Daniel & Yichen,
>
> What OS are you using?  We have not encountered either of these problems
> thus far ... something must be different about your setup and ours.
>
> Thanks,
> Matt
>
> On Fri, Nov 6, 2020 at 4:35 PM Daniel Gerzhoy via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> For some reason that syscall is only built if you set a flag. Recompile
>> the simulator like so:
>>
>> scons -j$(nproc) build/GCN3_X86/gem5.opt --ignore-style SLICC_HTML=True
>> CCFLAGS_EXTRA="-DSYS_getdents -DSYS_getdents64"
>>
>> Cheers,
>>
>> Dan
>>
>> On Fri, Nov 6, 2020 at 5:25 PM Poremba, Matthew via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> [AMD Public Use]
>>>
>>>
>>>
>>> Looking into that syscall error now.
>>>
>>>
>>>
>>> I’m not quite sure yet how to fix the docker image since python 3.5 is
>>> the latest version available for the distro needed.  For now I disabled the
>>> check for 3.6 since it seems unnecessarily strict and doesn’t break
>>> anything related to this build.
>>>
>>>
>>>
>>>
>>>
>>> -Matt
>>>
>>>
>>>
>>> *From:* Yichen Yang 
>>> *Sent:* Friday, November 6, 2020 1:30 PM
>>> *To:* Poremba, Matthew 
>>> *Cc:* gem5 users mailing list 
>>> *Subject:* Re: [gem5-users] gem5 GCN3 GPU model running issues
>>>
>>>
>>>
>>> [CAUTION: External Email]
>>>
>>> Thanks!
>>>
>>>
>>>
>>> I tried the develop branch. But running into new problems
>>>
>>> warn: ignoring syscall set_robust_list(...)
>>> warn: ignoring syscall rt_sigaction(...)
>>>   (further warnings will be suppressed)
>>> warn: ignoring syscall rt_sigprocmask(...)
>>>   (further warnings will be suppressed)
>>> warn: ignoring syscall mprotect(...)
>>> warn: ignoring syscall mprotect(...)
>>> fatal: syscall getdents (#78) unimplemented.
>>> Memory Usage: 1562768 KBytes
>>>
>>>
>>>
>>> And I think the dockerfile needs some update. The scons requires
>>> python3.6 to compile gem5, to be specific, `python3-config` need python3.6,
>>> but the default version installed with the docker is 3.5.
>>>
>>>
>>>
>>> Best, Yichen
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Nov 6, 2020 at 2:58 PM Poremba, Matthew 
>>> wrote:
>>>
>>> [AMD Public Use]
>>>
>>>
>>>
>>> Hi Yichen,
>>>
>>>
>>>
>>>
>>>
>>> Based on the changes I see you’ve made, it seems like you are using an
>>> older version of gem5.  These should all be fixed, including the error you
>>> are seeing, on the tip of develop.
>>>
>>>
>>>
>>> Keep in mind GCN3 was not officially part of the gem5 20.1 release, so
>>> the most up to date version is on the develop branch until the next gem5
>>> release.
>>>
>>>
>>>
>>>
>>>
>>> -Matt
>>>
>>>
>>>
>>> *From:* Yichen Yang via gem5-users 
>>> *Sent:* Friday, November 6, 2020 11:34 AM
>>> *To:* gem5-users@gem5.org
>>> *Cc:* Yichen Yang 
>>> *Subject:* [gem5-users] gem5 GCN3 GPU model running issues
>>>
>>>
>>>
>>> [CAUTION: External Email]
>>>
>>> Hi,
>>>
>>>
>>>
>>> I was trying to run gem5 with its GCN3 GPU model following the
>>> instructions on
>>> https://www.gem5.org/documentation/general_docs/gpu_models/GCN3
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gem5.org%2Fdocumentation%2Fgeneral_docs%2Fgpu_models%2FGCN3=04%7C01%7CMatthew.Poremba%40amd.com%7C980fe8dd09644c3cc28008d8829b271d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637402950178924915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ZpmiYAeHJQWW2Q223UJnRuiA4DuBlgTf%2BGYMMh2p3AY%3D=0>
>>> .
>>>
>>>
>>>
>>> I fixed some bugs in the code but still cannot run the example. I
>>> attached commands and bugs I fixed below.
>>>
>>>
>>>
>>> The simulator launched and running into this problem

[gem5-users] Re: gem5 GCN3 GPU model running issues

[Daniel Gerzhoy via gem5-users]

For some reason that syscall is only built if you set a flag. Recompile the
simulator like so:

scons -j$(nproc) build/GCN3_X86/gem5.opt --ignore-style SLICC_HTML=True
CCFLAGS_EXTRA="-DSYS_getdents -DSYS_getdents64"

Cheers,

Dan

On Fri, Nov 6, 2020 at 5:25 PM Poremba, Matthew via gem5-users <
gem5-users@gem5.org> wrote:

> [AMD Public Use]
>
>
>
> Looking into that syscall error now.
>
>
>
> I’m not quite sure yet how to fix the docker image since python 3.5 is the
> latest version available for the distro needed.  For now I disabled the
> check for 3.6 since it seems unnecessarily strict and doesn’t break
> anything related to this build.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Yichen Yang 
> *Sent:* Friday, November 6, 2020 1:30 PM
> *To:* Poremba, Matthew 
> *Cc:* gem5 users mailing list 
> *Subject:* Re: [gem5-users] gem5 GCN3 GPU model running issues
>
>
>
> [CAUTION: External Email]
>
> Thanks!
>
>
>
> I tried the develop branch. But running into new problems
>
> warn: ignoring syscall set_robust_list(...)
> warn: ignoring syscall rt_sigaction(...)
>   (further warnings will be suppressed)
> warn: ignoring syscall rt_sigprocmask(...)
>   (further warnings will be suppressed)
> warn: ignoring syscall mprotect(...)
> warn: ignoring syscall mprotect(...)
> fatal: syscall getdents (#78) unimplemented.
> Memory Usage: 1562768 KBytes
>
>
>
> And I think the dockerfile needs some update. The scons requires python3.6
> to compile gem5, to be specific, `python3-config` need python3.6, but the
> default version installed with the docker is 3.5.
>
>
>
> Best, Yichen
>
>
>
>
>
>
>
> On Fri, Nov 6, 2020 at 2:58 PM Poremba, Matthew 
> wrote:
>
> [AMD Public Use]
>
>
>
> Hi Yichen,
>
>
>
>
>
> Based on the changes I see you’ve made, it seems like you are using an
> older version of gem5.  These should all be fixed, including the error you
> are seeing, on the tip of develop.
>
>
>
> Keep in mind GCN3 was not officially part of the gem5 20.1 release, so the
> most up to date version is on the develop branch until the next gem5
> release.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Yichen Yang via gem5-users 
> *Sent:* Friday, November 6, 2020 11:34 AM
> *To:* gem5-users@gem5.org
> *Cc:* Yichen Yang 
> *Subject:* [gem5-users] gem5 GCN3 GPU model running issues
>
>
>
> [CAUTION: External Email]
>
> Hi,
>
>
>
> I was trying to run gem5 with its GCN3 GPU model following the
> instructions on
> https://www.gem5.org/documentation/general_docs/gpu_models/GCN3
> 
> .
>
>
>
> I fixed some bugs in the code but still cannot run the example. I attached
> commands and bugs I fixed below.
>
>
>
> The simulator launched and running into this problem:
>
> Program Started!
> info: running on device
> info: architecture on AMD GPU device is: 801
> info: allocate host mem (  7.63 MB)
> info: launch 'vector_square' kernel
> panic: panic condition availableTokens > maxTokens occurred: More tokens
> available than the maximum after recvTokens!
> Memory Usage: 1737788 KBytes
> Program aborted at tick 137231963000
>
>
>
> Is there anything I did incorrectly?
>
>
>
> Thanks!
>
> Best, Yichen
>
>
>
> To be specific, I use the following command:
>
> ## build docker
> docker build -t gcn3-test gem5/util/dockerfiles/gcn-gpu
> ## make gem5
> docker run --rm -v $PWD/gem5:/gem5 -w /gem5 gcn3-test scons -sQ -j$(nproc)
> build/GCN3_X86/gem5.opt
> ## make application
> docker run --rm -v $PWD/gem5-resources:/gem5-resources -w /gem5-resources
> -u $UID:$GID \
> gcr.io/gem5-test/gcn-gpu
> 
>  make
> gfx8-apu -C /gem5-resources/src/square
> ## run gem5
> docker run --rm -v $PWD/gem5:/gem5 -v $PWD/gem5-resources:/gem5-resources \
> -w /gem5 gcn3-test \
> build/GCN3_X86/gem5.opt configs/example/apu_se.py -n2 \
> --benchmark-root=/gem5-resources/src/square/bin \
> -c square.o
>
>
>
> And here's the bugs I fixed:
>
> diff --git a/configs/example/apu_se.py b/configs/example/apu_se.py
> index 03418c3..a285a14 100644
> --- a/configs/example/apu_se.py
> +++ b/configs/example/apu_se.py
> @@ -174,7 +174,7 @@ parser.add_option("--numLdsBanks", type="int",
> default=32,
>help="number of 

[gem5-users] Re: Setting up cluster for gem5

[Daniel Gerzhoy via gem5-users]

Hey Shehab,

I've been working with gem5 on my group's research cluster for a while now.
1) Gem5 isn't very memory hungry in my experience, sometimes long
simulations (I'm talking 3 weeks+) will  start bloating to GB of RAM but
its usually not paging so it doesn't slow things down (depends on the
program you are running)
I exclusively use Syscall Emulation mode, so that may not apply in Full
System.

*It is however single-threaded. So if your entire group is running many
experiments at the same time make sure you have a ton of cores.*

2) As for job management, I created my own system for
configuring/running/parsing etc.that I've built with python.

gem5 as of recently has been shipped with dockerfiles. I use the gcn3
dockerfile for instance. I'd recommend using them.
Again I use a custom solution here, but I'm pretty sure container job
management is a solved problem. I think one of them is "kubernets" (see
https://kubernetes.io/)
I don't have experience with anything like that, but I'm sure that would be
useful.

Also, if you plan on editing gem5 and your sourcecode is going to be
located on the cluster, I'd recommend using code-server (
https://github.com/cdr/code-server)
It broadcasts an instance of vscode to a web page that you can access from
anywhere. I used to use gvim and bash scripts and it was hell. Code server
was a life-saver.

If you (or anyone else) already have a solution for editing code on the
cluster I would be interested in what it is.

Good luck!

Dan Gerzhoy
PhD Candidate, Computer Engineering
University of Maryland College Park

On Fri, Nov 6, 2020 at 8:38 AM Shehab Elsayed via gem5-users <
gem5-users@gem5.org> wrote:

> Hello All,
>
> My group is in the process of upgrading our cluster and since many of us
> are using gem5 I was wondering if anyone has experience or recommendation
> they would like to share about the process for a smooth gem5 operation.
> Mainly I am concerned about 2 issues:
>
> 1) Required hard disk and memory on the nodes for a smooth gem5 operation.
> 2) OS and job management systems or any software related recommendations.
>
> Thank you very much in advance.
>
> Best Regards,
> Shehab
> ___
> 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: What is the role of TimeBuffer in gem5?

[Daniel Gerzhoy via gem5-users]

Hey guys,

I just interacted with it to fix a bug in the O3 cpu. Seems to me
a Timebuffer is how the pipeline stages communicate with each other.
Looks like a wrapper for the datastructures that
communicate between different stages, as "wires."
Each wire within a time buffer communicates between different stages, some
backwards, some forwards, each with a specific latency based on the config.
Every tick you advance() each of the buffers to propagate signals between
the stages.
When the data reaches its endpoint the timebuffer takes care of getting rid
of it.

In O3 its a little confusing because the timeBuffer object which takes care
of backwards communication is of type TimeBuffer ,
and there are the fetchQueue decodeQueue etc which are of type TimeBuffer
as well.

Hope this helps,

Dan

On Tue, Nov 3, 2020 at 11:49 AM Jason Lowe-Power via gem5-users <
gem5-users@gem5.org> wrote:

> Hello,
>
> I've been using gem5 for ~10 years, and this is the first time I've ever
> seen this code :D. It  was committed 14 years ago, and it hasn't been
> touched since.
>
> It looks to me like it's used for gathering statistics about the activity
> of different CPU pipeline stages. However, I *know* it's not actively
> maintained, so I would guess that it doesn't work anymore. As far as what
> it's doing, I think the comment in activity.hh is probably the best
> explanation:
>
> http://doxygen.gem5.org/release/current/classActivityRecorder.html#details
>
> Cheers,
> Jason
>
> On Tue, Nov 3, 2020 at 4:49 AM yujiecui--- via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> What does TimeBuffer in gem5 do? I read its source code, but there are no
>> comments and it is not easy to understand operations. I saw in the tick
>> function in the cpu.cc file that every tick() will proceed
>> timeBuffer.advance();
>> fetchQueue.advance();
>> decodeQueue.advance();
>> renameQueue.advance();
>> iewQueue.advance();
>> But the function of advance is
>> advance()
>> {
>>  if (++base >= size)
>> base = 0;
>> int ptr = base + future;
>> if (ptr >= (int)size)
>> ptr -= size;
>> (reinterpret_cast(index[ptr]))->~T();
>> std::memset(index[ptr], 0, sizeof(T));
>> new (index[ptr]) T;
>> }
>> Just looking at the source code, this is really hard to understand. I
>> think if someone can tell me what it is doing? I think it’s easier for me
>> to understand this code
>> ___
>> 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: SE Mode and Std::thread

[Daniel Gerzhoy via gem5-users]

Ciro,

When I merged the changes in from that patch and its relations I started
getting a crash instead of a hang. That crash, I can reproduce on develop.

gem5.opt: build/X86/cpu/o3/cpu.cc:823: void
FullO3CPU::removeThread(ThreadID)
[with Impl = O3CPUImpl; ThreadID = short int]: Assertion
`commit.rob->isEmpty(tid)' failed.

Check out the gem5-users thread from last week:
  [gem5-users] gem5 pthread regression with O3CPU on x86?

Incidentally this highlights the need for a slack or something like that
for gem5-users/develop where we can tag people etc.

Anyway:

 I am working on a fix and will open a ticket. Apparently it works ok
on ARM, Derrick Greenspan ran it.. Not sure what that means, it might just
happen to be that the ROB is empty when the ARM core is halted, I think
that the flaw is in the cpu code itself. (See my description in that
thread).

Dan

On Mon, Nov 2, 2020 at 7:19 AM Ciro Santilli  wrote:

> Daniel, if you manage to reproduce on clean develop, please also open an
> issue at https://gem5.atlassian.net/jira/software/c/projects/GEM5/issues I'd
> also be curious to see if it reproduces on se.py (so I could see if it also
> happens on ARM).
>
> We've had some ARM-specific SE issues e.g. at
> https://gem5.atlassian.net/browse/GEM5-537 but this is X86 so I'm not
> sure. With SyscallAll + ExecAll and some patience most bugs can be found.
> Presumably new instructions are being run in an infinite loop, otherwise
> simulation would reach the end of time. So I would try to determine what
> that minimal loop is and why it won't exit.
> --------------
> *From:* Daniel Gerzhoy via gem5-users 
> *Sent:* Wednesday, October 28, 2020 7:21 PM
> *To:* gem5 users mailing list 
> *Cc:* Daniel Gerzhoy 
> *Subject:* [gem5-users] Re: SE Mode and Std::thread
>
> Looks like this is related to this change:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/8184
>
> I'm a bit behind develop because of custom changes and don't have this
> patch merged yet.
> Cherry picking this might work, but merging would probably be the best
> solution, if time consuming.
>
> Cheers,
> Dan
>
>
> On Tue, Oct 27, 2020 at 3:39 PM Daniel Gerzhoy 
> wrote:
>
> Hey all,
>
> I'm running into a strange issue where threads are not spawning when
> launched with std::thread. It seems to work once, and then I try to launch
> again using a newly allocated thread pointer (after deleting the old one)
> and it hangs.
>
> Minimal example:
>
> void foo()
> {
>   printf("Foo alive from tid %lu\n", m5_cpu_id());
>   //m5_cpu_id is a pseudo_instruction I added to return tc->cpuId()
> }
>
> void main()
> {
>   printf("Launching foo 1"\n);
>   std::thread * mythread = new std::thread(foo,...);
>   printf("Done Launching foo 1"\n);
>
>   printf("Joining foo 1"\n);
>   myThread->join();
>   delete myThread;
>
>   printf("Launching foo 2"\n);
>   mythread = new std::thread(foo,...);
>   printf("Done Launching foo 2"\n);
>
>   printf("Joining foo 2"\n);
>   myThread->join(); //<<<<< IT HANGS HERE
>   printf("Done Everything!\n");
>   delete myThread;
> }
>
> __
>
> It works fine with TimingSimpleCPU, but then with DerivO3CPU I get the
> failure.
>
> Output for  DerivO3CPU:
>   Launch 1
>   Done Launch 1
>   I'm alive on tid 1
>   Launch 2
>   Done Launch 2
>
> And there it Hangs.
>
> FYI I am using apu_se.py, though with the above minimal example I've
> managed to reproduce the bug with no GPU code (nor even hipcc) involved.
>
> I went back to the original code I found that showed std::thread could be
> used here:
> https://www.gem5.org/documentation/learning_gem5/part3/running/
>
> [image: image.png]
>
> The comment there that -1 is required for SE mode, and then the subsequent
> comment about appeasing SE mode...
>
> What exactly do those comments mean?
>
> I'm going to keep debugging, but if anyone has any suggestions for debug
> flags that could be helpful it would be appreciated. (I'm using SyscallAll
> and going to investigate some of the syscalls SE mode ignores).
>
> I'm wondering if maybe it is calling join() multiple times that might be
> the problem? Though unsure why at this point.
>
> Thanks!
>
> Dan
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
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: gem5 pthread regression with O3CPU on x86?

[Daniel Gerzhoy via gem5-users]

I'm getting the same error, working on fixing it but not very familiar with
the O3 cpu code (Or I wasn't before anyway).

>From what I can tell:

*FullO3CPU::scheduleThreadExitEvent *schedules the threadExitEvent
for the next cycle, assuming that it will empty by then.
It sets* exitingThreads[tid] = true;*

By the time it gets to *FullO3CPU::exitThreads *the reorder buffer
still has entries in it.

The reorder buffer can only squash 8 instructions per cycle. In my test
case at the time a halt is called, there are 70 instructions in the reorder
buffer.
So by the normal mechanism it would take 9 cycles to squash them all.
In order to decrement the counter that the error is complaining about:
*threadEntries[tid],* the commit stage has to retire them.

Commit can usually only commit 8 instructions per cycle but since it is
retiring squashed instructions it does them all in one cycle.

I can only guess at the reason for commit to be able to commit all its
squashed instructions in one cycle while the ROB has to do them in chunks
but the disparity is interesting. Could be a bug?

I increased the latency at which  *scheduleThreadExitEvent *schedules the
wait event, and I saw the ROB take its 9 cycles to squash and Commit take
one more cycle to fully retire them.

However in the interim fetch hadn't been disabled and the ROB filled up
with more instructions. (Fetch gets disabled when the event triggers, just
before the assertion fail we are seeing)

My idea to fix it (if indeed this is a bug, I could be wrong) would be one
of two things, depending on if the ROB is allowed to squash all of the
instructions at once or not.

If  it is allowed:
Squash all the instructions on the cycle the halt is called, then the
next cycle before the event triggers (it has a low priority) the commit
stage will retire all of the ROB instructions.
Voila, 0 ROB entries.

Else:
Then the cpu needs to deactivate the fetch stage on the cycle it gets
the halt,
and the cpu needs to wait  *threadEntries[tid]/squashWidth *cycles (or
keep checking every cycle, I don't actually know what is realistic)

If this is in fact a bug, and I get some guidance about what would be the
realistic solution, I can check in the fix to develop.

Cheers!

Dan


On Thu, Oct 29, 2020 at 3:35 AM Liao Xiongfei via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Derrick,
>
>
>
> I just built gem5 simulator based on code downloaded yesterday.
>
>
>
> The simulator crashed with messages below.
>
>
>
>
>
>
>
>  REAL SIMULATION 
>
> info: Entering event queue @ 0.  Starting simulation...
>
> Hello world!
>
> Hello world!
>
> gem5.opt: build/X86/cpu/o3/cpu.cc:823: void
> FullO3CPU::removeThread(ThreadID) [with Impl = O3CPUImpl; ThreadID =
> short int]: Assertion `commit.rob->isEmpty(tid)' failed.
>
> Program aborted at tick 17776220
>
> --- BEGIN LIBC BACKTRACE ---
>
> ./build/X86/gem5.opt(+0xa7eff0)[0x7f6734002ff0]
>
> ./build/X86/gem5.opt(+0xa9352e)[0x7f673401752e]
>
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f6732fd23c0]
>
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f673212618b]
>
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f6732105859]
>
> /lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f6732105729]
>
> /lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f6732116f36]
>
> ./build/X86/gem5.opt(+0x43e60a)[0x7f67339c260a]
>
> ./build/X86/gem5.opt(+0x43e945)[0x7f67339c2945]
>
> ./build/X86/gem5.opt(+0x43f75d)[0x7f67339c375d]
>
> ./build/X86/gem5.opt(+0xa87069)[0x7f673400b069]
>
> ./build/X86/gem5.opt(+0xaa8bf8)[0x7f673402cbf8]
>
> ./build/X86/gem5.opt(+0xaa99ed)[0x7f673402d9ed]
>
> ./build/X86/gem5.opt(+0x86e720)[0x7f6733df2720]
>
> ./build/X86/gem5.opt(+0x3d425f)[0x7f673395825f]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2a8408)[0x7f6733288408]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x8dd8)[0x7f673305df48]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f67331aad3b]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7f6733287de4]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f6733054d6d]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7f673305cef6]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x8006b)[0x7f673306006b]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f6733054d6d]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x12fd)[0x7f673305646d]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f67331aad3b]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7f6733287de4]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f6733054d6d]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7f673305cef6]
>
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f67331aad3b]
>
>
> 

[gem5-users] Re: SE Mode and Std::thread

[Daniel Gerzhoy via gem5-users]

Looks like this is related to this change:

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

I'm a bit behind develop because of custom changes and don't have this
patch merged yet.
Cherry picking this might work, but merging would probably be the best
solution, if time consuming.

Cheers,
Dan


On Tue, Oct 27, 2020 at 3:39 PM Daniel Gerzhoy 
wrote:

> Hey all,
>
> I'm running into a strange issue where threads are not spawning when
> launched with std::thread. It seems to work once, and then I try to launch
> again using a newly allocated thread pointer (after deleting the old one)
> and it hangs.
>
> Minimal example:
>
> void foo()
> {
>   printf("Foo alive from tid %lu\n", m5_cpu_id());
>   //m5_cpu_id is a pseudo_instruction I added to return tc->cpuId()
> }
>
> void main()
> {
>   printf("Launching foo 1"\n);
>   std::thread * mythread = new std::thread(foo,...);
>   printf("Done Launching foo 1"\n);
>
>   printf("Joining foo 1"\n);
>   myThread->join();
>   delete myThread;
>
>   printf("Launching foo 2"\n);
>   mythread = new std::thread(foo,...);
>   printf("Done Launching foo 2"\n);
>
>   printf("Joining foo 2"\n);
>   myThread->join(); //< IT HANGS HERE
>   printf("Done Everything!\n");
>   delete myThread;
> }
>
> __
>
> It works fine with TimingSimpleCPU, but then with DerivO3CPU I get the
> failure.
>
> Output for  DerivO3CPU:
>   Launch 1
>   Done Launch 1
>   I'm alive on tid 1
>   Launch 2
>   Done Launch 2
>
> And there it Hangs.
>
> FYI I am using apu_se.py, though with the above minimal example I've
> managed to reproduce the bug with no GPU code (nor even hipcc) involved.
>
> I went back to the original code I found that showed std::thread could be
> used here:
> https://www.gem5.org/documentation/learning_gem5/part3/running/
>
> [image: image.png]
>
> The comment there that -1 is required for SE mode, and then the subsequent
> comment about appeasing SE mode...
>
> What exactly do those comments mean?
>
> I'm going to keep debugging, but if anyone has any suggestions for debug
> flags that could be helpful it would be appreciated. (I'm using SyscallAll
> and going to investigate some of the syscalls SE mode ignores).
>
> I'm wondering if maybe it is calling join() multiple times that might be
> the problem? Though unsure why at this point.
>
> Thanks!
>
> Dan
>
___
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] SE Mode and Std::thread

[Daniel Gerzhoy via gem5-users]

Hey all,

I'm running into a strange issue where threads are not spawning when
launched with std::thread. It seems to work once, and then I try to launch
again using a newly allocated thread pointer (after deleting the old one)
and it hangs.

Minimal example:

void foo()
{
  printf("Foo alive from tid %lu\n", m5_cpu_id());
  //m5_cpu_id is a pseudo_instruction I added to return tc->cpuId()
}

void main()
{
  printf("Launching foo 1"\n);
  std::thread * mythread = new std::thread(foo,...);
  printf("Done Launching foo 1"\n);

  printf("Joining foo 1"\n);
  myThread->join();
  delete myThread;

  printf("Launching foo 2"\n);
  mythread = new std::thread(foo,...);
  printf("Done Launching foo 2"\n);

  printf("Joining foo 2"\n);
  myThread->join(); //< IT HANGS HERE
  printf("Done Everything!\n");
  delete myThread;
}

__

It works fine with TimingSimpleCPU, but then with DerivO3CPU I get the
failure.

Output for  DerivO3CPU:
  Launch 1
  Done Launch 1
  I'm alive on tid 1
  Launch 2
  Done Launch 2

And there it Hangs.

FYI I am using apu_se.py, though with the above minimal example I've
managed to reproduce the bug with no GPU code (nor even hipcc) involved.

I went back to the original code I found that showed std::thread could be
used here:
https://www.gem5.org/documentation/learning_gem5/part3/running/

[image: image.png]

The comment there that -1 is required for SE mode, and then the subsequent
comment about appeasing SE mode...

What exactly do those comments mean?

I'm going to keep debugging, but if anyone has any suggestions for debug
flags that could be helpful it would be appreciated. (I'm using SyscallAll
and going to investigate some of the syscalls SE mode ignores).

I'm wondering if maybe it is calling join() multiple times that might be
the problem? Though unsure why at this point.

Thanks!

Dan
___
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 docker file missing

[Daniel Gerzhoy via gem5-users]

Looks like that command needs to be updated, or the makefile.

Try the command without "square" at the end (" docker run --rm -v
$PWD/gem5-resources:/gem5-resources -w /gem5-resources/src/square 
make ")
If you look in the makefile the first rule is "gfx8-apu" not "square" so
you could also change the command to be "make gfx8-apu"

You are failing to compile with g++ because you need to use hipcc (the hip
compiler), which if you look at the makefile it is doing for you (along
with the important --amdgpu-target=gfx801 flag.

Hope this helps,

Dan

On Mon, Aug 31, 2020 at 11:46 AM Samaksh Sethi via gem5-users <
gem5-users@gem5.org> wrote:

> Ok so I forgot to mention that the gem5-resources repository (
> https://gem5.googlesource.com/public/gem5-resources/) doesn't have the
> makefile in the main folder, it's actually in gem5-resources>>src>>square,
> so I can't just run the command (docker run --rm -v
> $PWD/gem5-resources:/gem5-resources -w /gem5-resources/src/square 
> make square) directly or it just says ""make: *** No rule to make target
> 'square'.  Stop.""
>
> About square.out, I'm unable to make that too directly with gcc/g++
> because of the error that I'm getting which is the same as when I run docker
> run --rm -v $PWD/gem5-resources:/gem5-resources -w
> /gem5-resources/src/square  make square ""square.cpp:24:29:
> fatal error: hip/hip_runtime.h: No such file or directory compilation
> terminated."" I can't find the file myself too, I did look in the makefile
> folder (gem5-resources>>src>>square), I couldn't find the sources.mk file
> and so I couldn't find any $INCLUDE tag, so I couldn't understand where to
> look.
>
> Lastly, about docker files, I tried using the method you suggested with
> docker run -it  bash, let me know if there's a better method or
> any other options I should also be using. Also, about the --rm docker
> option, what exactly does that remove, the docker image I created/compiled
> with docker build -t  (approx 3.1GB) or just this instance of
> the image? because if it deletes the compiled image, then it would be
> really time consuming to recompile it everytime I need to test a change
> (eg-running make square multiple times). Also let me know if I'm using the
> terms image/container/instance correctly or not.
> ___
> 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 docker file missing

[Daniel Gerzhoy via gem5-users]

Samaksh,

Yep, thats precisely what I've been doing. Using the docker from the
develop branch, and then the simulator is the staging branch.

It actually looks like you pointed the simulator onto the square.cpp source
file rather than the square.out (or whatever your compiler outputs).

Not sure if this was a typo or not, but you need to compile the source into
a binary first using the command from that link:

docker run --rm -v $PWD/gem5-resources:/gem5-resources -w /gem5-resources
 make square

You can also just have a docker container running and then attach to it to
do command line (commands) directly in the container, so you could cd into
gem5-resources and then just type "make square." \Sometimes this is more
convenient, sometimes not. Up to you.

Best,

Dan


On Sun, Aug 30, 2020 at 7:10 PM Matt Sinclair 
wrote:

> Dan or Kyle can confirm, but yes I believe that is what others are doing.
>
> If you look through the posted text from running square, you have a fatal
> error because of it being able to access gem5-resources.  Kyle, have you
> seen this before?
>
> Matt
>
> On Sun, Aug 30, 2020 at 5:43 PM Samaksh Sethi via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Okay, yeah that does make sense to me.
>> So what i understand is, I used the develop branch for the dockerfile and
>> then I run everything as usual from the staging branch
>>
>> Ok, so that works, Thanks a lot!!
>> I was able to get the build command running,
>>
>> Just one last thing, how do I confirm everything worked ok?
>> I ran this command for square (changed a bit, from
>> http://www.gem5.org/documentation/general_docs/gpu_models/GCN3)
>> *docker run --rm -v $PWD/gem5:/gem5 -v
>> $PWD/gem5-resources:/gem5-resources -w /gem5 gcn-docker
>> build/GCN3_X86/gem5.opt configs/example/apu_se.py -n2
>> --benchmark-root=/gem5-resources/src/square -c square.cpp*
>> warn: system.ruby.network adopting orphan SimObject param 'int_links'
>> warn: system.ruby.network adopting orphan SimObject param 'ext_links'
>> warn: DRAM device capacity (8192 Mbytes) does not match the address range
>> assigned (512 Mbytes)
>> gem5 Simulator System.  http://gem5.org
>> gem5 is copyrighted software; use the --copyright option for details.
>>
>> gem5 compiled Aug 30 2020 22:11:25
>> gem5 started Aug 30 2020 22:27:07
>> gem5 executing on d154d77a3679, pid 1
>> command line: build/GCN3_X86/gem5.opt configs/example/apu_se.py -n2
>> --benchmark-root=/gem5-resources/src/square -c square.cpp
>>
>> info: Standard input is not a terminal, disabling listeners.
>> Num SQC =  1 Num scalar caches =  1 Num CU =  4
>> Global frequency set at 1 ticks per second
>> fatal: Can't load object file /gem5-resources/src/square/square.cpp
>> Memory Usage: 1182408 KBytes
>>
>> Now what? There's nothing in the stats.txt, is there any other command I
>> need to run too?
>>
>>
>>
>>
>> ___
>>
>> 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
>
> --
> Regards,
> Matt Sinclair
> Assistant Professor
> University of Wisconsin-Madison
> Computer Sciences Department
> cs.wisc.edu/~sinclair
>
___
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/hip constant memory

[Daniel Gerzhoy via gem5-users]

Matt,

Thanks for the detailed response. Yeah that sounds pretty involved, I
probably won't go down that path unless I see no other way.

When you say the data cache do you mean make it a global memory array? This
is actually what I already have, and I wanted to keep the "constant" data
from getting evicted by other global memory data.

How does the SQC work in terms of data rather than instructions? Could I
have data go in the SQC?

On that note, where does "Shared" memory reside?

Thanks,

Dan

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

> Hi Dan,
>
> Tony will have to confirm, but I believe AMD didn’t add support for
> constant memory because none of the applications they looked at used it.
> The mincore error is kind of a catch all, saying that something bad
> happened and you went down a failure path.
>
> Assuming the above is correct, if you wanted to add support for constant
> memory, you’d need to start by adding the appropriate syscall support.  I
> suspect the reason you are hitting the mincore error is because your
> program attempted to run an unimplemented syscall and didn’t know what to
> do.  If you want to go down this route, I would suggest running with a
> debug build of gem5 and using gdb to try and trace back where the mincore
> failure is coming from, but from personal experience I can tell you this is
> not always 100% effective.  Another other option would be to use gdb in the
> application itself and step through it, seeing what ioctls the
> hipMemcpyToSymbol is using under the hood.  Anyways, in gem5 you would also
> need to instantiate a separate constant cache and connect that to the
> existing memory hierarchy in the appropriate places.  So, as you can
> probably tell, this will likely be a fairly intensive process to get
> working though.
>
> The alternative would be to change your program to use the data cache for
> the array instead of using the constant cache.  This would potentially hurt
> the performance of the application, but wouldn’t require adding any new
> features to the simulator.
>
> To answer your other questions more directly:
>
> - the constant memory allocations shouldn’t go to the scalar cache or data
> cache.  It uses a separate cache, the constant cache.  If you look at
> slides on GCN3 (e.g., slide 23 of:
> https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf
> or Figure 1.1 in
> http://developer.amd.com/wordpress/media/2013/12/AMD_GCN3_Instruction_Set_Architecture_rev1.1.pdf),
> you’ll see a separate cache from the I$, D$, and scalar cache for constants.
> - See slide 60:
> http://www.m5sim.org/wiki/images/1/19/AMD_gem5_APU_simulator_isca_2018_gem5_wiki.pdf
> for the SQC explanation.
>
> Thanks,
> Matt
>
> On Tue, Aug 18, 2020 at 8:37 AM Daniel Gerzhoy via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hey all,
>>
>> Is there a way to use constant memory in the GPU Model right now?
>>
>> Using the
>>
>> *__constant__ float variable[SIZE];*
>>
>> and
>>
>> *hipMemcpyToSymbol(...)*
>>
>> results in a
>>
>> *fatal: syscall mincore (#27) unimplemented.*
>>
>> I've been looking through the code to find a way, but I haven't yet.
>> I guess a clarifying question might be: which cache does constant memory
>> go to? the SQC? Scalar Cache? (Those two actually seem to have the same
>> controller)
>>
>> Thanks,
>>
>> Dan Gerzhoy
>>
>>
>> ___
>>
>> 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

[Daniel Gerzhoy via gem5-users]

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:

> 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
>>
>>
>> 
>>  Virus-free.
>> www.avg.com
>> 

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

[Daniel Gerzhoy via gem5-users]

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


 
  Virus-free.
 www.avg.com
 
 <#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] GCN3/hip constant memory

[Daniel Gerzhoy via gem5-users]

Hey all,

Is there a way to use constant memory in the GPU Model right now?

Using the

*__constant__ float variable[SIZE];*

and

*hipMemcpyToSymbol(...)*

results in a

*fatal: syscall mincore (#27) unimplemented.*

I've been looking through the code to find a way, but I haven't yet.
I guess a clarifying question might be: which cache does constant memory go
to? the SQC? Scalar Cache? (Those two actually seem to have the same
controller)

Thanks,

Dan Gerzhoy
___
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: Getting tick number from C code

[Daniel Gerzhoy via gem5-users]

There is the m5_rpns() pseudo instruction that returns the current time in
nanoseconds. That is it returns:

return curTick() / SimClock::Int::ns;

That value is simply 10^3 (unless you've changed the ticks per second it
for some reason)
So you simply need to multiply the result of rpns() by 10^3

For convenience I've made a new pseudo instruction that returns the ticks
value directly. (You could just comment out that division in rpns() as well
if you don't care to implement your own pseudo instruction.

So I guess for your purposes, record the ticks at the beginning and end of
your function.

Best,

Dan

On Thu, Aug 6, 2020 at 1:07 PM Muhammad Aamir via gem5-users <
gem5-users@gem5.org> wrote:

> Hi everyone,
>
> Is there a way where I can set a checkpoint and print the tick number when
> gem5 has reached that checkpoint. What I would like to do is get the number
> of ticks a certain function has taken to run. Do m5ops have this capability
> or i have to use some other method.
>
> Any help would be appreciated.
>
> Thanks,
> Muhammad Aamir Saeed
> ___
> 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

[Daniel Gerzhoy via gem5-users]

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

[Daniel Gerzhoy via gem5-users]

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

[Daniel Gerzhoy via gem5-users]

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: GCN3 GPU Simulation Start-Up Time

[Daniel Gerzhoy via gem5-users]

e application, maybe
>>>> it will be easier to spot differences.
>>>>
>>>> I would also recommend updating to the latest commit on the staging
>>>> branch -- I don't believe it should break anything with those patches.
>>>>
>>>> Yes, looks like you are using the release version of ROCm -- no issues
>>>> there.
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>> On Thu, Jun 11, 2020 at 9:38 AM Daniel Gerzhoy <
>>>> daniel.gerz...@gmail.com> wrote:
>>>>
>>>> I am using the docker, yeah.
>>>> It's running on our server cluster which is a Xeon Gold 5117 @ (2.0 -
>>>> 2.8 GHz) which might make up some of the difference, the r5 3600 has a
>>>> faster clock (3.6-4.2 GHz).
>>>>
>>>> I've hesitated to update my branch because in the Dockerfile it
>>>> specifically checks this branch out and applies a patch, though the patch
>>>> isn't very extensive.
>>>> This was from a while back (November maybe?) and I know you guys have
>>>> been integrating things into the main branch (thanks!)
>>>> I was thinking I would wait until it's fully merged into the mainline
>>>> gem5 branch and rebase onto that and try to merge my changes in.
>>>>
>>>> Last I checked the GCN3 stuff is in the dev branch not the master right?
>>>>
>>>> But if it will help maybe I should update to the head of this branch.
>>>> Will I need to update the docker as well?
>>>>
>>>> As for the debug vs release rocm I think I'm using the release version.
>>>> This is what the dockerfile built:
>>>>
>>>> ARG rocm_ver=1.6.2
>>>> RUN wget -qO- repo.radeon.com/rocm/archive/apt_${rocm_ver}.tar.bz2
>>>> <http://repo.radeon.com/rocm/archive/apt_$%7Brocm_ver%7D.tar.bz2> \
>>>> | tar -xjv \
>>>> && cd apt_${rocm_ver}/pool/main/ \
>>>> && dpkg -i h/hsakmt-roct-dev/* \
>>>> && dpkg -i h/hsa-ext-rocr-dev/* \
>>>> && dpkg -i h/hsa-rocr-dev/* \
>>>> && dpkg -i r/rocm-utils/* \
>>>> && dpkg -i h/hcc/* \
>>>> && dpkg -i h/hip_base/* \
>>>> && dpkg -i h/hip_hcc/* \
>>>> && dpkg -i h/hip_samples/*
>>>>
>>>>
>>>> I ran a benchmark that prints that it entered main and returns
>>>> immediately, this took 9 minutes.
>>>> I've attached a debug trace with debug flags =
>>>> "GPUDriver,SyscallVerbose"
>>>> There's a lot of weird things going on, "syscall open: failed",
>>>> "syscall brk: break point changed to [...]", and lots of ignored system
>>>> calls.
>>>>
>>>> head of Stats for reference:
>>>> -- Begin Simulation Statistics --
>>>> sim_seconds  0.096192
>>>> # Number of seconds simulated
>>>> sim_ticks 96192368500
>>>> # Number of ticks simulated
>>>> final_tick96192368500
>>>> # Number of ticks from beginning of simulation (restored from
>>>> checkpoints and never reset)
>>>> sim_freq 1
>>>>   # Frequency of simulated ticks
>>>> host_inst_rate 175209
>>>> # Simulator instruction rate (inst/s)
>>>> host_op_rate   338409
>>>> # Simulator op (including micro ops) rate (op/s)
>>>> host_tick_rate  175362515
>>>> # Simulator tick rate (ticks/s)
>>>> host_mem_usage1628608
>>>> # Number of bytes of host memory used
>>>> host_seconds   548.53
>>>> # Real time elapsed on the host
>>>> sim_insts96108256
>>>> # Number of instructions simulated
>>>> sim_ops 185628785
>>>> # Number of ops (including micro ops) simulated
>>>> system.voltage_domain.voltage   1
>>>> # Voltage in Volts
>>>> system.clk_domain.clock  1000
>>>> # Clock period in ticks
>>>>
>>>> Maybe something in the attached file explains it better than I can
>>>> express.
>>>>
>>>> Many thanks for your help and hard work!
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jun 11, 2020 at 3:32 AM Kyle Roarty  wrote:
>>>>
>>>> Running through a few applications, it took me about 2.5 minutes or
>>>> less each time using docker to start executing the program on an r5 3600.
>>>>
>>>> I ran square, dynamic_shared, and MatrixTranspose (All from HIP) which
>>>> took about 1-1.5 mins.
>>>>
>>>> I ran conv_bench and rnn_bench from DeepBench which took just about 2
>>>> minutes.
>>>>
>>>> Because of that, it's possible the size of the app has an effect on
>>>> setup time, as the HIP apps are extremely small.
>>>>
>>>> Also, the commit Dan is checked out on is d0945dc
>>>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>
>>>>  mem-ruby:
>>>> add cache hit/miss statistics for TCP and TCC
>>>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>,
>>>> which isn't the most recent commit. I don't believe that that would account
>>>> for such a large slowdown, but it doesn't hurt to try the newest commit
>>>> unless it breaks something.
>>>>
>>>> Kyle
>>>> --
>>>> *From:* mattdsincl...@gmail.com 
>>>> *Sent:* Thursday, June 11, 2020 1:15 AM
>>>> *To:* gem5 users mailing list 
>>>> *Cc:* Daniel Gerzhoy ; GAURAV JAIN <
>>>> gja...@wisc.edu>; Kyle Roarty 
>>>> *Subject:* Re: [gem5-users] GCN3 GPU Simulation Start-Up Time
>>>>
>>>> Gaurav & Kyle, do you know if this is the case?
>>>>
>>>> Dan, I believe the short answer is yes although 7-8 minutes seems a
>>>> little long.  Are you running this in Kyle's Docker, or separately?  If in
>>>> the Docker, that does increase the overhead somewhat, so running it
>>>> directly on a system would likely reduce the overhead somewhat.  Also, are
>>>> you running with the release or debug version of the ROCm drivers?  Again,
>>>> debug version will likely add some time to this.
>>>>
>>>> Matt
>>>>
>>>> On Wed, Jun 10, 2020 at 2:00 PM Daniel Gerzhoy via gem5-users <
>>>> gem5-users@gem5.org> wrote:
>>>>
>>>> I've been running simulations using the GCN3 branch:
>>>>
>>>> rocm_ver=1.6.2
>>>> $git branch
>>>>* (HEAD detached at d0945dc)
>>>>   agutierr/master-gcn3-staging
>>>>
>>>> And I've noticed that it takes roughly 7-8 minutes to get to main()
>>>>
>>>> I'm guessing that this is the simulator setting up drivers?
>>>> Is that correct? Is there other stuff going on?
>>>>
>>>> *Has anyone found a way to speed this up? *
>>>>
>>>> I am trying to get some of the rodinia benchmarks from the HIP-Examples
>>>> running and debugging takes a long time as a result.
>>>>
>>>> I suspect that this is unavoidable but I won't know if I don't ask!
>>>>
>>>> Cheers,
>>>>
>>>> Dan Gerzhoy
>>>> ___
>>>> 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 GPU Simulation Start-Up Time

[Daniel Gerzhoy via gem5-users]

om checkpoints
>> and never reset)
>> sim_freq 1
>> # Frequency of simulated ticks
>> host_inst_rate 175209
>>   # Simulator instruction rate (inst/s)
>> host_op_rate   338409
>>   # Simulator op (including micro ops) rate (op/s)
>> host_tick_rate  175362515
>>   # Simulator tick rate (ticks/s)
>> host_mem_usage1628608
>>   # Number of bytes of host memory used
>> host_seconds   548.53
>>   # Real time elapsed on the host
>> sim_insts96108256
>>   # Number of instructions simulated
>> sim_ops 185628785
>>   # Number of ops (including micro ops) simulated
>> system.voltage_domain.voltage   1
>>   # Voltage in Volts
>> system.clk_domain.clock  1000
>>   # Clock period in ticks
>>
>> Maybe something in the attached file explains it better than I can
>> express.
>>
>> Many thanks for your help and hard work!
>>
>> Dan
>>
>>
>>
>>
>>
>> On Thu, Jun 11, 2020 at 3:32 AM Kyle Roarty  wrote:
>>
>> Running through a few applications, it took me about 2.5 minutes or less
>> each time using docker to start executing the program on an r5 3600.
>>
>> I ran square, dynamic_shared, and MatrixTranspose (All from HIP) which
>> took about 1-1.5 mins.
>>
>> I ran conv_bench and rnn_bench from DeepBench which took just about 2
>> minutes.
>>
>> Because of that, it's possible the size of the app has an effect on setup
>> time, as the HIP apps are extremely small.
>>
>> Also, the commit Dan is checked out on is d0945dc
>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>
>>  mem-ruby:
>> add cache hit/miss statistics for TCP and TCC
>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>,
>> which isn't the most recent commit. I don't believe that that would account
>> for such a large slowdown, but it doesn't hurt to try the newest commit
>> unless it breaks something.
>>
>> Kyle
>> --
>> *From:* mattdsincl...@gmail.com 
>> *Sent:* Thursday, June 11, 2020 1:15 AM
>> *To:* gem5 users mailing list 
>> *Cc:* Daniel Gerzhoy ; GAURAV JAIN <
>> gja...@wisc.edu>; Kyle Roarty 
>> *Subject:* Re: [gem5-users] GCN3 GPU Simulation Start-Up Time
>>
>> Gaurav & Kyle, do you know if this is the case?
>>
>> Dan, I believe the short answer is yes although 7-8 minutes seems a
>> little long.  Are you running this in Kyle's Docker, or separately?  If in
>> the Docker, that does increase the overhead somewhat, so running it
>> directly on a system would likely reduce the overhead somewhat.  Also, are
>> you running with the release or debug version of the ROCm drivers?  Again,
>> debug version will likely add some time to this.
>>
>> Matt
>>
>> On Wed, Jun 10, 2020 at 2:00 PM Daniel Gerzhoy via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>> I've been running simulations using the GCN3 branch:
>>
>> rocm_ver=1.6.2
>> $git branch
>>* (HEAD detached at d0945dc)
>>   agutierr/master-gcn3-staging
>>
>> And I've noticed that it takes roughly 7-8 minutes to get to main()
>>
>> I'm guessing that this is the simulator setting up drivers?
>> Is that correct? Is there other stuff going on?
>>
>> *Has anyone found a way to speed this up? *
>>
>> I am trying to get some of the rodinia benchmarks from the HIP-Examples
>> running and debugging takes a long time as a result.
>>
>> I suspect that this is unavoidable but I won't know if I don't ask!
>>
>> Cheers,
>>
>> Dan Gerzhoy
>> ___
>> 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 GPU Simulation Start-Up Time

[Daniel Gerzhoy via gem5-users]

;>> I ran a benchmark that prints that it entered main and returns
>>> immediately, this took 9 minutes.
>>> I've attached a debug trace with debug flags =
>>> "GPUDriver,SyscallVerbose"
>>> There's a lot of weird things going on, "syscall open: failed", "syscall
>>> brk: break point changed to [...]", and lots of ignored system calls.
>>>
>>> head of Stats for reference:
>>> -- Begin Simulation Statistics --
>>> sim_seconds  0.096192
>>> # Number of seconds simulated
>>> sim_ticks 96192368500
>>> # Number of ticks simulated
>>> final_tick96192368500
>>> # Number of ticks from beginning of simulation (restored from
>>> checkpoints and never reset)
>>> sim_freq 1
>>> # Frequency of simulated ticks
>>> host_inst_rate 175209
>>> # Simulator instruction rate (inst/s)
>>> host_op_rate   338409
>>> # Simulator op (including micro ops) rate (op/s)
>>> host_tick_rate  175362515
>>> # Simulator tick rate (ticks/s)
>>> host_mem_usage1628608
>>> # Number of bytes of host memory used
>>> host_seconds   548.53
>>> # Real time elapsed on the host
>>> sim_insts96108256
>>> # Number of instructions simulated
>>> sim_ops 185628785
>>> # Number of ops (including micro ops) simulated
>>> system.voltage_domain.voltage   1
>>> # Voltage in Volts
>>> system.clk_domain.clock  1000
>>> # Clock period in ticks
>>>
>>> Maybe something in the attached file explains it better than I can
>>> express.
>>>
>>> Many thanks for your help and hard work!
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 11, 2020 at 3:32 AM Kyle Roarty  wrote:
>>>
>>> Running through a few applications, it took me about 2.5 minutes or less
>>> each time using docker to start executing the program on an r5 3600.
>>>
>>> I ran square, dynamic_shared, and MatrixTranspose (All from HIP) which
>>> took about 1-1.5 mins.
>>>
>>> I ran conv_bench and rnn_bench from DeepBench which took just about 2
>>> minutes.
>>>
>>> Because of that, it's possible the size of the app has an effect on
>>> setup time, as the HIP apps are extremely small.
>>>
>>> Also, the commit Dan is checked out on is d0945dc
>>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>
>>>  mem-ruby:
>>> add cache hit/miss statistics for TCP and TCC
>>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>,
>>> which isn't the most recent commit. I don't believe that that would account
>>> for such a large slowdown, but it doesn't hurt to try the newest commit
>>> unless it breaks something.
>>>
>>> Kyle
>>> --
>>> *From:* mattdsincl...@gmail.com 
>>> *Sent:* Thursday, June 11, 2020 1:15 AM
>>> *To:* gem5 users mailing list 
>>> *Cc:* Daniel Gerzhoy ; GAURAV JAIN <
>>> gja...@wisc.edu>; Kyle Roarty 
>>> *Subject:* Re: [gem5-users] GCN3 GPU Simulation Start-Up Time
>>>
>>> Gaurav & Kyle, do you know if this is the case?
>>>
>>> Dan, I believe the short answer is yes although 7-8 minutes seems a
>>> little long.  Are you running this in Kyle's Docker, or separately?  If in
>>> the Docker, that does increase the overhead somewhat, so running it
>>> directly on a system would likely reduce the overhead somewhat.  Also, are
>>> you running with the release or debug version of the ROCm drivers?  Again,
>>> debug version will likely add some time to this.
>>>
>>> Matt
>>>
>>> On Wed, Jun 10, 2020 at 2:00 PM Daniel Gerzhoy via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>> I've been running simulations using the GCN3 branch:
>>>
>>> rocm_ver=1.6.2
>>> $git branch
>>>* (HEAD detached at d0945dc)
>>>   agutierr/master-gcn3-staging
>>>
>>> And I've noticed that it takes roughly 7-8 minutes to get to main()
>>>
>>> I'm guessing that this is the simulator setting up drivers?
>>> Is that correct? Is there other stuff going on?
>>>
>>> *Has anyone found a way to speed this up? *
>>>
>>> I am trying to get some of the rodinia benchmarks from the HIP-Examples
>>> running and debugging takes a long time as a result.
>>>
>>> I suspect that this is unavoidable but I won't know if I don't ask!
>>>
>>> Cheers,
>>>
>>> Dan Gerzhoy
>>> ___
>>> 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 GPU Simulation Start-Up Time

[Daniel Gerzhoy via gem5-users]

 with those patches.
>
> Yes, looks like you are using the release version of ROCm -- no issues
> there.
>
> Matt
>
>
>
> On Thu, Jun 11, 2020 at 9:38 AM Daniel Gerzhoy 
> wrote:
>
> I am using the docker, yeah.
> It's running on our server cluster which is a Xeon Gold 5117 @ (2.0 - 2.8
> GHz) which might make up some of the difference, the r5 3600 has a faster
> clock (3.6-4.2 GHz).
>
> I've hesitated to update my branch because in the Dockerfile it
> specifically checks this branch out and applies a patch, though the patch
> isn't very extensive.
> This was from a while back (November maybe?) and I know you guys have been
> integrating things into the main branch (thanks!)
> I was thinking I would wait until it's fully merged into the mainline gem5
> branch and rebase onto that and try to merge my changes in.
>
> Last I checked the GCN3 stuff is in the dev branch not the master right?
>
> But if it will help maybe I should update to the head of this branch. Will
> I need to update the docker as well?
>
> As for the debug vs release rocm I think I'm using the release version.
> This is what the dockerfile built:
>
> ARG rocm_ver=1.6.2
> RUN wget -qO- repo.radeon.com/rocm/archive/apt_${rocm_ver}.tar.bz2
> <http://repo.radeon.com/rocm/archive/apt_$%7Brocm_ver%7D.tar.bz2> \
> | tar -xjv \
> && cd apt_${rocm_ver}/pool/main/ \
> && dpkg -i h/hsakmt-roct-dev/* \
> && dpkg -i h/hsa-ext-rocr-dev/* \
> && dpkg -i h/hsa-rocr-dev/* \
> && dpkg -i r/rocm-utils/* \
> && dpkg -i h/hcc/* \
> && dpkg -i h/hip_base/* \
> && dpkg -i h/hip_hcc/* \
> && dpkg -i h/hip_samples/*
>
>
> I ran a benchmark that prints that it entered main and returns
> immediately, this took 9 minutes.
> I've attached a debug trace with debug flags = "GPUDriver,SyscallVerbose"
> There's a lot of weird things going on, "syscall open: failed", "syscall
> brk: break point changed to [...]", and lots of ignored system calls.
>
> head of Stats for reference:
> -- Begin Simulation Statistics --
> sim_seconds  0.096192
>   # Number of seconds simulated
> sim_ticks 96192368500
>   # Number of ticks simulated
> final_tick96192368500
>   # Number of ticks from beginning of simulation (restored from checkpoints
> and never reset)
> sim_freq 1
>   # Frequency of simulated ticks
> host_inst_rate 175209
>   # Simulator instruction rate (inst/s)
> host_op_rate   338409
>   # Simulator op (including micro ops) rate (op/s)
> host_tick_rate  175362515
>   # Simulator tick rate (ticks/s)
> host_mem_usage1628608
>   # Number of bytes of host memory used
> host_seconds   548.53
>   # Real time elapsed on the host
> sim_insts96108256
>   # Number of instructions simulated
> sim_ops 185628785
>   # Number of ops (including micro ops) simulated
> system.voltage_domain.voltage   1
>   # Voltage in Volts
> system.clk_domain.clock  1000
>   # Clock period in ticks
>
> Maybe something in the attached file explains it better than I can express.
>
> Many thanks for your help and hard work!
>
> Dan
>
>
>
>
>
> On Thu, Jun 11, 2020 at 3:32 AM Kyle Roarty  wrote:
>
> Running through a few applications, it took me about 2.5 minutes or less
> each time using docker to start executing the program on an r5 3600.
>
> I ran square, dynamic_shared, and MatrixTranspose (All from HIP) which
> took about 1-1.5 mins.
>
> I ran conv_bench and rnn_bench from DeepBench which took just about 2
> minutes.
>
> Because of that, it's possible the size of the app has an effect on setup
> time, as the HIP apps are extremely small.
>
> Also, the commit Dan is checked out on is d0945dc
> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>
>  mem-ruby:
> add cache hit/miss statistics for TCP and TCC
> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>,
> which isn't the most recent commit. I don't believe that that would account
> for such a large slowdown, but it doesn't hurt to try the newest commit
> unless it breaks something.
>
> Kyle
> --------------
> *From:* mattdsincl...@gmail.com 
> *

[gem5-users] Re: GCN3 GPU Simulation Start-Up Time

[Daniel Gerzhoy via gem5-users]

   338409
>>   # Simulator op (including micro ops) rate (op/s)
>> host_tick_rate  175362515
>>   # Simulator tick rate (ticks/s)
>> host_mem_usage1628608
>>   # Number of bytes of host memory used
>> host_seconds   548.53
>>   # Real time elapsed on the host
>> sim_insts96108256
>>   # Number of instructions simulated
>> sim_ops 185628785
>>   # Number of ops (including micro ops) simulated
>> system.voltage_domain.voltage   1
>>   # Voltage in Volts
>> system.clk_domain.clock  1000
>>   # Clock period in ticks
>>
>> Maybe something in the attached file explains it better than I can
>> express.
>>
>> Many thanks for your help and hard work!
>>
>> Dan
>>
>>
>>
>>
>>
>> On Thu, Jun 11, 2020 at 3:32 AM Kyle Roarty  wrote:
>>
>>> Running through a few applications, it took me about 2.5 minutes or less
>>> each time using docker to start executing the program on an r5 3600.
>>>
>>> I ran square, dynamic_shared, and MatrixTranspose (All from HIP) which
>>> took about 1-1.5 mins.
>>>
>>> I ran conv_bench and rnn_bench from DeepBench which took just about 2
>>> minutes.
>>>
>>> Because of that, it's possible the size of the app has an effect on
>>> setup time, as the HIP apps are extremely small.
>>>
>>> Also, the commit Dan is checked out on is d0945dc
>>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>
>>>  mem-ruby:
>>> add cache hit/miss statistics for TCP and TCC
>>> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>,
>>> which isn't the most recent commit. I don't believe that that would account
>>> for such a large slowdown, but it doesn't hurt to try the newest commit
>>> unless it breaks something.
>>>
>>> Kyle
>>> --
>>> *From:* mattdsincl...@gmail.com 
>>> *Sent:* Thursday, June 11, 2020 1:15 AM
>>> *To:* gem5 users mailing list 
>>> *Cc:* Daniel Gerzhoy ; GAURAV JAIN <
>>> gja...@wisc.edu>; Kyle Roarty 
>>> *Subject:* Re: [gem5-users] GCN3 GPU Simulation Start-Up Time
>>>
>>> Gaurav & Kyle, do you know if this is the case?
>>>
>>> Dan, I believe the short answer is yes although 7-8 minutes seems a
>>> little long.  Are you running this in Kyle's Docker, or separately?  If in
>>> the Docker, that does increase the overhead somewhat, so running it
>>> directly on a system would likely reduce the overhead somewhat.  Also, are
>>> you running with the release or debug version of the ROCm drivers?  Again,
>>> debug version will likely add some time to this.
>>>
>>> Matt
>>>
>>> On Wed, Jun 10, 2020 at 2:00 PM Daniel Gerzhoy via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
>>> I've been running simulations using the GCN3 branch:
>>>
>>> rocm_ver=1.6.2
>>> $git branch
>>>* (HEAD detached at d0945dc)
>>>   agutierr/master-gcn3-staging
>>>
>>> And I've noticed that it takes roughly 7-8 minutes to get to main()
>>>
>>> I'm guessing that this is the simulator setting up drivers?
>>> Is that correct? Is there other stuff going on?
>>>
>>> *Has anyone found a way to speed this up? *
>>>
>>> I am trying to get some of the rodinia benchmarks from the HIP-Examples
>>> running and debugging takes a long time as a result.
>>>
>>> I suspect that this is unavoidable but I won't know if I don't ask!
>>>
>>> Cheers,
>>>
>>> Dan Gerzhoy
>>> ___
>>> 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 GPU Simulation Start-Up Time

[Daniel Gerzhoy via gem5-users]

I am using the docker, yeah.
It's running on our server cluster which is a Xeon Gold 5117 @ (2.0 - 2.8
GHz) which might make up some of the difference, the r5 3600 has a faster
clock (3.6-4.2 GHz).

I've hesitated to update my branch because in the Dockerfile it
specifically checks this branch out and applies a patch, though the patch
isn't very extensive.
This was from a while back (November maybe?) and I know you guys have been
integrating things into the main branch (thanks!)
I was thinking I would wait until it's fully merged into the mainline gem5
branch and rebase onto that and try to merge my changes in.

Last I checked the GCN3 stuff is in the dev branch not the master right?

But if it will help maybe I should update to the head of this branch. Will
I need to update the docker as well?

As for the debug vs release rocm I think I'm using the release version.
This is what the dockerfile built:

ARG rocm_ver=1.6.2
RUN wget -qO- repo.radeon.com/rocm/archive/apt_${rocm_ver}.tar.bz2 \
| tar -xjv \
&& cd apt_${rocm_ver}/pool/main/ \
&& dpkg -i h/hsakmt-roct-dev/* \
&& dpkg -i h/hsa-ext-rocr-dev/* \
&& dpkg -i h/hsa-rocr-dev/* \
&& dpkg -i r/rocm-utils/* \
&& dpkg -i h/hcc/* \
&& dpkg -i h/hip_base/* \
&& dpkg -i h/hip_hcc/* \
&& dpkg -i h/hip_samples/*


I ran a benchmark that prints that it entered main and returns immediately,
this took 9 minutes.
I've attached a debug trace with debug flags = "GPUDriver,SyscallVerbose"
There's a lot of weird things going on, "syscall open: failed", "syscall
brk: break point changed to [...]", and lots of ignored system calls.

head of Stats for reference:
-- Begin Simulation Statistics --
sim_seconds  0.096192
# Number of seconds simulated
sim_ticks 96192368500
# Number of ticks simulated
final_tick96192368500
# Number of ticks from beginning of simulation (restored from checkpoints
and never reset)
sim_freq 1
  # Frequency of simulated ticks
host_inst_rate 175209
# Simulator instruction rate (inst/s)
host_op_rate   338409
# Simulator op (including micro ops) rate (op/s)
host_tick_rate  175362515
# Simulator tick rate (ticks/s)
host_mem_usage1628608
# Number of bytes of host memory used
host_seconds   548.53
# Real time elapsed on the host
sim_insts96108256
# Number of instructions simulated
sim_ops 185628785
# Number of ops (including micro ops) simulated
system.voltage_domain.voltage   1
# Voltage in Volts
system.clk_domain.clock  1000
# Clock period in ticks

Maybe something in the attached file explains it better than I can express.

Many thanks for your help and hard work!

Dan





On Thu, Jun 11, 2020 at 3:32 AM Kyle Roarty  wrote:

> Running through a few applications, it took me about 2.5 minutes or less
> each time using docker to start executing the program on an r5 3600.
>
> I ran square, dynamic_shared, and MatrixTranspose (All from HIP) which
> took about 1-1.5 mins.
>
> I ran conv_bench and rnn_bench from DeepBench which took just about 2
> minutes.
>
> Because of that, it's possible the size of the app has an effect on setup
> time, as the HIP apps are extremely small.
>
> Also, the commit Dan is checked out on is d0945dc
> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>
>  mem-ruby:
> add cache hit/miss statistics for TCP and TCC
> <https://gem5.googlesource.com/amd/gem5/+/d0945dc285cf146de160808d7e6d4c1fd3f73639>,
> which isn't the most recent commit. I don't believe that that would account
> for such a large slowdown, but it doesn't hurt to try the newest commit
> unless it breaks something.
>
> Kyle
> --
> *From:* mattdsincl...@gmail.com 
> *Sent:* Thursday, June 11, 2020 1:15 AM
> *To:* gem5 users mailing list 
> *Cc:* Daniel Gerzhoy ; GAURAV JAIN <
> gja...@wisc.edu>; Kyle Roarty 
> *Subject:* Re: [gem5-users] GCN3 GPU Simulation Start-Up Time
>
> Gaurav & Kyle, do you know if this is the case?
>
> Dan, I believe the short answer is yes although 7-8 minutes seems a little
> long.  Are you running this in Kyle's Docker, or separately?  If in the
> Docker, that does increase the overhead somewhat, so running it directly on
> a system would likely reduce the overhead somewhat.  Also, are you running
> with the release or debug version of the ROCm drivers?  Again, debug
> version will l

[gem5-users] Re: std::thread can not use in SE mode?

[Daniel Gerzhoy via gem5-users]

It should be able to run std::thread.

Make sure you have enough cores set in the simulation command. (E.g. -n 4)

Cheers,
Dan

On Fri, Jun 5, 2020 at 12:50 AM Taiyu Zhou via gem5-users <
gem5-users@gem5.org> wrote:

> Hi guys!
> I am trying to run a Muti-thread program in SE mode. But It can’t work in
> SE mode. It is gem5 se mode can’t support std::thread?
> My program is simple:
> "
> void th(){
> printf("thread\n");
>
> }
>
> int main(){
> std::thread t1(th);
> std::thread t2(th);
> t1.join();t2.join();
> printf("end\n");
> return 0;
> }
> “
>
>And gem5 will report that
> “
> terminate called after throwing an instance of 'std::system_error'
>   what():  Resource temporarily unavailable
> “
>
> Are there any method to solve this problem?
> Thanks
> ___
> 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