[gem5-users] Re: Modifying simulation structure after instantiation/checkpoint restore

2022-04-12 Thread Antoine Kaufmann via gem5-users
Thanks for the quick response Sam!

Yeah I saw that that also seems to be how the CPU swapping is implemented, and
for switching out a few objects this seems like the easiest way to get this to
work.

But my use case is a bit messy and I want to make larger structural changes. So
I am wondering if this is something that is doable in principle within the
object/config model, or if I need to figure out some workaround.


For a bit more context: we're trying to partition one larger multi-core
simulation configuration into multiple smaller parts that we connect together
(and synchronize) at the memory ports going across configurations. We have the
interconnections and synchronization working for SE configs where we manually
configure each partition, but I'm trying to figure out the simplest way of doing
this for full-system, where the initialization in the workload etc. really needs
the global view of all thread contexts etc. so I was hoping we could just create
it and initialize it in one process, and then checkpoint, and then restore the
checkpoint for each partition but delete the unneeded objects and add in the
"proxy objects" connecting partitions. If that does not work the initialization
gets a fair bit more complex, which I would like to avoid if possible.

So if anyone has any pointers to indicate that making such changes to the
simulation structure are generally possible or impossible that would be very
useful before we get too deep down into the weeds. :-)

Thanks
Antoine

On Tue, Apr 12 15:49, Thomas, Samuel via gem5-users wrote:
> Hi Antoine,
> 
> We had a similar use case in our work. Our solution was to include all of
> the objects that we wanted to in the system and implement them so that they
> forward all packets in the mode that you don't care about. For us, we
> wanted to include an object that we didn't want to do anything during
> fast-forward mode, so our implementation of its port functions that handle
> atomic requests merely sends the packets along without doing any
> processing. In theory, you could do the same with timing packets if you
> don't want the object to be in the system during an atomic mode
> fast-forward but not in the system for timing mode.
> 
> I hope this helps!
> 
> Best,
> Sam
> 
> On Tue, Apr 12, 2022 at 3:43 PM Antoine Kaufmann via gem5-users <
> gem5-users@gem5.org> wrote:
> 
> > Hi everyone,
> >
> > I have a quick conceptual question about gem5 configuration: are there
> > restrictions about what can be modified in an already instantiated and
> > initialized gem5 config, say after restoring from a checkpoint. I know
> > there is
> > some special cases such as replacing CPUs on restore. Is this something
> > that
> > gem5 supports more generally, e.g. swapping out, adding,
> > connecting/disconnecting, or removing SimObjects in a simulation? Or is
> > making
> > changes to the simulation structure generally a problem?
> >
> > The use-case I'm looking at is similar to the CPU swapping, but wih other
> > objects as well, basically boot system with a fast config, and then swap
> > out
> > other things too for more detailed versions. (setting up logical state for
> > the
> > replacement simobjects is something I have in hand, so I'm only wondering
> > about
> > whether gem5 will be unhappy if I attempt to make such structural changes
> > to a
> > simulation).
> >
> > Thanks in advance,
> > Antoine
> >
> > --
> > Antoine Kaufmann
> > 
> > ___
> > 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


-- 
Antoine Kaufmann



signature.asc
Description: PGP signature
___
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: How to set the Cache replacement policy

2022-04-12 Thread Jason Lowe-Power via gem5-users
Hi Ankit,

I would suggest modifying your python runscript instead of using command
line parameters.
https://www.gem5.org/documentation/learning_gem5/introduction/ may help
explain how to set parameters on SimObjects.

Cheers,
Jason

On Wed, Apr 6, 2022 at 2:48 PM Ankit Berde  wrote:

> Hi Gem5 Team,
>
> Could you please guide us on how to set the replacement policy to a
> certain value. We are trying to simulate Cache Replacement policies, and
> whichever argument we provide as "--repl_policy==FIFORP()", it by default
> calls LRURP.
>
> Could you please help us on this
>
> Thanks,
> Ankit
>
___
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] finding tag of address in cache in ruby model

2022-04-12 Thread Varun Venkitaraman via gem5-users
Hi all,

I am using ruby model. I am struggling to know whether the deallocate
function in cachememory.cc in ruby folder is taking entire physical address
as input argument or just the tag?

