[gem5-users] Re: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
[AMD Official Use Only]
These would be valid for both as they both use the same cache protocol files.
I'm not very familiar with how dGPU is hacked up in SE mode to look like a
dGPU...
-Matt
From: David Fong
Sent: Thursday, March 17, 2022 9:57 AM
To: Poremba, Matthew ; Matt Sinclair
; gem5 users mailing list
Cc: Kyle Roarty ; Bharadwaj, Srikant
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
[CAUTION: External Email]
Hi Matt P,
Thanks for the tip on latency parameters.
Are these parameters valid ONLY for DGPU with VRAM or these apply to both DGPU
and APU ?
David
From: Poremba, Matthew mailto:matthew.pore...@amd.com>>
Sent: Thursday, March 17, 2022 7:51 AM
To: Matt Sinclair mailto:sincl...@cs.wisc.edu>>; David
Fong mailto:da...@chronostech.com>>; gem5 users mailing
list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Bharadwaj, Srikant
mailto:srikant.bharad...@amd.com>>
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
[AMD Official Use Only]
Hi David,
I don't think these are the parameters you want to be changing if you are
trying to change the VRAM memory latency which it seems like you are based on
the GDDR5 comment. Those parameters are for the latency between CUs seeing a
memory request and the request leaving the global memory pipeline, I believe.
It doesn't really have anything to do with interconnect or the latency to VRAM
memory.
I think the parameters you probably want are the latencies defined in the
GPU_VIPER slicc files:
* l2_request_latency / l2_response_latency in GPU_VIPER-TCC.sm
It looks like in configs/ruby/GPU_VIPER.py there are some command line
parameters for this which correspond to:
* --gpu-to-dir-latency / --TCC_latency
-Matt
From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Wednesday, March 16, 2022 10:41 PM
To: David Fong mailto:da...@chronostech.com>>; gem5
users mailing list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Poremba, Matthew
mailto:matthew.pore...@amd.com>>; Bharadwaj, Srikant
mailto:srikant.bharad...@amd.com>>
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
[CAUTION: External Email]
Matt P or Srikant: can you please help David with the latency question? You
know the answers better than I do here.
Matt
From: David Fong mailto:da...@chronostech.com>>
Sent: Wednesday, March 16, 2022 5:47 PM
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: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
Hi Matt S,
Thanks again for your quick reply with useful information.
I will rerun with -reg-alloc-policy=dynamic
in my mini regression to see If it makes a difference
As for LRN, I won't make modifications to lrn_config.dnnmark
unless it's required to run additional DNN tests.
The 4 tests : test_fwd_softmax, test_bwd_softmax, test_fwd_pool, and
test_bwd_bn are good enough for now.
For Matt S and Matt P,
Are these parameters for "mem_req_latency" and "mem_resp_latency" valid for
both APU (Carrizo) and GPU (VEGA) ?
gem5/src/gpu-compute/GPU.py
mem_req_latency = Param.Int(40, "Latency for request from the cu to ruby. "\
"Represents the pipeline to reach the TCP "\
"and specified in GPU clock cycles")
mem_resp_latency = Param.Int(40, "Latency for responses from ruby to the "\
"cu. Represents the pipeline between the "\
"TCP and cu as well as TCP data array "\
"access. Specified in GPU clock cycles")
It seems like to me the GPU (VEGA) with dedicated memory (GDDR5) should be
using a different parameter for its memory access latencies.
My company's IP could be used to reduce interconnect latencies for the APU and
GPU and would to quantify this at system level with benchmarks.
We would like to determine if GPU can get performance boost with reduced memory
access latencies.
Please confirm which memory latencies parameters to modify and use for GPU
(VEGA).
Thanks,
David
From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Tuesday, March 15, 2022 1:08 PM
To: David Fong mailto:da...@chronostech.com>>; 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: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
Hi David,
The dynamic register allocation policy allows the GPU to schedule as many
wavefronts as there is register space on a CU. By default, the original
register allocator released with this GPU model ("simple") only allowed 1
wavefront per CU at a time because the publicly available dependence modeling
was fairly primitive. However, this was not very realistic relative to how a
real GPU performs, so my group has added better
[gem5-users] Re: Gem5 FS mode exit after booting
First, please in future just copy and paste the text/error messages.
Screenshots are inefficient and make email threads such as this difficult
for future users to search.
Nikos is correct, your boot is working as intended, but I'll expand the
answer to help you in your work.
I notice you're using gem5 v21.0.0.0. This version of gem5 is a year old
and we've made significant improvements to the tool since then. The current
release of gem5 is v21.2.1.0. I strongly recommend you use this version.
You can get this by cloning the repo and compiling what you find at the
HEAD of the "stable" branch.
I know this is very confusing but the files under
http://gem5.org/dist/current/ are legacy files and were only known to work
for gem5 v19 (sidenote: this is totally my fault for calling this directory
"current" and due to various links being passed around since then, it's
stuck). The files you really want will be under http://gem5.org/dist/v21-2
for the v21.2 release, or http://gem5.org/dist/v21-0 for the v21.0 release
you're using.
The easiest way to do an x86 FS boot in v21.2 would be to do the following:
```
scons build/X86/gem5.opt -j `nproc`
./build/X86/gem5.opt configs/example/gem5_library/x86-ubuntu-run.py
```
This will automatically download the kernel and the disk image you need to
run the simulation. It will also exit after boot. The only thing you need
to keep in mind here is this uses the X86DemoBoard, which holds no
guarantees to be representative of real-world targets.
You can do some limit stuff after boot if you want, you can change the
x86-ubuntu-run.py line to something like:
```
board.set_kernel_disk_workload(
kernel=Resource("x86-linux-kernel-5.4.49"),
disk_image=Resource("x86-ubuntu-18.04-img"),
readfile_contents="echo 'hello'",
)
```
This will print "Hello" after boot instead of exiting. If you want
something more substantial you'll need to create your own disk image. We
provide some, most of of which have example scripts you can find under
"configs/example/gem5_library". More information on using the gem5
standard library can be found here:
https://www.gem5.org/documentation/gem5-stdlib/overview
Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
web: https://www.bobbybruce.net
On Thu, Mar 17, 2022 at 11:41 AM Eliot Moss via gem5-users <
gem5-users@gem5.org> wrote:
>
> ... and I'll just add that often folks want to have gem5 simulate the boot
> sequence and then take a checkpoint. That checkpoint can be used over and
> over to run from that point in the simulation, skipping the time taken to
> boot. In one of my setups this save 15-20 mins for each run.
>
> Regards - Eliot Moss
> ___
> 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: Gem5 FS mode exit after booting
... and I'll just add that often folks want to have gem5 simulate the boot sequence and then take a checkpoint. That checkpoint can be used over and over to run from that point in the simulation, skipping the time taken to boot. In one of my setups this save 15-20 mins for each run. Regards - Eliot Moss ___ 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 : X86 + GCN3 (gfx801) + test_fwd_lrn
Hi Matt P,
Thanks for the tip on latency parameters.
Are these parameters valid ONLY for DGPU with VRAM or these apply to both DGPU
and APU ?
David
From: Poremba, Matthew
Sent: Thursday, March 17, 2022 7:51 AM
To: Matt Sinclair ; David Fong ;
gem5 users mailing list
Cc: Kyle Roarty ; Bharadwaj, Srikant
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
[AMD Official Use Only]
Hi David,
I don't think these are the parameters you want to be changing if you are
trying to change the VRAM memory latency which it seems like you are based on
the GDDR5 comment. Those parameters are for the latency between CUs seeing a
memory request and the request leaving the global memory pipeline, I believe.
It doesn't really have anything to do with interconnect or the latency to VRAM
memory.
I think the parameters you probably want are the latencies defined in the
GPU_VIPER slicc files:
* l2_request_latency / l2_response_latency in GPU_VIPER-TCC.sm
It looks like in configs/ruby/GPU_VIPER.py there are some command line
parameters for this which correspond to:
* --gpu-to-dir-latency / --TCC_latency
-Matt
From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Wednesday, March 16, 2022 10:41 PM
To: David Fong mailto:da...@chronostech.com>>; gem5
users mailing list mailto:gem5-users@gem5.org>>
Cc: Kyle Roarty mailto:kroa...@wisc.edu>>; Poremba, Matthew
mailto:matthew.pore...@amd.com>>; Bharadwaj, Srikant
mailto:srikant.bharad...@amd.com>>
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
[CAUTION: External Email]
Matt P or Srikant: can you please help David with the latency question? You
know the answers better than I do here.
Matt
From: David Fong mailto:da...@chronostech.com>>
Sent: Wednesday, March 16, 2022 5:47 PM
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: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
Hi Matt S,
Thanks again for your quick reply with useful information.
I will rerun with -reg-alloc-policy=dynamic
in my mini regression to see If it makes a difference
As for LRN, I won't make modifications to lrn_config.dnnmark
unless it's required to run additional DNN tests.
The 4 tests : test_fwd_softmax, test_bwd_softmax, test_fwd_pool, and
test_bwd_bn are good enough for now.
For Matt S and Matt P,
Are these parameters for "mem_req_latency" and "mem_resp_latency" valid for
both APU (Carrizo) and GPU (VEGA) ?
gem5/src/gpu-compute/GPU.py
mem_req_latency = Param.Int(40, "Latency for request from the cu to ruby. "\
"Represents the pipeline to reach the TCP "\
"and specified in GPU clock cycles")
mem_resp_latency = Param.Int(40, "Latency for responses from ruby to the "\
"cu. Represents the pipeline between the "\
"TCP and cu as well as TCP data array "\
"access. Specified in GPU clock cycles")
It seems like to me the GPU (VEGA) with dedicated memory (GDDR5) should be
using a different parameter for its memory access latencies.
My company's IP could be used to reduce interconnect latencies for the APU and
GPU and would to quantify this at system level with benchmarks.
We would like to determine if GPU can get performance boost with reduced memory
access latencies.
Please confirm which memory latencies parameters to modify and use for GPU
(VEGA).
Thanks,
David
From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Tuesday, March 15, 2022 1:08 PM
To: David Fong mailto:da...@chronostech.com>>; 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: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
Hi David,
The dynamic register allocation policy allows the GPU to schedule as many
wavefronts as there is register space on a CU. By default, the original
register allocator released with this GPU model ("simple") only allowed 1
wavefront per CU at a time because the publicly available dependence modeling
was fairly primitive. However, this was not very realistic relative to how a
real GPU performs, so my group has added better dependence tracking support
(more could probably still be done, but it reduced stalls by up to 42% relative
to simple) and a register allocation scheme that allows multiple wavefronts to
run concurrently per CU ("dynamic").
By default, the GPU model assumes that the simple policy is used unless
otherwise specified. I have a patch in progress to change that though:
https://gem5-review.googlesource.com/c/public/gem5/+/57537
[gem5-users] Re: Gem5 FS mode exit after booting
Dear Waliullah, I think that the image has a gem5_init script that executes the m5 exit command. You can use the image from gem5 resources (http://dist.gem5.org/dist/v21-2/images/x86/ubuntu-18-04/x86-ubuntu.img.gz) with vmlinux-5.4.49 kernel (http://dist.gem5.org/dist/v21-2/kernels/x86/static/vmlinux-5.4.49). Then you need to emulate the image and change the gem5_init.sh in order to get the terminal: sudo apt-get install qemu qemu-user-static qemu-user sudo mount -o loop,offset=1048576 $HOME/COSSIM/kernels/disks/x86-ubuntu.img /mnt cd /mnt sudo mount --bind /proc /mnt/proc sudo mount --bind /dev /mnt/dev sudo chroot . nano root/gem5_init.sh #Change the line 21 from m5 exit to /bin/sh exit # now we are back to the host system cd sudo umount /mnt/proc sudo umount /mnt/dev sudo umount /mnt Now you can simulate using the gem5. Best regards, Nikos Quoting Waliullah Mridha via gem5-users : Hi, I am a new user trying to run Gem5 in FS mode. My command line is given bellow. I also attached a terminal to see the output. Everything looks good except Gem5 exit after the boot process finishes. On Gem5 run terminal I got the message "[cid:image004.png@01D8394B.885BD600]". Shouldn't I see a linux command prompt in the attached terminal instead of exiting after boot complete. Just wondering if the disk image I am using (downloaded from gs://dist/gem5.org/dist/current/images/x86) has any init script that causes this exit? Appreciate your help. Thanks Here is my command line. [cid:image002.png@01D8394B.885BD600] Here is the output from gem5: [cid:image003.png@01D8394B.885BD600] . . [cid:image004.png@01D8394B.885BD600] Here is the output from the terminal: . . [cid:image001.png@01D8394C.E5439960] ___ 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 do I disable most statistics in the stats.txt under Atomic CPU
Hello, I don't believe there's a way to do that right now. However, in atomic mode, many stats *are* skipped as they are only accessed in the "timing" functions. I doubt it would make much performance difference. However, that's just a guess, and I could be wrong. Cheers, Jason On Wed, Mar 16, 2022 at 6:25 PM Liyichao via gem5-users wrote: > Hi All: > > In the Atomic CPU, only a function simulation is performed for > enabling or debugging applications. The performance statistics of the > architecture are not concerned. Therefore, only a small items are required, > e.g. number of instructions or cycles. > > > > According to my understanding, each performance measurement item in the > code may affect the simulation speed. If we can disable statistics items > that are not concerned in most functional models, the simulation speed may > be greatly improved. I do not know whether my understanding is correct. If > so, does GEM5 consider the performance statistics switch? > > > ___ > 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] Gem5 FS mode exit after booting
Hi, I am a new user trying to run Gem5 in FS mode. My command line is given bellow. I also attached a terminal to see the output. Everything looks good except Gem5 exit after the boot process finishes. On Gem5 run terminal I got the message "[cid:image004.png@01D8394B.885BD600]". Shouldn't I see a linux command prompt in the attached terminal instead of exiting after boot complete. Just wondering if the disk image I am using (downloaded from gs://dist/gem5.org/dist/current/images/x86) has any init script that causes this exit? Appreciate your help. Thanks Here is my command line. [cid:image002.png@01D8394B.885BD600] Here is the output from gem5: [cid:image003.png@01D8394B.885BD600] . . [cid:image004.png@01D8394B.885BD600] Here is the output from the terminal: . . [cid:image001.png@01D8394C.E5439960] ___ 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 : X86 + GCN3 (gfx801) + test_fwd_lrn
[AMD Official Use Only]
Hi David,
I don't think these are the parameters you want to be changing if you are
trying to change the VRAM memory latency which it seems like you are based on
the GDDR5 comment. Those parameters are for the latency between CUs seeing a
memory request and the request leaving the global memory pipeline, I believe.
It doesn't really have anything to do with interconnect or the latency to VRAM
memory.
I think the parameters you probably want are the latencies defined in the
GPU_VIPER slicc files:
* l2_request_latency / l2_response_latency in GPU_VIPER-TCC.sm
It looks like in configs/ruby/GPU_VIPER.py there are some command line
parameters for this which correspond to:
* --gpu-to-dir-latency / --TCC_latency
-Matt
From: Matt Sinclair
Sent: Wednesday, March 16, 2022 10:41 PM
To: David Fong ; gem5 users mailing list
Cc: Kyle Roarty ; Poremba, Matthew ;
Bharadwaj, Srikant
Subject: RE: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
[CAUTION: External Email]
Matt P or Srikant: can you please help David with the latency question? You
know the answers better than I do here.
Matt
From: David Fong mailto:da...@chronostech.com>>
Sent: Wednesday, March 16, 2022 5:47 PM
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: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
Hi Matt S,
Thanks again for your quick reply with useful information.
I will rerun with -reg-alloc-policy=dynamic
in my mini regression to see If it makes a difference
As for LRN, I won't make modifications to lrn_config.dnnmark
unless it's required to run additional DNN tests.
The 4 tests : test_fwd_softmax, test_bwd_softmax, test_fwd_pool, and
test_bwd_bn are good enough for now.
For Matt S and Matt P,
Are these parameters for "mem_req_latency" and "mem_resp_latency" valid for
both APU (Carrizo) and GPU (VEGA) ?
gem5/src/gpu-compute/GPU.py
mem_req_latency = Param.Int(40, "Latency for request from the cu to ruby. "\
"Represents the pipeline to reach the TCP "\
"and specified in GPU clock cycles")
mem_resp_latency = Param.Int(40, "Latency for responses from ruby to the "\
"cu. Represents the pipeline between the "\
"TCP and cu as well as TCP data array "\
"access. Specified in GPU clock cycles")
It seems like to me the GPU (VEGA) with dedicated memory (GDDR5) should be
using a different parameter for its memory access latencies.
My company's IP could be used to reduce interconnect latencies for the APU and
GPU and would to quantify this at system level with benchmarks.
We would like to determine if GPU can get performance boost with reduced memory
access latencies.
Please confirm which memory latencies parameters to modify and use for GPU
(VEGA).
Thanks,
David
From: Matt Sinclair mailto:sincl...@cs.wisc.edu>>
Sent: Tuesday, March 15, 2022 1:08 PM
To: David Fong mailto:da...@chronostech.com>>; 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: gem5 : X86 + GCN3 (gfx801) + test_fwd_lrn
Hi David,
The dynamic register allocation policy allows the GPU to schedule as many
wavefronts as there is register space on a CU. By default, the original
register allocator released with this GPU model ("simple") only allowed 1
wavefront per CU at a time because the publicly available dependence modeling
was fairly primitive. However, this was not very realistic relative to how a
real GPU performs, so my group has added better dependence tracking support
(more could probably still be done, but it reduced stalls by up to 42% relative
to simple) and a register allocation scheme that allows multiple wavefronts to
run concurrently per CU ("dynamic").
By default, the GPU model assumes that the simple policy is used unless
otherwise specified. I have a patch in progress to change that though:
https://gem5-review.googlesource.com/c/public/gem5/+/57537.
Regardless, if applications are faili
[gem5-users] Re: Boot gets stuck sometimes ARM FS + KVM + 8 CPUs
Thank you, Giacomo! I'll take a look at the links you provide and try to merge the implemented GICv3 support into my local repo. Regards, Pedro. ___ 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