If that address in input argument to function deallocate is full physical
address then how do we find the tag portion of the address?

Please suggest me a way out of this issue.

-- 
With Regards,
Varun Venkitaraman.
___
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: Modifying simulation structure after instantiation/checkpoint restore

2022-04-12 Thread Thomas, Samuel via gem5-users
Hi Antoine,

We had a similar use case in our work. Our solution was to include all of
the objects that we wanted to in the system and implement them so that they
forward all packets in the mode that you don't care about. For us, we
wanted to include an object that we didn't want to do anything during
fast-forward mode, so our implementation of its port functions that handle
atomic requests merely sends the packets along without doing any
processing. In theory, you could do the same with timing packets if you
don't want the object to be in the system during an atomic mode
fast-forward but not in the system for timing mode.

I hope this helps!

Best,
Sam

On Tue, Apr 12, 2022 at 3:43 PM Antoine Kaufmann via gem5-users <
gem5-users@gem5.org> wrote:

> Hi everyone,
>
> I have a quick conceptual question about gem5 configuration: are there
> restrictions about what can be modified in an already instantiated and
> initialized gem5 config, say after restoring from a checkpoint. I know
> there is
> some special cases such as replacing CPUs on restore. Is this something
> that
> gem5 supports more generally, e.g. swapping out, adding,
> connecting/disconnecting, or removing SimObjects in a simulation? Or is
> making
> changes to the simulation structure generally a problem?
>
> The use-case I'm looking at is similar to the CPU swapping, but wih other
> objects as well, basically boot system with a fast config, and then swap
> out
> other things too for more detailed versions. (setting up logical state for
> the
> replacement simobjects is something I have in hand, so I'm only wondering
> about
> whether gem5 will be unhappy if I attempt to make such structural changes
> to a
> simulation).
>
> Thanks in advance,
> Antoine
>
> --
> Antoine Kaufmann
> 
> ___
> 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] Modifying simulation structure after instantiation/checkpoint restore

2022-04-12 Thread Antoine Kaufmann via gem5-users
Hi everyone,

I have a quick conceptual question about gem5 configuration: are there
restrictions about what can be modified in an already instantiated and
initialized gem5 config, say after restoring from a checkpoint. I know there is
some special cases such as replacing CPUs on restore. Is this something that
gem5 supports more generally, e.g. swapping out, adding,
connecting/disconnecting, or removing SimObjects in a simulation? Or is making
changes to the simulation structure generally a problem?

The use-case I'm looking at is similar to the CPU swapping, but wih other
objects as well, basically boot system with a fast config, and then swap out
other things too for more detailed versions. (setting up logical state for the
replacement simobjects is something I have in hand, so I'm only wondering about
whether gem5 will be unhappy if I attempt to make such structural changes to a
simulation).

Thanks in advance,
Antoine

-- 
Antoine Kaufmann



signature.asc
Description: PGP signature
___
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: Error when running test_bwd_bn test

2022-04-12 Thread David Fong via gem5-users
Hi Matt S,

Here's the info you requested.

Linux
uname -a
Linux xconfidentialx.com 3.10.0-1160.62.1.el7.x86_64 #1 SMP Tue Apr 5 
16:57:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

HIP_PLATFORM
Found this below.  Is it used by docker ?
gem5/util/dockerfiles/gcn-gpu/Dockerfile:-DHIP_COMPILER=clang 
-DHIP_PLATFORM=rocclr -DCMAKE_PREFIX_PATH="/opt/rocm"\

David

From: Matt Sinclair 
Sent: Tuesday, April 12, 2022 10:11 AM
To: David Fong ; gem5 users mailing list 
; Kyle Roarty 
Cc: Poremba, Matthew 
Subject: RE: Error when running test_bwd_bn test

In general, yes, MIOpen is less optimized for APUs.  I do not recall seeing 
this before for bwd_bn though.  @Kyle Roarty: have you 
seen this?  I'm wondering if something is missing with how we set HIP_PLATFORM 
in the docker?

I did some quick digging and it appears to be coming from here: 
https://github.com/ROCmSoftwarePlatform/MIOpen/blob/rocm-4.0.x/src/ocl/gcn_asm_utils.cpp#L144

David, what OS are you running this on?  In theory since you're using the 
docker, I wouldn't expect it to matter, but unless Kyle is also seeing this, 
that print appears to be happening when MIOpen doesn't think you are running on 
Linux.  Or that somewhere in your setup you set the compiler to something other 
than HCC/clang/rocclr?  What is HIP_PLATFORM set to in your setup?

Matt

From: David Fong mailto:da...@chronostech.com>>
Sent: Tuesday, April 12, 2022 10:53 AM
To: Matt Sinclair mailto:sincl...@cs.wisc.edu>>; gem5 
users mailing list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Poremba, Matthew 
mailto:matthew.pore...@amd.com>>
Subject: RE: Error when running test_bwd_bn test

Hi Matt S,

I'm using gfx801.
It proceeds and does not error out.
So it just means it's less optimized running with the APU.
I don't get this message for my other 3 tests (test_fwd_softmax, 
test_bwd_softmax, test_fwd_pool), only for test_bwd_bn.
I guess there's some special  function used in test_bwd_bn that is better 
optimized in GPU.

David



From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Monday, April 11, 2022 6:00 PM
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: David Fong mailto:da...@chronostech.com>>; Kyle 
Roarty mailto:kroa...@wisc.edu>>; Poremba, Matthew 
mailto:matthew.pore...@amd.com>>
Subject: RE: Error when running test_bwd_bn test

Hi David,

My guess is you are using gfx801 for this?  If so, does the application 
actually error out at this point, or just proceed beyond it?  If it's the 
latter, my guess is MIOpen is just complaining that you're running with an APU, 
which is less well optimized for.  If it's the former, then there may be 
something else in your setup we need to check.

Matt

From: David Fong via gem5-users 
mailto:gem5-users@gem5.org>>
Sent: Monday, April 11, 2022 1:29 PM
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: David Fong mailto:da...@chronostech.com>>
Subject: [gem5-users] Error when running test_bwd_bn test

Hi,

When I run the DNNMark test_bwd_bn,

docker run --rm -v ${PWD}:${PWD} -v 
${PWD}/gem5/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0 
-w ${PWD} gcr.io/gem5-test/gcn-gpu:v21-2 gem5/build/GCN3_X86/gem5.opt 
gem5/configs/example/apu_se.py --num-compute-units 128 -n3 --gpu-to-dir-latency 
120 --TCC_latency 16 
--benchmark-root=gem5/gem5-resources/src/gpu/DNNMark/build/benchmarks/test_bwd_bn
 -c dnnmark_test_bwd_bn --options="-config 
gem5/gem5-resources/src/gpu/DNNMark/config_example/bn_config.dnnmark -mmap 
gem5/gem5-resources/src/gpu/DNNMark/mmap.bin"

I get this error:

MIOpen(HIP): Error [ValidateGcnAssemblerImpl] Specified assembler does not 
support AMDGPU. Expect performance degradation.

Does this mean the test will not run properly with AMD GPU and I should ignore 
this test?
Or the AMD CPU will be doing the computations and it means the test will take 
longer to complete?

David

Log for lines before and after the error.
build/GCN3_X86/arch/generic/debugfaults.hh:145: warn: MOVNTDQ: Ignoring 
non-temporal hint, modeling as cacheable!
build/GCN3_X86/arch/x86/generated/exec-ns.cc.inc:27: warn: instruction 
'frndint' unimplemented
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:704: warn: unimplemented 
ioctl: AMDKFD_IOC_ACQUIRE_VM
build/GCN3_X86/sim/syscall_emul.hh:1862: warn: mmap: writing to shared mmap 
region is currently unsupported. The write succeeds on the target, but it will 
not be propagated to the host or shared mappings

[gem5-users] Re: Error when running test_bwd_bn test

2022-04-12 Thread Matt Sinclair via gem5-users
In general, yes, MIOpen is less optimized for APUs.  I do not recall seeing 
this before for bwd_bn though.  @Kyle Roarty: have you 
seen this?  I'm wondering if something is missing with how we set HIP_PLATFORM 
in the docker?

I did some quick digging and it appears to be coming from here: 
https://github.com/ROCmSoftwarePlatform/MIOpen/blob/rocm-4.0.x/src/ocl/gcn_asm_utils.cpp#L144

David, what OS are you running this on?  In theory since you're using the 
docker, I wouldn't expect it to matter, but unless Kyle is also seeing this, 
that print appears to be happening when MIOpen doesn't think you are running on 
Linux.  Or that somewhere in your setup you set the compiler to something other 
than HCC/clang/rocclr?  What is HIP_PLATFORM set to in your setup?

Matt

From: David Fong 
Sent: Tuesday, April 12, 2022 10:53 AM
To: Matt Sinclair ; gem5 users mailing list 

Cc: Kyle Roarty ; Poremba, Matthew 
Subject: RE: Error when running test_bwd_bn test

Hi Matt S,

I'm using gfx801.
It proceeds and does not error out.
So it just means it's less optimized running with the APU.
I don't get this message for my other 3 tests (test_fwd_softmax, 
test_bwd_softmax, test_fwd_pool), only for test_bwd_bn.
I guess there's some special  function used in test_bwd_bn that is better 
optimized in GPU.

David



From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Monday, April 11, 2022 6:00 PM
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: David Fong mailto:da...@chronostech.com>>; Kyle 
Roarty mailto:kroa...@wisc.edu>>; Poremba, Matthew 
mailto:matthew.pore...@amd.com>>
Subject: RE: Error when running test_bwd_bn test

Hi David,

My guess is you are using gfx801 for this?  If so, does the application 
actually error out at this point, or just proceed beyond it?  If it's the 
latter, my guess is MIOpen is just complaining that you're running with an APU, 
which is less well optimized for.  If it's the former, then there may be 
something else in your setup we need to check.

Matt

From: David Fong via gem5-users 
mailto:gem5-users@gem5.org>>
Sent: Monday, April 11, 2022 1:29 PM
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: David Fong mailto:da...@chronostech.com>>
Subject: [gem5-users] Error when running test_bwd_bn test

Hi,

When I run the DNNMark test_bwd_bn,

docker run --rm -v ${PWD}:${PWD} -v 
${PWD}/gem5/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0 
-w ${PWD} gcr.io/gem5-test/gcn-gpu:v21-2 gem5/build/GCN3_X86/gem5.opt 
gem5/configs/example/apu_se.py --num-compute-units 128 -n3 --gpu-to-dir-latency 
120 --TCC_latency 16 
--benchmark-root=gem5/gem5-resources/src/gpu/DNNMark/build/benchmarks/test_bwd_bn
 -c dnnmark_test_bwd_bn --options="-config 
gem5/gem5-resources/src/gpu/DNNMark/config_example/bn_config.dnnmark -mmap 
gem5/gem5-resources/src/gpu/DNNMark/mmap.bin"

I get this error:

MIOpen(HIP): Error [ValidateGcnAssemblerImpl] Specified assembler does not 
support AMDGPU. Expect performance degradation.

Does this mean the test will not run properly with AMD GPU and I should ignore 
this test?
Or the AMD CPU will be doing the computations and it means the test will take 
longer to complete?

David

Log for lines before and after the error.
build/GCN3_X86/arch/generic/debugfaults.hh:145: warn: MOVNTDQ: Ignoring 
non-temporal hint, modeling as cacheable!
build/GCN3_X86/arch/x86/generated/exec-ns.cc.inc:27: warn: instruction 
'frndint' unimplemented
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:704: warn: unimplemented 
ioctl: AMDKFD_IOC_ACQUIRE_VM
build/GCN3_X86/sim/syscall_emul.hh:1862: warn: mmap: writing to shared mmap 
region is currently unsupported. The write succeeds on the target, but it will 
not be propagated to the host or shared mappings
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:455: warn: Signal events are 
only supported currently
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/power_state.cc:105: warn: PowerState: Already in the 
requested power state, request ignored
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall 
set_robust_list(...)
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:599: warn: unimplemented 
ioctl: AMDKFD_IOC_SET_SCRATCH_BACKING_VA
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:609: warn: unimplemented 
ioctl: AMDKFD_IOC_SET_TRAP_HANDLER
build/GCN3_X86/sim/syscall_emul.hh:2081: warn: prlimit: unimplemented resource 7
build/GCN3_X86/sim/syscall_emul.hh:2081: warn: prlimit: unimplemented resource 7
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring 

[gem5-users] Re: Error when running test_bwd_bn test

2022-04-12 Thread David Fong via gem5-users
Hi Matt S,

I'm using gfx801.
It proceeds and does not error out.
So it just means it's less optimized running with the APU.
I don't get this message for my other 3 tests (test_fwd_softmax, 
test_bwd_softmax, test_fwd_pool), only for test_bwd_bn.
I guess there's some special  function used in test_bwd_bn that is better 
optimized in GPU.

David



From: Matt Sinclair 
Sent: Monday, April 11, 2022 6:00 PM
To: gem5 users mailing list 
Cc: David Fong ; Kyle Roarty ; 
Poremba, Matthew 
Subject: RE: Error when running test_bwd_bn test

Hi David,

My guess is you are using gfx801 for this?  If so, does the application 
actually error out at this point, or just proceed beyond it?  If it's the 
latter, my guess is MIOpen is just complaining that you're running with an APU, 
which is less well optimized for.  If it's the former, then there may be 
something else in your setup we need to check.

Matt

From: David Fong via gem5-users 
mailto:gem5-users@gem5.org>>
Sent: Monday, April 11, 2022 1:29 PM
To: gem5 users mailing list mailto:gem5-users@gem5.org>>
Cc: David Fong mailto:da...@chronostech.com>>
Subject: [gem5-users] Error when running test_bwd_bn test

Hi,

When I run the DNNMark test_bwd_bn,

docker run --rm -v ${PWD}:${PWD} -v 
${PWD}/gem5/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0 
-w ${PWD} gcr.io/gem5-test/gcn-gpu:v21-2 gem5/build/GCN3_X86/gem5.opt 
gem5/configs/example/apu_se.py --num-compute-units 128 -n3 --gpu-to-dir-latency 
120 --TCC_latency 16 
--benchmark-root=gem5/gem5-resources/src/gpu/DNNMark/build/benchmarks/test_bwd_bn
 -c dnnmark_test_bwd_bn --options="-config 
gem5/gem5-resources/src/gpu/DNNMark/config_example/bn_config.dnnmark -mmap 
gem5/gem5-resources/src/gpu/DNNMark/mmap.bin"

I get this error:

MIOpen(HIP): Error [ValidateGcnAssemblerImpl] Specified assembler does not 
support AMDGPU. Expect performance degradation.

Does this mean the test will not run properly with AMD GPU and I should ignore 
this test?
Or the AMD CPU will be doing the computations and it means the test will take 
longer to complete?

David

Log for lines before and after the error.
build/GCN3_X86/arch/generic/debugfaults.hh:145: warn: MOVNTDQ: Ignoring 
non-temporal hint, modeling as cacheable!
build/GCN3_X86/arch/x86/generated/exec-ns.cc.inc:27: warn: instruction 
'frndint' unimplemented
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:704: warn: unimplemented 
ioctl: AMDKFD_IOC_ACQUIRE_VM
build/GCN3_X86/sim/syscall_emul.hh:1862: warn: mmap: writing to shared mmap 
region is currently unsupported. The write succeeds on the target, but it will 
not be propagated to the host or shared mappings
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:455: warn: Signal events are 
only supported currently
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/power_state.cc:105: warn: PowerState: Already in the 
requested power state, request ignored
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall 
set_robust_list(...)
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:599: warn: unimplemented 
ioctl: AMDKFD_IOC_SET_SCRATCH_BACKING_VA
build/GCN3_X86/gpu-compute/gpu_compute_driver.cc:609: warn: unimplemented 
ioctl: AMDKFD_IOC_SET_TRAP_HANDLER
build/GCN3_X86/sim/syscall_emul.hh:2081: warn: prlimit: unimplemented resource 7
build/GCN3_X86/sim/syscall_emul.hh:2081: warn: prlimit: unimplemented resource 7
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
sh: 1: Cannot fork
MIOpen(HIP): Error [ValidateGcnAssemblerImpl] Specified assembler does not 
support AMDGPU. Expect performance degradation.
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/sim/mem_state.cc:443: info: Increasing stack size by one page.
build/GCN3_X86/sim/syscall_emul.cc:683: warn: fcntl: unsupported command 6
build/GCN3_X86/sim/syscall_emul.cc:683: warn: fcntl: unsupported command 6
build/GCN3_X86/sim/syscall_emul.cc:683: warn: fcntl: unsupported command 6


___
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