[gem5-dev] Re: Modeling Golden Cove in Gem5

[Matt Sinclair via gem5-dev]

I am not an expert at the CPU model, but a couple things I can point you
two:

1.  The X86 O3CPU model is based on the (very old) Alpha 21264 CPU (
https://ieeexplore.ieee.org/document/755465), with some bells and whistles
that have partially updated it to try and represent more modern CPUs.  For
example, on the review board there are currently some patches for FDIP (
https://web.eecs.umich.edu/~taustin/papers/MICRO32-fdp.pdf) support (
https://github.com/gem5/gem5/pull/355) although I believe that is initially
focused on ARM.

2.  The most recent X86 CPU architecture modeling I am aware of is for
Skylake: https://github.com/darchr/gem5-skylake-config.  I did not take
part in this work, so I can't really answer any questions about it (others
on the mailing list hopefully can), but I would assume you could start with
this model and then try to update for Golden Cove from there.

Hope this helps,
Matt

On Tue, Nov 7, 2023 at 1:41 AM Madan YN via gem5-dev 
wrote:

> Hey guys, I have recently started using Gem5 for my undergraduate research
> work and I am very new to it. I have two questions
> 1. What is the microarchitecture of the standard x86 O3 cpu model and is
> there a graphical representation anywhere?
> 2. If I have to model a specific microarchitecture like Golden Cove, what
> will be the best way to do it? Is it creating the simobject from scratch or
> using the O3 simobject and building on top of it?
>
> Thank you for your time
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #659

[Matt Sinclair via gem5-dev]

Thanks Bobby, appreciate it.

Matt

On Fri, Jul 7, 2023 at 11:04 AM Bobby Bruce  wrote:

> This appears to be a Docker failure of some kind. Both the compiler and
> nightly tests dropped at the same time. I think the Docker daemon crashed
> for some reason
>
> No tests failed here. The patches submitted yesterday don’t interact with
> any tests so they should all still pass.
>
> I’ll re-run these now.
>
> To answer you question directly Matt: these tests (Nightly #659) didn’t
> reach the GPU test stage so there’s nothing to see here, but yesterday’s
> passed and you can see the terminal output here:
> https://jenkins.gem5.org/job/nightly/658/consoleText. The GPU tests are
> still just bash scripts for now so the GPU tests fail based on gem5 exit
> codes and all we get is terminal output as a log. From looking at this, it
> looks like square is running as intended.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
> On Jul 7, 2023, at 8:28 AM, Matt Sinclair 
> wrote:
>
> Hi Bobby,
>
> How do I read this output?  I wanted to check if Square was still passing,
> because of the patch Matt P pushed yesterday, but I don't seem to see it.
> I realize we are replacing this setup shortly, but nonetheless want to make
> sure bugs aren't slipping in.
>
> Thanks,
> Matt
>
> On Fri, Jul 7, 2023 at 9:14 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/659/display/redirect?page=changes>
>>
>> Changes:
>>
>> [Bobby R. Bruce] util: Update GitHub Runners Vagrant to overcommit memory
>>
>> [Bobby R. Bruce] util: '-eq' -> '-ge' for if in vm_manager.sh
>>
>> [Bobby R. Bruce] util: Add 'shutdown' argument option to vm_manager.sh
>>
>> [Bobby R. Bruce] util: Add 'swapspace' daemon to runner VM.
>>
>>
>> --
>> [...truncated 2.76 MB...]
>> Starting Test Suite:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>>
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outfhfhbv7i/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test1_ld
>> Test:
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5outtvvim2dh -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/second_chance_test2_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test2_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>>
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outtvvim2dh/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test2_ld
>> Test:
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5outqn5wz59b -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/second_chance_test3_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test3_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>>
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outqn5wz59b/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test3_ld
>> Test:
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5out6it56ldp -re 

[gem5-dev] Re: Build failed in Jenkins: nightly #659

[Matt Sinclair via gem5-dev]

Hi Bobby,

How do I read this output?  I wanted to check if Square was still passing,
because of the patch Matt P pushed yesterday, but I don't seem to see it.
I realize we are replacing this setup shortly, but nonetheless want to make
sure bugs aren't slipping in.

Thanks,
Matt

On Fri, Jul 7, 2023 at 9:14 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/659/display/redirect?page=changes>
>
> Changes:
>
> [Bobby R. Bruce] util: Update GitHub Runners Vagrant to overcommit memory
>
> [Bobby R. Bruce] util: '-eq' -> '-ge' for if in vm_manager.sh
>
> [Bobby R. Bruce] util: Add 'shutdown' argument option to vm_manager.sh
>
> [Bobby R. Bruce] util: Add 'swapspace' daemon to runner VM.
>
>
> --
> [...truncated 2.76 MB...]
> Starting Test Suite:
> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>
> Starting Test Case:
> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5outfhfhbv7i/simout
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test1_ld
> Test:
> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5outtvvim2dh -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
> traces/second_chance_test2_ld
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test2_ld.py
> Starting Test Suite:
> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>
> Starting Test Case:
> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5outtvvim2dh/simout
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test2_ld
> Test:
> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5outqn5wz59b -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
> traces/second_chance_test3_ld
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test3_ld.py
> Starting Test Suite:
> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>
> Starting Test Case:
> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5outqn5wz59b/simout
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test3_ld
> Test:
> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5out6it56ldp -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
> traces/tree_plru_test1_ld
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/tree_plru_test1_ld.py
> Starting Test Suite:
> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example
>
> Starting Test Case:
> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5out6it56ldp/simout
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/tree_plru_test1_ld
> Test:
> test-replacement-policy-traces/tree_plru_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5outwz6n_66i -re --silent-redirect
> 

[gem5-dev] Re: Build failed in Jenkins: nightly #620

[Matt Sinclair via gem5-dev]

Agreed, thanks Matt P!

Matt

On Wed, May 31, 2023 at 3:43 PM Bobby Bruce  wrote:

> Ah! Thanks Matt P. I didn’t realize this was the fix! Thanks!
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
> On May 31, 2023, at 1:28 PM, Poremba, Matthew 
> wrote:
>
> [AMD Official Use Only - General]
>
> https://gem5-review.googlesource.com/c/public/gem5/+/71078
>
> -Matt
>
> *From:* Matt Sinclair 
> *Sent:* Wednesday, May 31, 2023 1:22 PM
> *To:* The gem5 Developer List 
> *Cc:* Bobby Bruce ; Poremba, Matthew <
> matthew.pore...@amd.com>
> *Subject:* Re: [gem5-dev] Re: Build failed in Jenkins: nightly #620
>
> *Caution:* This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
> I’m confused, there weren’t any recent GPU commits, right?  So someone
> other than Matt P or us must have broken things?
>
> Matt
>
> On Wed, May 31, 2023 at 3:19 PM Bobby Bruce via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> Hey Matt,
>
> At least one of the reason’s the Nightly tests are failing is a GPU test
> failure. You can reproduce it using:
>
> ```
> wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
>
> docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd)
> gcr.io/gem5-test/gcn-gpu:latest scons build/GCN3_X86/gem5.opt -j`nproc`
>
> docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd)
> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt
> configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
> ```
>
> Could someone on your end look into this? It appears to encounter a
> segmentation fault.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On May 29, 2023, at 3:28 PM, jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> See 
>
> Changes:
>
>
> --
> [...truncated 4.14 MB...]
> [ CXX] GCN3_X86/debug/VIOIface.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOConsole.cc
> [ CXX] GCN3_X86/debug/VIOConsole.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOBlock.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9P.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9PData.cc
> [ CXX] GCN3_X86/debug/VIOBlock.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9P.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9PData.cc -> .o
> [ CXX] GCN3_X86/python/m5/defines.py.cc -> .o
> [ CXX] GCN3_X86/python/m5/info.py.cc -> .o
> [ CXX] src/base/date.cc -> GCN3_X86/base/date.o
> [LINK]  -> GCN3_X86/gem5.opt
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
> Please make sure to check the mailing list for deprecation
> announcements.
> + wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
> + mkdir -p tests/testing-results
> + docker run --rm -u 118: --volume
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
> -w /nobackup/jenkins/workspace/nightly/tests/.. --memory=18g
> gcr.io/gem5-test/gcn-gpu:latestbuild/GCN3_X86/gem5.opt
> configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
> Global frequency set at 1 ticks per second
> src/mem/dram_interface.cc:690: warn: DRAM device capacity (8192 Mbytes)
> does not match the address range assigned (512 Mbytes)
> src/base/statistics.hh:279: warn: One of the stats is a legacy stat.
> Legacy stat is a stat that does not belong to any statistics::Group. Legacy
> stat is deprecated.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does 

[gem5-dev] Re: Build failed in Jenkins: nightly #620

[Matt Sinclair via gem5-dev]

I’m confused, there weren’t any recent GPU commits, right?  So someone
other than Matt P or us must have broken things?

Matt

On Wed, May 31, 2023 at 3:19 PM Bobby Bruce via gem5-dev 
wrote:

> Hey Matt,
>
> At least one of the reason’s the Nightly tests are failing is a GPU test
> failure. You can reproduce it using:
>
> ```
>
> wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
>
>
> docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd)
> gcr.io/gem5-test/gcn-gpu:latest scons build/GCN3_X86/gem5.opt -j`nproc`
>
>
> docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd)
> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt
> configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
>
> ```
>
>
> Could someone on your end look into this? It appears to encounter a
> segmentation fault.
>
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
> On May 29, 2023, at 3:28 PM, jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> See 
>
> Changes:
>
>
> --
> [...truncated 4.14 MB...]
> [ CXX] GCN3_X86/debug/VIOIface.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOConsole.cc
> [ CXX] GCN3_X86/debug/VIOConsole.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOBlock.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9P.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9PData.cc
> [ CXX] GCN3_X86/debug/VIOBlock.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9P.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9PData.cc -> .o
> [ CXX] GCN3_X86/python/m5/defines.py.cc -> .o
> [ CXX] GCN3_X86/python/m5/info.py.cc -> .o
> [ CXX] src/base/date.cc -> GCN3_X86/base/date.o
> [LINK]  -> GCN3_X86/gem5.opt
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
> Please make sure to check the mailing list for deprecation
> announcements.
> + wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
> + mkdir -p tests/testing-results
> + docker run --rm -u 118: --volume
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
> -w /nobackup/jenkins/workspace/nightly/tests/.. --memory=18g
> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt
> configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
> Global frequency set at 1 ticks per second
> src/mem/dram_interface.cc:690: warn: DRAM device capacity (8192 Mbytes)
> does not match the address range assigned (512 Mbytes)
> src/base/statistics.hh:279: warn: One of the stats is a legacy stat.
> Legacy stat is a stat that does not belong to any statistics::Group. Legacy
> stat is deprecated.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide
> range [1:1.6e+06] into equal-sized buckets. Rounding up.
> 

[gem5-dev] Re: GEM5-GCN-DNNMark get Invalid filter channel number when running: dnnmark_test_VGG, dnnmark_test_alexnet, dnnmark_test_fwd_conv

[Matt Sinclair via gem5-dev]

Thanks, this is helpful.  Looking through those old email chains, I don't
see any specific resolution to them, unfortunately.  I do not have a ton of
time to dig into this (end of the semester is keeping me busy) but if you
can keep digging I may be able to provide some ideas.

First, are you still seeing this error:

MIOpen(HIP): Warning [ParseAndLoadDb] File is unreadable:
/opt/rocm-4.0.1/miopen/share/miopen/db/gfx801_4.HIP.fdb.txt

after making the above change to include the MIOpen cache?

Second, what layer size are you assuming/trying to conv?  The failure
shortly after is here:
https://github.com/ROCmSoftwarePlatform/MIOpen/blob/rocm-4.0.1-release/src/ocl/convolutionocl.cpp#L149.
It seems to imply that X and W are not equal, but we'd need to dig to
figure out if this is because of the config file being passed in, or
something in MIOpen/gem5 that is breaking it.  Given that the function call
that is failing is trying to create a tensor:
https://github.com/shidong-ai/DNNMark/blob/develop/core/include/dnn_utility.h#L106,
my guess is that it's something with the config, because something so basic
probably (hopefully?) doesn't fail in MIOpen...

In terms of if it should work or not, I don't see that we included it in
prior papers (e.g.,
https://www.gem5.org/assets/files/papers/enabling2021ispass.pdf) but I
don't know if that was because we didn't try or if there was a deeper, more
fundamental reason).

Matt

On Sat, May 13, 2023 at 10:34 AM 429442672 <429442...@qq.com> wrote:

> Thank you so much for advice.
>
> Acturally, i have made the cachefiles as shown in the figure.
>
> Besides, i have succesfully run several benchmarks such as pool,
> activations, softmax, so i think the kernels is setuped.
> The reason of the differences in commands is that i directly run the
> command in the docker container.
>
> There might be a common problem when running the network with conv, some
> other email such as
> https://www.mail-archive.com/gem5-users@gem5.org/msg20468.html
> https://www.mail-archive.com/gem5-users@gem5.org/msg20456.html
> also met this problem.
>
> I have also tried to use the latest docker and the original command like
> this:
>
> docker run --rm -v ${PWD}:${PWD} -v 
> ${PWD}/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0 -w 
> ${PWD} gcr.io/gem5-test/gcn-gpu:v22-1 gem5/build/GCN3_X86/gem5.opt 
> gem5/configs/example/apu_se.py -n3 
> --benchmark-root=gem5-resources/src/gpu/DNNMark/build/benchmarks/test_fwd_conv
>  -cdnnmark_test_fwd_conv --options="-config 
> gem5-resources/src/gpu/DNNMark/config_example/conv_config.dnnmark -mmap 
> gem5-resources/src/gpu/DNNMark/mmap.bin"
>
> but still got the same error.
>
> Is that means conv layers is currently no available for gem5-gcn?
>
> May i ask is there anyone else met this problem before?
>
> thank you!
>
>
> -- 原始邮件 --
> *发件人:* "Matt Sinclair" ;
> *发送时间:* 2023年5月12日(星期五) 中午11:42
> *收件人:* "The gem5 Developer List";
> *抄送:* "gem5-users";"429442672"<429442...@qq.com>;
> *主题:* Re: [gem5-dev] GEM5-GCN-DNNMark get Invalid filter channel number
> when running: dnnmark_test_VGG, dnnmark_test_alexnet, dnnmark_test_fwd_conv
>
> I have not tried running these specific benchmarks in gem5 personally, so
> I cannot say for certain what the error is or even if they are expected to
> run to completion in gem5.  But, normally the error you're seeing happens
> because you have not created the appropriate "cache" files for the GPU
> kernel(s) the program is trying to run.  MIOpen first checks to see if the
> desired kernel has been run on your machine before, and if not it tries to
> do online compilation of that kernel.  Unfortunately online compilation of
> kernels in gem5 is a) very slow and b), because it is very slow, not
> supported in gem5 (basically, it is so slow as to not be worth supporting
> in many cases, in my opinion).  So, instead, the expectation is that we
> build the kernels we want ahead of time, before running the program.  You
> may have seen in the examples we provide for DNNMark (
> https://resources.gem5.org/resources/dnn-mark) that we have this
> "generate cachefiles" script -- that is exactly what the purpose of that
> script is.  Moreover, on the same webpage, you may have noticed we include
> the path to that cache directory in our docker commands (emphasis mine):
>
> docker run --rm -v ${PWD}:${PWD} -v 
> *${PWD}/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0* 
> -w ${PWD} gcr.io/gem5-test/gcn-gpu:v22-1 gem5/build/GCN3_X86/gem5.opt 
> gem5/configs/example/apu_se.py -n3 
> --benchmark-root=gem5-resources/src/gpu/DNNMark/build/benchmarks/test_fwd_softmax
>  -cdnnmark_test_fwd_softmax --options="-config 
> gem5-resources/src/gpu/DNNMark/config_example/softmax_config.dnnmark -mmap 
> gem5-resources/src/gpu/DNNMark/mmap.bin"
>
> From looking at your commands, I don't see you including this.  Thus,
> while I do not know if that script by default produces the kernels 

[gem5-dev] Re: GEM5-GCN-DNNMark get Invalid filter channel number when running: dnnmark_test_VGG, dnnmark_test_alexnet, dnnmark_test_fwd_conv

[Matt Sinclair via gem5-dev]

I have not tried running these specific benchmarks in gem5 personally, so I
cannot say for certain what the error is or even if they are expected to
run to completion in gem5.  But, normally the error you're seeing happens
because you have not created the appropriate "cache" files for the GPU
kernel(s) the program is trying to run.  MIOpen first checks to see if the
desired kernel has been run on your machine before, and if not it tries to
do online compilation of that kernel.  Unfortunately online compilation of
kernels in gem5 is a) very slow and b), because it is very slow, not
supported in gem5 (basically, it is so slow as to not be worth supporting
in many cases, in my opinion).  So, instead, the expectation is that we
build the kernels we want ahead of time, before running the program.  You
may have seen in the examples we provide for DNNMark (
https://resources.gem5.org/resources/dnn-mark) that we have this "generate
cachefiles" script -- that is exactly what the purpose of that script is.
Moreover, on the same webpage, you may have noticed we include the path to
that cache directory in our docker commands (emphasis mine):

docker run --rm -v ${PWD}:${PWD} -v
*${PWD}/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0*
-w ${PWD} gcr.io/gem5-test/gcn-gpu:v22-1 gem5/build/GCN3_X86/gem5.opt
gem5/configs/example/apu_se.py -n3
--benchmark-root=gem5-resources/src/gpu/DNNMark/build/benchmarks/test_fwd_softmax
-cdnnmark_test_fwd_softmax --options="-config
gem5-resources/src/gpu/DNNMark/config_example/softmax_config.dnnmark
-mmap gem5-resources/src/gpu/DNNMark/mmap.bin"

>From looking at your commands, I don't see you including this.  Thus, while
I do not know if that script by default produces the kernels needed for,
say, AlexNet, I strongly suspect you should start by running that script
and updating your docker commands to include the cache stuff ... then see
what happens from there.

Sidenote: normally when I see this:

MIOpen(HIP): Warning [ParseAndLoadDb] File is unreadable:
/opt/rocm-4.0.1/miopen/share/miopen/db/gfx801_4.HIP.fdb.txt

It means that the files MIOpen is expecting are not setup properly.
Normally I just symlink these extra files -- e.g., symlink gfx801_4... from
gfx801_32 ... (this is not the best performing, option because the
resources are different, but provides a basic setup step to avoid problems
like this).
Matt

On Thu, May 11, 2023 at 10:02 PM 429442672 via gem5-dev 
wrote:

> Dear Matt,
>  When i run the benchmarks: dnnmark_test_VGG, dnnmark_test_alexnet,
> dnnmark_test_fwd_conv, and i got the same error like this (get Invalid
> filter channel number)：
>
> build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall
> fdatasync(...)
> build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall
> fdatasync(...)
> build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall
> fdatasync(...)
> build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall
> fdatasync(...)
> 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
> 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
> 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
> 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
> MIOpen(HIP): Warning [ParseAndLoadDb] File is unreadable:
> /opt/rocm-4.0.1/miopen/share/miopen/db/gfx801_4.HIP.fdb.txt
> 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
> MIOpen Error: /root/driver/MLOpen/src/ocl/convolutionocl.cpp:150: Invalid
> filter channel number
> 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
> MIOpen Error: /root/driver/MLOpen/src/ocl/convolutionocl.cpp:150: Invalid
> filter channel number
> MIOpen Error: 3 at
> /home/tang/gem5-resources/src/gpu/DNNMark/core/include/dnn_utility.h1057Ticks:
> 327510244000
> Exiting because exiting with last active thread context
>
>
> My command line is:
>
> gem5/build/GCN3_X86/gem5.opt gem5/configs/example/apu_se.py
> -n 8 --mem-size=12GB
> --benchmark-root=gem5-resources/src/gpu/DNNMark/build/benchmarks/test_fwd_conv
> -c dnnmark_test_fwd_conv
> --options="-config
> gem5-resources/src/gpu/DNNMark/config_example/conv_config.dnnmark -mmap
> gem5-resources/src/gpu/DNNMark/mmap.bin"
>
> and i 

[gem5-dev] Re: Problem on simulating GCN3 GPU: Running DNNMark too slow.

[Matt Sinclair via gem5-dev]

I have not personally tried to run FWD_FC lately -- we do test some of the
DNNMark layers in the weekly test, but testing all of them is not
practical.  Looking at the error though, it appears that the simulated gem5
memory system is not big enough.  I would try increasing --mem-size on the
command line.  For example, try --mem-size=8GB or --mem-size=16GB (not sure
exactly how much memory FWD_FC needs).

Matt

On Wed, May 10, 2023 at 1:33 AM 429442672 <429442...@qq.com> wrote:

> Thank you so much for taking the time to answer my questions
>
> For the question 1:
>
> yes, blocked means as what you said: "the program is just running"
>
> I followed your suggestion and made some modifications:
>
> a. for src/gpu/DNNMark/config_example/fc_config.dnnmark:
>
> b. i generate a 30MB data as input, instead of using the mmap.bin
>
>
> then i ran:
>
> sudo docker run --rm -v ${PWD}:${PWD} -v
> ${PWD}/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0
> -w ${PWD} gcn-gpu gem5/build/GCN3_X86/gem5.opt
> gem5/configs/example/apu_se.py -n4
> --benchmark-root=gem5-resources/src/gpu/DNNMark/build/benchmarks/test_fwd_fc
> -c dnnmark_test_fwd_fc
> --options="-config
> gem5-resources/src/gpu/DNNMark/config_example/fc_config.dnnmark -mmap
> gem5-resources/src/gpu/DNNMark/DNNMark_data.dat"
>
>
> after a few hours, i got the output with:
>
> build/GCN3_X86/sim/syscall_emul.cc:74: warn: ignoring syscall mprotect(...)
> build/GCN3_X86/arch/generic/debugfaults.hh:145: warn: MOVNTDQ: Ignoring
> non-temporal hint, modeling as cacheable!
> build/GCN3_X86/sim/mem_state.cc:99: panic: Someone allocated physical
> memory at VA 0x1000 without creating a VMA!
> Memory Usage: 22622544 KBytes
> Program aborted at tick 10636412834000
> --- BEGIN LIBC BACKTRACE ---
> gem5/build/GCN3_X86/gem5.opt(+0x19efd50)[0x560c0deabd50]
> gem5/build/GCN3_X86/gem5.opt(+0x1a1425e)[0x560c0ded025e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f33bb73f420]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f33ba8e400b]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f33ba8c3859]
> gem5/build/GCN3_X86/gem5.opt(+0x4c20a5)[0x560c0c97e0a5]
> gem5/build/GCN3_X86/gem5.opt(+0x1a80f2b)[0x560c0df3cf2b]
> gem5/build/GCN3_X86/gem5.opt(+0x1a81623)[0x560c0df3d623]
> gem5/build/GCN3_X86/gem5.opt(+0x1a928ab)[0x560c0df4e8ab]
> gem5/build/GCN3_X86/gem5.opt(+0x12a3c92)[0x560c0d75fc92]
> gem5/build/GCN3_X86/gem5.opt(+0x12dc7f5)[0x560c0d7987f5]
> gem5/build/GCN3_X86/gem5.opt(+0x1304b15)[0x560c0d7c0b15]
> gem5/build/GCN3_X86/gem5.opt(+0x1304cc0)[0x560c0d7c0cc0]
> gem5/build/GCN3_X86/gem5.opt(+0x1a9427f)[0x560c0df5027f]
> gem5/build/GCN3_X86/gem5.opt(+0x129bef0)[0x560c0d757ef0]
> gem5/build/GCN3_X86/gem5.opt(+0x1a7333f)[0x560c0df2f33f]
> gem5/build/GCN3_X86/gem5.opt(+0x16b9804)[0x560c0db75804]
> gem5/build/GCN3_X86/gem5.opt(+0x16b3dc8)[0x560c0db6fdc8]
> gem5/build/GCN3_X86/gem5.opt(+0x16b4b80)[0x560c0db70b80]
> gem5/build/GCN3_X86/gem5.opt(+0x1a03665)[0x560c0debf665]
> gem5/build/GCN3_X86/gem5.opt(+0x1a2bab4)[0x560c0dee7ab4]
> gem5/build/GCN3_X86/gem5.opt(+0x1a2c093)[0x560c0dee8093]
> gem5/build/GCN3_X86/gem5.opt(+0xadded2)[0x560c0cf99ed2]
> gem5/build/GCN3_X86/gem5.opt(+0x4b6757)[0x560c0c972757]
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x2a8748)[0x7f33bb9f6748]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x8dd8)[0x7f33bb7cbf48]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f33bb918e4b]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyFunction_Vectorcall+0x94)[0x7f33bb9f6124]
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(+0x74d6d)[0x7f33bb7c2d6d]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalFrameDefault+0x7d86)[0x7f33bb7caef6]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(_PyEval_EvalCodeWithName+0x8fb)[0x7f33bb918e4b]
>
> /lib/x86_64-linux-gnu/libpython3.8.so.1.0(PyEval_EvalCodeEx+0x42)[0x7f33bb9191d2]
> --- END LIBC BACKTRACE ---
> Failed to execute default signal handler!
>
>
> I don't know what i did wrong.
> Have you ever tried running this benchmark or the benchmarks like alexnet
> or VGG?
> May I ask for some advices for successfully runing this test_fwd_fc?
>
> Thank you !!
>
> -- 原始邮件 --
> *发件人:* "Matt Sinclair" ;
> *发送时间:* 2023年5月10日(星期三) 凌晨5:34
> *收件人:* "429442672"<429442...@qq.com>;
> *抄送:* 
> "gem5-dev";"gem5-users";"Poremba,
> Matthew";
> *主题:* Re: Problem on simulating GCN3 GPU: Running DNNMark too slow.
>
> Hi,
>
> Trying to answer your various questions:
>
> 1.  Similar to #2 below, I am unclear what "blocked" means.  It sounds
> like the program is just running, but is slower than you were hoping it
> would be?  If so, unfortunately, this is a well known problem with detailed
> simulators like gem5 -- they can take a long time to simulate a workload.
> However, there is another option, where you aren't using enough thread
> contexts, see #2 below.  If you are willing to, you can decrease the batch
> size, and usually the program 

[gem5-dev] Re: Problem on simulating GCN3 GPU: Running DNNMark too slow.

[Matt Sinclair via gem5-dev]

Hi,

Trying to answer your various questions:

1.  Similar to #2 below, I am unclear what "blocked" means.  It sounds like
the program is just running, but is slower than you were hoping it would
be?  If so, unfortunately, this is a well known problem with detailed
simulators like gem5 -- they can take a long time to simulate a workload.
However, there is another option, where you aren't using enough thread
contexts, see #2 below.  If you are willing to, you can decrease the batch
size, and usually the program simulates faster.  For FWD_FC in particular,
you would do this by decreasing n (e.g., from to 100 to 4, 8, or 16):
https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/develop/src/gpu/DNNMark/config_example/fc_config.dnnmark#6
.

2.  Define blocked -- what does this mean?  The bigger benchmarks here are
very large ML workloads, it would not surprise me if they took days (or
maybe weeks) to run them end-to-end in gem5.  Are you seeing kernels
progressing through it (e.g., use the GPUKernelInfo debug flag to print
when kernels launch and exit)?  If you are seeing kernels progress, it's
just a really large workload and you'd have to be more patient.  My group
is working on ways to cut down runtime for workloads like this, but nothing
we have specifically tested for these workloads and no ETA on when that
would be available/fully working.

It is also possible that you aren't running with enough CPU thread contexts
and the program is infinitely looping there (ROCm launches additional CPU
processes when setting up a GPU program, these require gem5 to have
additional CPU thread contexts).  But without knowing where the program
seems to be blocked, it's hard to say if this is a problem or not.  But you
could try increasing -n on the command line (e.g., from 3 to 5, or from 5
to 10) to see if this resolves the current problem.  This will not resolve
the above issue though.

3.  I have never personally tried modeling a Transformer in DNNMark, so
this might be a better question for the DNNMark authors.  But ultimately
what you are suggesting is the right way to model things in DNNMark -- in
the config files you can specify a series of layers, one connected after
another.  So, if you knew what the layers in a Transformer are, in theory
you could express it in a config file.  This assumes that DNNMark supports
all of the layers in a Transformer though, which I do not know if that is
true or not (you would need to ask the DNNMark authors).

4.  This seems like a question for DNNMark's authors.  In gem5, we are just
running DNNMark in gem5.  But ultimately what I can recommend is you start
with the base files (e.g.,
https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/develop/src/gpu/DNNMark/benchmarks/test_alexnet/test_alexnet.cc)
and the config files (e.g.,
https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/develop/src/gpu/DNNMark/config_example/alexnet.dnnmark)
and go from there.  When I started with DNNMark, I would observe the LOG
prints it prints to the screen, then grep for those prints and examine the
code.

5.  What is "ruby memory" -- is this L1, L2, or main memory size?
Something else?  There are documents like this:
https://www.gem5.org/2020/06/01/towards-full.html,
https://www.gem5.org/2020/05/30/enabling-multi-gpu.html,
https://www.gem5.org/2020/05/27/modern-gpu-applications.html, and
https://www.gem5.org/documentation/general_docs/gpu_models/GCN3.  The GPU
Ruby system uses the same building blocks as the CPU Ruby models:
https://www.gem5.org/documentation/learning_gem5/part3/MSIintro/.  Not sure
what exactly you are looking for though.

Thanks,
Matt

On Tue, May 9, 2023 at 4:34 AM 429442672 <429442...@qq.com> wrote:

>
> hi everyone,
>
> I have successfully built and ran DNNMark using the command:
>
> sudo docker run --rm -v ${PWD}:${PWD} -v
> ${PWD}/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0
> -w ${PWD} gcn-gpu
> gem5/build/GCN3_X86/gem5.opt gem5/configs/example/apu_se.py -n 3
> --benchmark-root=gem5-resources/src/gpu/DNNMark/build/benchmarks/test_fwd_softmax
> -cdnnmark_test_fwd_softmax
> --options="-config
> gem5-resources/src/gpu/DNNMark/config_example/softmax_config.dnnmark -mmap
> gem5-resources/src/gpu/DNNMark/mmap.bin"
>
> with the output
>
> Exiting because exiting with last active thread context
>
> which may means i have correctly made the running environment.
>
>
> However, i tried several benchmarks in
>
>
> but meet following problems:
>
> 1. problem on running test_fwd_fc
>
> When i run test_fwd_fc using:
>
> sudo docker run --rm -v ${PWD}:${PWD} -v
> ${PWD}/gem5-resources/src/gpu/DNNMark/cachefiles:/root/.cache/miopen/2.9.0
> -w ${PWD} gcn-gpu gem5/build/GCN3_X86/gem5.opt
> gem5/configs/example/apu_se.py -n3
> --benchmark-root=gem5-resources/src/gpu/DNNMark/build/benchmarks/test_fwd_fc
> -c dnnmark_test_fwd_fc
> --options="-config
> gem5-resources/src/gpu/DNNMark/config_example/fc_config.dnnmark -mmap
> 

[gem5-dev] Re: 回复：[gem5-users] Re: Hi, i'm new to gem5. is there a way to make simulation for a CPU-GPU heterogeneous computing？

[Matt Sinclair via gem5-dev]

Right, you need to specify the values you want for them or don't include
them.

Matt

On Fri, Apr 28, 2023 at 9:45 AM 429442672 <429442...@qq.com> wrote:

> Oh， sorry,  i got the point.   that's the optional args.
>
>
> -- 原始邮件 --
> *发件人:* "The gem5 Developer List" ;
> *发送时间:* 2023年4月28日(星期五) 晚上7:47
> *收件人:* "The gem5 Users mailing list";
> *抄送:* "The gem5 Developer List";"gem5-users"<
> gem5-us...@gem5.org>;"Matt Sinclair" >;"429442672"<429442...@qq.com>;
> *主题:* [gem5-dev] 回复：[gem5-users] Re: Hi, i'm new to gem5. is there a way
> to make simulation for a CPU-GPU heterogeneous computing？
>
> hi,
> Thank you so much for replying me.
> I tried to run DNNMark, following the doc from
> https://resources.gem5.org/resources/dnn-mark. However, when i ran this
> code :
>
> *To generate the MIOpen kernels:*
>
> cd src/gpu/DNNMark
> docker run --rm -v ${PWD}:${PWD} 
> -v${PWD}/cachefiles:/root/.cache/miopen/2.9.0 -w ${PWD} 
> gcr.io/gem5-test/gcn-gpu:v22-1 python3 generate_cachefiles.py cachefiles.csv 
> [--gfx-version={gfx801,gfx803}] [--num-cus=N]
>
>
>   I got result like this.
>
>
> tang@tang-Matrimax-PC:~/gem5-resources/src/gpu/DNNMark$ sudo docker run
> --rm -v ${PWD}:${PWD} -v${PWD}/cachefiles:/root/.cache/miopen/2.9.0 -w
> ${PWD} gcn-gpu python3 generate_cachefiles.py cachefiles.csv
> [--gfx-version={gfx801,gfx803}] [--num-cus=N]
> usage: generate_cachefiles.py [-h] [--num-cus NUM_CUS]
>   [--gfx-version {gfx801,gfx803,gfx900}]
>   csv_file
> generate_cachefiles.py: error: unrecognized arguments:
> [--gfx-version=gfx801] [--gfx-version=gfx803] [--num-cus=N]
> tang@tang-Matrimax-PC:~/gem5-resources/src/gpu/DNNMark$ sudo docker run
> --rm -v ${PWD}:${PWD} -v${PWD}/cachefiles:/root/.cache/miopen/2.9.0 -w
> ${PWD} gcn-gpu python3 generate_cachefiles.py cachefiles.csv
> [--gfx-version={gfx801,gfx803}] [--num-cus=4]
> usage: generate_cachefiles.py [-h] [--num-cus NUM_CUS]
>   [--gfx-version {gfx801,gfx803,gfx900}]
>   csv_file
> generate_cachefiles.py: error: unrecognized arguments:
> [--gfx-version=gfx801] [--gfx-version=gfx803] [--num-cus=4]
> tang@tang-Matrimax-PC:~/gem5-resources/src/gpu/DNNMark$ sudo docker run
> --rm -v ${PWD}:${PWD} -v${PWD}/cachefiles:/root/.cache/miopen/2.9.0 -w
> ${PWD} gcn-gpu python3 generate_cachefiles.py
> [--gfx-version={gfx801,gfx803}] [--num-cus=4] cachefiles.csv
> usage: generate_cachefiles.py [-h] [--num-cus NUM_CUS]
>   [--gfx-version {gfx801,gfx803,gfx900}]
>   csv_file
> generate_cachefiles.py: error: unrecognized arguments:
> [--gfx-version=gfx803] [--num-cus=4] cachefiles.csv
>
>   May i ask for the correct usage?
>
> Thank you!
>
> -- 原始邮件 --
> *发件人:* "The gem5 Users mailing list" ;
> *发送时间:* 2023年4月25日(星期二) 上午8:53
> *收件人:* "429442672"<429442...@qq.com>;
> *抄送:* "The gem5 Developer List";"gem5-users"<
> gem5-us...@gem5.org>;"Matt Sinclair";
> *主题:* [gem5-users] Re: [gem5-dev] Hi, i'm new to gem5. is there a way to
> make simulation for a CPU-GPU heterogeneous computing？
>
> 1.  I am not personally aware of any CPU-FPGA support, but maybe others on
> this mailing list can chime in if they are aware of it.
>
> 2.  gem5 already has support for some small ML workloads.  For example
> DNNMark (https://resources.gem5.org/resources/dnn-mark) is already
> integrated into gem5-resources.  I know DeepBench works too, although my
> group has not had time to integrate them into gem5-resources yet.  However,
> larger workloads (e.g., ResNet, AlexNet) do not work yet.  We've spent a
> lot of time getting things like that running in SE mode, but since the ROCm
> versions keep changing, we decided to invest our time in getting GPU FS
> mode support working first, so we didn't have to get new syscalls working
> over and over. For example, in ROCm 1.6, I was able to get ResNet18 to run
> into the 18th layer, but then there were a number of additional failures
> that needed tending to, which we haven't gotten around to fixing.
>
> Matt
>
> On Sun, Apr 23, 2023 at 8:42 PM 429442672 <429442...@qq.com> wrote:
>
>> Thank you so much, i will follow your guide to make some trials.
>>
>> By the way, i have a few more questions:
>>
>> 1. Does current Gem5 support simulating CPU-FPGA heterogeneous
>> computing, if it is possible, could you please show me a way or url?
>>
>> 2. Is Gem5 able to simulate deep learning workload?
>>
>>
>> -- 原始邮件 --
>> *发件人:* "Matt Sinclair" ;
>> *发送时间:* 2023年4月20日(星期四) 中午12:04
>> *收件人:* "The gem5 Developer List";
>> *抄送:* "gem5-users";"429442672"<429442...@qq.com>;
>> *主题:* Re: [gem5-dev] Hi, i'm new to gem5. is there a way to make
>> simulation for a CPU-GPU heterogeneous computing？
>>
>> Yes, all of the “GPU” examples posted on gem5-resources do this, for both
>> GCN3 and Vega models.  For 

[gem5-dev] Re: Hi, i'm new to gem5. is there a way to make simulation for a CPU-GPU heterogeneous computing？

[Matt Sinclair via gem5-dev]

1.  I am not personally aware of any CPU-FPGA support, but maybe others on
this mailing list can chime in if they are aware of it.

2.  gem5 already has support for some small ML workloads.  For example
DNNMark (https://resources.gem5.org/resources/dnn-mark) is already
integrated into gem5-resources.  I know DeepBench works too, although my
group has not had time to integrate them into gem5-resources yet.  However,
larger workloads (e.g., ResNet, AlexNet) do not work yet.  We've spent a
lot of time getting things like that running in SE mode, but since the ROCm
versions keep changing, we decided to invest our time in getting GPU FS
mode support working first, so we didn't have to get new syscalls working
over and over. For example, in ROCm 1.6, I was able to get ResNet18 to run
into the 18th layer, but then there were a number of additional failures
that needed tending to, which we haven't gotten around to fixing.

Matt

On Sun, Apr 23, 2023 at 8:42 PM 429442672 <429442...@qq.com> wrote:

> Thank you so much, i will follow your guide to make some trials.
>
> By the way, i have a few more questions:
>
> 1. Does current Gem5 support simulating CPU-FPGA heterogeneous computing,
> if it is possible, could you please show me a way or url?
>
> 2. Is Gem5 able to simulate deep learning workload?
>
>
> -- 原始邮件 --
> *发件人:* "Matt Sinclair" ;
> *发送时间:* 2023年4月20日(星期四) 中午12:04
> *收件人:* "The gem5 Developer List";
> *抄送:* "gem5-users";"429442672"<429442...@qq.com>;
> *主题:* Re: [gem5-dev] Hi, i'm new to gem5. is there a way to make
> simulation for a CPU-GPU heterogeneous computing？
>
> Yes, all of the “GPU” examples posted on gem5-resources do this, for both
> GCN3 and Vega models.  For example, I usually recommend people start with
> square: https://resources.gem5.org/resources/square
>
>
>
> You can find many more examples of this on the homepage of gem5 resources
> too: https://resources.gem5.org/
>
>
>
> Hope this helps,
>
> Matt
>
> On Wed, Apr 19, 2023 at 10:58 PM 429442672 via gem5-dev 
> wrote:
>
>> i'm new to gem5. May i ask is there a way to make simulation for a
>> CPU-GPU heterogeneous computing？ the gem5-gpu is too old and poorly
>> maintained, so it is better to use GCN3, in ES mode.
>>
>>
>> For example, i want to simulate that:
>>
>> 1.CPU load several data from CPU memory and handle them.
>>
>> 2.CPU send them to GPU memory
>>
>> 3.GPU fetch data from GPU memory and handle them.
>>
>> 4.GPU write the data back to CPU memory
>>
>>
>> Is there a way to achieve this in Gem5?
>>
>> Sincerely ask for help.
>>
>> I find no example about CPU-GPU heterogeneous computing. Is there any
>> example here?
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Hi, i'm new to gem5. is there a way to make simulation for a CPU-GPU heterogeneous computing？

[Matt Sinclair via gem5-dev]

Yes, all of the “GPU” examples posted on gem5-resources do this, for both
GCN3 and Vega models.  For example, I usually recommend people start with
square: https://resources.gem5.org/resources/square



You can find many more examples of this on the homepage of gem5 resources
too: https://resources.gem5.org/



Hope this helps,

Matt

On Wed, Apr 19, 2023 at 10:58 PM 429442672 via gem5-dev 
wrote:

> i'm new to gem5. May i ask is there a way to make simulation for a CPU-GPU
> heterogeneous computing？ the gem5-gpu is too old and poorly maintained, so
> it is better to use GCN3, in ES mode.
>
>
> For example, i want to simulate that:
>
> 1.CPU load several data from CPU memory and handle them.
>
> 2.CPU send them to GPU memory
>
> 3.GPU fetch data from GPU memory and handle them.
>
> 4.GPU write the data back to CPU memory
>
>
> Is there a way to achieve this in Gem5?
>
> Sincerely ask for help.
>
> I find no example about CPU-GPU heterogeneous computing. Is there any
> example here?
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #566

[Matt Sinclair via gem5-dev]

Sounds good, thanks for letting me know.

Matt

On Wed, Apr 5, 2023 at 12:13 PM Bobby Bruce  wrote:

> I don’t know the exact cause of this problem but it’s a Docker failure of
> some kind and likely not due to any actual test failure. These just happen
> very so often on our Jenkin’s setup and they are impossible to recreate
> locally. It could be Docker running out of member (though it should have
> ample) or the service just being interrupted by something. I’ve never
> managed to figure out why or how to resolve it but they happen every so
> often. I suspect the Nightly tests will pass tonight.
>
> I’m currently working on Migrating out tests to run via GitHub actions.
> I’m hoping this setup allows us to sidesteps all these funny little things
> that happen when running Docker in Jenkins.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
> On Apr 5, 2023, at 7:55 AM, Matt Sinclair 
> wrote:
>
> Hi Bobby,
>
> I'm trying to interpret the console output here, as it seems like the
> replacement policy tests are failing:
>
> ...
>
> *03:41:45* Test: 
> test-replacement-policy-traces/tree_plru_test1_st-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>  Passed*04:02:55* time="2023-04-05T04:02:55-05:00" level=error msg="error 
> waiting for container: "*04:02:55* Build step 'Execute shell' marked build as 
> failure
>
> ...
>
> What does "Execute shell" refer to?  Is it just the next thing after the
> replacement policy tests that is failing?
>
> Thanks,
> Matt
>
> On Wed, Apr 5, 2023 at 4:04 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/566/display/redirect?page=changes>
>>
>> Changes:
>>
>> [humzajahangirikram] stdlib: Small fix in stdlib spec2006 script
>>
>> [mattdsinclair] mem-ruby: fix whitespacing errors in RubySystem
>>
>> [gabe.black] base: Abstract the AF_INET-ness out of ListenSocket.
>>
>>
>> --
>> [...truncated 2.46 MB...]
>> Test:
>> test-replacement-policy-traces/lfu_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5outxv9s3_65 -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/lfu_test2_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lfu_test2_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example
>> Starting Test Case:
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outxv9s3_65/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/lfu_test2_ld
>> Test:
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5out8el_uqrg -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/lfu_test3_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lfu_test3_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example
>> Starting Test Case:
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5out8el_uqrg/simout
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/lfu_test3_ld
>> Test:
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
>> /tmp/gem5outnoz1lhkk -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>> traces/lip_test1_ld
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lip_test1_ld.py
>> Starting Test Suite:
>> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example
>> Starting Test Case:
>> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example
>> Test:
>> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example
>> Passed
>> Starting Test Case:
>> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: 

[gem5-dev] Re: Build failed in Jenkins: nightly #566

[Matt Sinclair via gem5-dev]

Hi Bobby,

I'm trying to interpret the console output here, as it seems like the
replacement policy tests are failing:

...

*03:41:45* Test:
test-replacement-policy-traces/tree_plru_test1_st-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
Passed*04:02:55* time="2023-04-05T04:02:55-05:00" level=error
msg="error waiting for container: "*04:02:55* Build step 'Execute
shell' marked build as failure

...

What does "Execute shell" refer to?  Is it just the next thing after the
replacement policy tests that is failing?

Thanks,
Matt

On Wed, Apr 5, 2023 at 4:04 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/566/display/redirect?page=changes>
>
> Changes:
>
> [humzajahangirikram] stdlib: Small fix in stdlib spec2006 script
>
> [mattdsinclair] mem-ruby: fix whitespacing errors in RubySystem
>
> [gabe.black] base: Abstract the AF_INET-ness out of ListenSocket.
>
>
> --
> [...truncated 2.46 MB...]
> Test:
> test-replacement-policy-traces/lfu_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5outxv9s3_65 -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
> traces/lfu_test2_ld
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lfu_test2_ld.py
> Starting Test Suite:
> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example
> Starting Test Case:
> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5outxv9s3_65/simout
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/lfu_test2_ld
> Test:
> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5out8el_uqrg -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
> traces/lfu_test3_ld
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lfu_test3_ld.py
> Starting Test Suite:
> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example
> Starting Test Case:
> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5out8el_uqrg/simout
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/lfu_test3_ld
> Test:
> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5outnoz1lhkk -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
> traces/lip_test1_ld
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lip_test1_ld.py
> Starting Test Suite:
> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example
> Starting Test Case:
> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5outnoz1lhkk/simout
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/lip_test1_ld
> Test:
> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d
> /tmp/gem5out1hv4053r -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
> traces/lru_test1_ld
> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lru_test1_ld.py
> Starting Test Suite:
> test-replacement-policy-traces/lru_test1_ld-NULL-x86_64-opt-MI_example
> Starting Test Case:
> test-replacement-policy-traces/lru_test1_ld-NULL-x86_64-opt-MI_example
> Test:
> test-replacement-policy-traces/lru_test1_ld-NULL-x86_64-opt-MI_example
> Passed
> Starting Test Case:
> test-replacement-policy-traces/lru_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
> Logging call to command: diff /tmp/gem5out1hv4053r/simout
> 

[gem5-dev] Re: Build failed in Jenkins: nightly #482

[Matt Sinclair via gem5-dev]

No problem, great.

Matt

On Fri, Jan 13, 2023 at 8:18 AM Bobby Bruce  wrote:

> Sorry for the delay. Yesterday I cleared up some space on the server. We
> shouldn't see space issue again.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Thu, Jan 12, 2023 at 7:04 PM Matt Sinclair <
> mattdsinclair.w...@gmail.com> wrote:
>
>> Hi Bobby,
>>
>> Just checking on this again.
>>
>> Thanks,
>> Matt
>>
>> On Mon, Jan 9, 2023 at 11:21 PM Matt Sinclair <
>> mattdsinclair.w...@gmail.com> wrote:
>>
>>> Bobby do you need me to clean up the machine or open a ticket with IT at
>>> UW:
>>>
>>> *19:22:13* {standard input}: Fatal error: can't write 97 bytes to section 
>>> .text of build/ARM/python/_m5/param_TickedObject.o: 'No space left on 
>>> device'
>>>
>>> Matt
>>>
>>> On Mon, Jan 9, 2023 at 7:23 PM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 See <
 https://jenkins.gem5.org/job/nightly/482/display/redirect?page=changes>

 Changes:

 [mattdsinclair] mem-ruby, gpu-compute: fix TCP GLC cache bypassing

 [mattdsinclair] mem-ruby: fix TCP spacing/spelling

 [mattdsinclair] mem-ruby: add GPU cache bypass I->I transition


 --
 [...truncated 4.09 MB...]
  [SO Param] m5.objects.Cache_Controller, Cache_Controller ->
 ARM/python/_m5/param_Cache_Controller.cc
  [ CXX] ARM/mem/ruby/protocol/Cache_DirEntry.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_Event.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_ReplacementMsg.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_RequestType.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_RetryQueueEntry.cc -> .o
  [ CXX] ARM/python/_m5/param_Cache_Controller.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_RetryTriggerMsg.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_State.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_TBE.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_Transitions.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_TriggerMsg.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Cache_Wakeup.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/DMASequencerRequestType.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/DirectoryRequestType.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/HtmCallbackMode.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/HtmFailedInCacheReason.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/InvalidateGeneratorStatus.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/LinkDirection.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/LockStatus.cc -> .o
  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
 ARM/params/Memory_Controller.hh
  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
 ARM/params/MiscNode_Controller.hh
  [ CXX] ARM/mem/ruby/protocol/MaskPredictorIndex.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MaskPredictorTraining.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MaskPredictorType.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MemoryControlRequestType.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MemoryMsg.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MemoryRequestType.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MachineType.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.py.cc -> .o
  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
 ARM/python/_m5/param_Memory_Controller.cc
  [ CXX] ARM/mem/ruby/protocol/Memory_Event.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_RetryQueueEntry.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_State.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_TBE.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_Transitions.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_TriggerMsg.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/Memory_Wakeup.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MessageSizeType.cc -> .o
  [ CXX] ARM/python/_m5/param_Memory_Controller.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.py.cc -> .o
  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
 ARM/python/_m5/param_MiscNode_Controller.cc
  [ CXX] ARM/mem/ruby/protocol/MiscNode_Event.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryQueueEntry.cc -> .o
  [ CXX] ARM/python/_m5/param_MiscNode_Controller.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryTriggerMsg.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MiscNode_State.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MiscNode_TBE.cc -> .o
  [ CXX] ARM/mem/ruby/protocol/MiscNode_Transitions.cc -> .o
  [ CXX] 

[gem5-dev] Re: Build failed in Jenkins: nightly #482

[Matt Sinclair via gem5-dev]

Hi Bobby,

Just checking on this again.

Thanks,
Matt

On Mon, Jan 9, 2023 at 11:21 PM Matt Sinclair 
wrote:

> Bobby do you need me to clean up the machine or open a ticket with IT at
> UW:
>
> *19:22:13* {standard input}: Fatal error: can't write 97 bytes to section 
> .text of build/ARM/python/_m5/param_TickedObject.o: 'No space left on device'
>
> Matt
>
> On Mon, Jan 9, 2023 at 7:23 PM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/482/display/redirect?page=changes>
>>
>> Changes:
>>
>> [mattdsinclair] mem-ruby, gpu-compute: fix TCP GLC cache bypassing
>>
>> [mattdsinclair] mem-ruby: fix TCP spacing/spelling
>>
>> [mattdsinclair] mem-ruby: add GPU cache bypass I->I transition
>>
>>
>> --
>> [...truncated 4.09 MB...]
>>  [SO Param] m5.objects.Cache_Controller, Cache_Controller ->
>> ARM/python/_m5/param_Cache_Controller.cc
>>  [ CXX] ARM/mem/ruby/protocol/Cache_DirEntry.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_Event.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_ReplacementMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_RequestType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_RetryQueueEntry.cc -> .o
>>  [ CXX] ARM/python/_m5/param_Cache_Controller.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_RetryTriggerMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_State.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_TBE.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_Transitions.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_TriggerMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Cache_Wakeup.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/DMASequencerRequestType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/DirectoryRequestType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/HtmCallbackMode.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/HtmFailedInCacheReason.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/InvalidateGeneratorStatus.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/LinkDirection.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/LockStatus.cc -> .o
>>  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
>> ARM/params/Memory_Controller.hh
>>  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
>> ARM/params/MiscNode_Controller.hh
>>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorIndex.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorTraining.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MemoryControlRequestType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MemoryMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MemoryRequestType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MachineType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.py.cc -> .o
>>  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
>> ARM/python/_m5/param_Memory_Controller.cc
>>  [ CXX] ARM/mem/ruby/protocol/Memory_Event.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_RetryQueueEntry.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_State.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_TBE.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_Transitions.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_TriggerMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/Memory_Wakeup.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MessageSizeType.cc -> .o
>>  [ CXX] ARM/python/_m5/param_Memory_Controller.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.py.cc -> .o
>>  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
>> ARM/python/_m5/param_MiscNode_Controller.cc
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Event.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryQueueEntry.cc -> .o
>>  [ CXX] ARM/python/_m5/param_MiscNode_Controller.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryTriggerMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_State.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_TBE.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Transitions.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_TriggerMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Wakeup.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/PrefetchBit.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/RequestStatus.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/RubyAccessMode.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/RubyRequestType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/SequencerMsg.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/SequencerRequestType.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/SequencerStatus.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/SeriesRequestGeneratorStatus.cc -> .o
>>  [ CXX] ARM/mem/ruby/protocol/TesterStatus.cc 

[gem5-dev] Re: Build failed in Jenkins: nightly #482

[Matt Sinclair via gem5-dev]

Bobby do you need me to clean up the machine or open a ticket with IT at UW:

*19:22:13* {standard input}: Fatal error: can't write 97 bytes to
section .text of build/ARM/python/_m5/param_TickedObject.o: 'No space
left on device'

Matt

On Mon, Jan 9, 2023 at 7:23 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/482/display/redirect?page=changes>
>
> Changes:
>
> [mattdsinclair] mem-ruby, gpu-compute: fix TCP GLC cache bypassing
>
> [mattdsinclair] mem-ruby: fix TCP spacing/spelling
>
> [mattdsinclair] mem-ruby: add GPU cache bypass I->I transition
>
>
> --
> [...truncated 4.09 MB...]
>  [SO Param] m5.objects.Cache_Controller, Cache_Controller ->
> ARM/python/_m5/param_Cache_Controller.cc
>  [ CXX] ARM/mem/ruby/protocol/Cache_DirEntry.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_Event.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_ReplacementMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_RequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_RetryQueueEntry.cc -> .o
>  [ CXX] ARM/python/_m5/param_Cache_Controller.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_RetryTriggerMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_State.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_TBE.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_Transitions.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_TriggerMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Cache_Wakeup.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/DMASequencerRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/DirectoryRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/HtmCallbackMode.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/HtmFailedInCacheReason.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/InvalidateGeneratorStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/LinkDirection.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/LockStatus.cc -> .o
>  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
> ARM/params/Memory_Controller.hh
>  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
> ARM/params/MiscNode_Controller.hh
>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorIndex.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorTraining.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MemoryControlRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MemoryMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MemoryRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MachineType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.py.cc -> .o
>  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
> ARM/python/_m5/param_Memory_Controller.cc
>  [ CXX] ARM/mem/ruby/protocol/Memory_Event.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_RetryQueueEntry.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_State.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_TBE.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_Transitions.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_TriggerMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/Memory_Wakeup.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MessageSizeType.cc -> .o
>  [ CXX] ARM/python/_m5/param_Memory_Controller.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.py.cc -> .o
>  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
> ARM/python/_m5/param_MiscNode_Controller.cc
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Event.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryQueueEntry.cc -> .o
>  [ CXX] ARM/python/_m5/param_MiscNode_Controller.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryTriggerMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_State.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_TBE.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Transitions.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_TriggerMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Wakeup.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/PrefetchBit.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/RequestStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/RubyAccessMode.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/RubyRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SequencerMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SequencerRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SequencerStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SeriesRequestGeneratorStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/TesterStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/TransitionResult.cc -> .o
>  [ CXX] ARM/mem/probes/BaseMemProbe.py.cc -> .o
>  [SO Param] m5.objects.BaseMemProbe, BaseMemProbe ->
> 

[gem5-dev] Re: Build failed in Jenkins: weekly #99

[Matt Sinclair via gem5-dev]

Thanks all.  I have validated all weekly and nightly GPU tests pass with my
changes.

Matt P: we should probably figure out if all tests pass on Vega now, and if
so move to Vega for nightly and weekly.  My recollection is some workloads
(Pennant?) were failing with Vega last time we tried?

Matt

On Mon, Jan 9, 2023 at 10:46 AM Poremba, Matthew 
wrote:

> [AMD Official Use Only - General]
>
>
>
> Thanks all, it looks like everything was taken care of over the weekend.
>
>
>
> To answer MattS’ question: I’ve tested weekly on most of my changes and
> haven’t found any issues.  I’ve been primarily making arch-vega changes and
> the weekly tester only tests gcn3 by default though.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Bobby Bruce 
> *Sent:* Monday, January 9, 2023 7:59 AM
> *To:* The gem5 Developer List 
> *Cc:* Jason Lowe-Power ; Poremba, Matthew <
> matthew.pore...@amd.com>; vrama...@wisc.edu; Matt Sinclair <
> mattdsinclair.w...@gmail.com>
> *Subject:* Re: [gem5-dev] Re: Build failed in Jenkins: weekly #99
>
>
>
> *Caution:* This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
>
> Thanks Matt!
>
>
>
> I've restarted the Weeklys to ensure it's now working. Should be complete
> over the next day or two.
>
>
>
> --
>
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
>
> web: https://www.bobbybruce.net
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bobbybruce.net%2F=05%7C01%7CMatthew.Poremba%40amd.com%7Cff4c7fc844b843dc3b6508daf25a8462%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638088767854623756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Wxw5ByN%2BTeiOQC4FczRdTg0RA28U5gsznTB9Ax3VofY%3D=0>
>
>
>
>
>
> On Sun, Jan 8, 2023 at 12:48 AM Matt Sinclair via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> The chain for the fixes for weekly is here:
> https://gem5-review.googlesource.com/c/public/gem5/+/67199/1
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5-review.googlesource.com%2Fc%2Fpublic%2Fgem5%2F%2B%2F67199%2F1=05%7C01%7CMatthew.Poremba%40amd.com%7Cff4c7fc844b843dc3b6508daf25a8462%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638088767854623756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3%2Fvkw6vJ0TdIsMSo8OrBtZf7oTBa4kO%2F4fz5xQ1ep8Q%3D=0>
>
>
>
> I have tested that BC gets past the current failure with these 3 fixes
> (previously BC failed in an initialization kernel before the first
> iteration started, so far with the change it completes the first 107/128
> iterations ... hopefully the last few go smoothly as well).  Obviously I
> have not tested the entire weekly script yet though since that takes
> multiple days.  I will run that in parallel with these being reviewed.
>
>
>
> Matt
>
>
>
> On Sat, Jan 7, 2023 at 4:12 PM Jason Lowe-Power 
> wrote:
>
> Thanks for quickly digging into this, Matt!
>
>
>
> On Sat, Jan 7, 2023 at 1:41 PM Matt Sinclair via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> I have confirmed that the Pannotia benchmarks (to my surprise) are using
> AMD's cache bypassing flags for some memory accesses, which Vishnu added
> support for this week.  Good thing the support is added now!  But that is
> why they are failing here -- they hit a corner case Vishnu and I had
> considered, but implemented incorrectly.  I have a fix I am testing now and
> will push later tonight assuming it solves the problem.
>
>
>
> Matt
>
>
>
> On Fri, Jan 6, 2023 at 10:07 PM Matt Sinclair <
> mattdsinclair.w...@gmail.com> wrote:
>
> Hi Matt P & Vishnu,
>
>
>
> It appears something with the GPU support must have broken between your
> changes this week -- as far as I can tell all of the nightly tests passed
> when you checked in your commits, but something in the more complex
> benchmarks (BC in this case) is breaking:
>
> gem5.opt: build/GCN3_X86/mem/ruby/system/VIPERCoalescer.cc:265: void 
> gem5::ruby::VIPERCoalescer::invTCPCallback(gem5::Addr): Assertion 
> `m_cache_inv_pkt && m_num_pending_invs > 0' failed.
>
> Vishnu, did you test your changes with the weekly tests at all?
>
>
>
> Matt P did you test your changes with the weekly tests at all?  And have
> you started bisecting yet to find the offending commit?
>
>
>
> If not, Vishnu I can show you how to do this.  I will be away next week
> (although with intermittent email access) so a fix relying on me may be
> delayed ... but ho

[gem5-dev] Re: Build failed in Jenkins: weekly #99

[Matt Sinclair via gem5-dev]

The chain for the fixes for weekly is here:
https://gem5-review.googlesource.com/c/public/gem5/+/67199/1

I have tested that BC gets past the current failure with these 3 fixes
(previously BC failed in an initialization kernel before the first
iteration started, so far with the change it completes the first 107/128
iterations ... hopefully the last few go smoothly as well).  Obviously I
have not tested the entire weekly script yet though since that takes
multiple days.  I will run that in parallel with these being reviewed.

Matt

On Sat, Jan 7, 2023 at 4:12 PM Jason Lowe-Power  wrote:

> Thanks for quickly digging into this, Matt!
>
> On Sat, Jan 7, 2023 at 1:41 PM Matt Sinclair via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> I have confirmed that the Pannotia benchmarks (to my surprise) are using
>> AMD's cache bypassing flags for some memory accesses, which Vishnu added
>> support for this week.  Good thing the support is added now!  But that is
>> why they are failing here -- they hit a corner case Vishnu and I had
>> considered, but implemented incorrectly.  I have a fix I am testing now and
>> will push later tonight assuming it solves the problem.
>>
>> Matt
>>
>> On Fri, Jan 6, 2023 at 10:07 PM Matt Sinclair <
>> mattdsinclair.w...@gmail.com> wrote:
>>
>>> Hi Matt P & Vishnu,
>>>
>>> It appears something with the GPU support must have broken between your
>>> changes this week -- as far as I can tell all of the nightly tests passed
>>> when you checked in your commits, but something in the more complex
>>> benchmarks (BC in this case) is breaking:
>>>
>>> gem5.opt: build/GCN3_X86/mem/ruby/system/VIPERCoalescer.cc:265: void 
>>> gem5::ruby::VIPERCoalescer::invTCPCallback(gem5::Addr): Assertion 
>>> `m_cache_inv_pkt && m_num_pending_invs > 0' failed.
>>>
>>> Vishnu, did you test your changes with the weekly tests at all?
>>>
>>> Matt P did you test your changes with the weekly tests at all?  And have
>>> you started bisecting yet to find the offending commit?
>>>
>>> If not, Vishnu I can show you how to do this.  I will be away next week
>>> (although with intermittent email access) so a fix relying on me may be
>>> delayed ... but hopefully between the three of us we can isolate and figure
>>> out which commit is causing/fixing.  My intuition says that it's probably
>>> one of Vishnu's commits, since Matt P's aren't changing the coherence
>>> protocol at all, but it's not obvious why Vishnu's commits would be
>>> affecting the invalidation calls at all ...
>>>
>>> Thanks,
>>> Matt S.
>>>
>>> On Fri, Jan 6, 2023 at 9:54 PM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> See <
>>>> https://jenkins.gem5.org/job/weekly/99/display/redirect?page=changes>
>>>>
>>>> Changes:
>>>>
>>>> [Bobby R. Bruce] ext: Fix SST Documentation links
>>>>
>>>> [Bobby R. Bruce] tests: Fix the download test
>>>>
>>>> [Bobby R. Bruce] stdlib: Removing incorrect requires.
>>>>
>>>> [Bobby R. Bruce] stdlib: se_binary_workload exits on work items by
>>>> default
>>>>
>>>> [Bobby R. Bruce] configs: Fix unconnected PCI port in SST gem5 config
>>>>
>>>> [Bobby R. Bruce] mem: Add getAddrRanges in HBMCtrl
>>>>
>>>> [Bobby R. Bruce] system-arm: Fix FEAT_PAuth trapping in AArch64
>>>> bootloader
>>>>
>>>> [Bobby R. Bruce] misc: Update version info to v22.0.0.2
>>>>
>>>> [Bobby R. Bruce] misc: Update RELEASE-NOTES.md for v22.0.0.2
>>>>
>>>> [Bobby R. Bruce] stdlib: Fix get_isa_from_str() exception behavior in
>>>> isas.py
>>>>
>>>> [Bobby R. Bruce] dev-amdgpu: Handle ring buffer wrap for PM4 queue
>>>>
>>>> [Bobby R. Bruce] arch-vega: Fix SOPK instruction sign extends
>>>>
>>>> [Bobby R. Bruce] dev-amdgpu: Fix SDMA ring buffer wrap around
>>>>
>>>> [Bobby R. Bruce] arch-x86: X86ISA default vector_string to HygonGenuine
>>>>
>>>> [Bobby R. Bruce] arch-arm: Revert 'Setup TC/ISA at construction time..'
>>>>
>>>> [Bobby R. Bruce] stdlib,configs: Update riscvmatched-fs example
>>>> docstring
>>>>
>>>> [Bobby R. Bruce] configs,stdlib: Fix import in riscvmatched-fs.py
>>>>
>>>> [Bobby R. Bruce] configs,stdlib,tes

[gem5-dev] Re: Build failed in Jenkins: weekly #99

[Matt Sinclair via gem5-dev]

I have confirmed that the Pannotia benchmarks (to my surprise) are using
AMD's cache bypassing flags for some memory accesses, which Vishnu added
support for this week.  Good thing the support is added now!  But that is
why they are failing here -- they hit a corner case Vishnu and I had
considered, but implemented incorrectly.  I have a fix I am testing now and
will push later tonight assuming it solves the problem.

Matt

On Fri, Jan 6, 2023 at 10:07 PM Matt Sinclair 
wrote:

> Hi Matt P & Vishnu,
>
> It appears something with the GPU support must have broken between your
> changes this week -- as far as I can tell all of the nightly tests passed
> when you checked in your commits, but something in the more complex
> benchmarks (BC in this case) is breaking:
>
> gem5.opt: build/GCN3_X86/mem/ruby/system/VIPERCoalescer.cc:265: void 
> gem5::ruby::VIPERCoalescer::invTCPCallback(gem5::Addr): Assertion 
> `m_cache_inv_pkt && m_num_pending_invs > 0' failed.
>
> Vishnu, did you test your changes with the weekly tests at all?
>
> Matt P did you test your changes with the weekly tests at all?  And have
> you started bisecting yet to find the offending commit?
>
> If not, Vishnu I can show you how to do this.  I will be away next week
> (although with intermittent email access) so a fix relying on me may be
> delayed ... but hopefully between the three of us we can isolate and figure
> out which commit is causing/fixing.  My intuition says that it's probably
> one of Vishnu's commits, since Matt P's aren't changing the coherence
> protocol at all, but it's not obvious why Vishnu's commits would be
> affecting the invalidation calls at all ...
>
> Thanks,
> Matt S.
>
> On Fri, Jan 6, 2023 at 9:54 PM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See > >
>>
>> Changes:
>>
>> [Bobby R. Bruce] ext: Fix SST Documentation links
>>
>> [Bobby R. Bruce] tests: Fix the download test
>>
>> [Bobby R. Bruce] stdlib: Removing incorrect requires.
>>
>> [Bobby R. Bruce] stdlib: se_binary_workload exits on work items by default
>>
>> [Bobby R. Bruce] configs: Fix unconnected PCI port in SST gem5 config
>>
>> [Bobby R. Bruce] mem: Add getAddrRanges in HBMCtrl
>>
>> [Bobby R. Bruce] system-arm: Fix FEAT_PAuth trapping in AArch64 bootloader
>>
>> [Bobby R. Bruce] misc: Update version info to v22.0.0.2
>>
>> [Bobby R. Bruce] misc: Update RELEASE-NOTES.md for v22.0.0.2
>>
>> [Bobby R. Bruce] stdlib: Fix get_isa_from_str() exception behavior in
>> isas.py
>>
>> [Bobby R. Bruce] dev-amdgpu: Handle ring buffer wrap for PM4 queue
>>
>> [Bobby R. Bruce] arch-vega: Fix SOPK instruction sign extends
>>
>> [Bobby R. Bruce] dev-amdgpu: Fix SDMA ring buffer wrap around
>>
>> [Bobby R. Bruce] arch-x86: X86ISA default vector_string to HygonGenuine
>>
>> [Bobby R. Bruce] arch-arm: Revert 'Setup TC/ISA at construction time..'
>>
>> [Bobby R. Bruce] stdlib,configs: Update riscvmatched-fs example docstring
>>
>> [Bobby R. Bruce] configs,stdlib: Fix import in riscvmatched-fs.py
>>
>> [Bobby R. Bruce] configs,stdlib,tests: Update riscvmatched-fs.py to-init
>>
>> [Bobby R. Bruce] tests: Update riscvmatched tests to use ALL/gem5.opt
>>
>> [Bobby R. Bruce] configs: Add missing `_pre_instantiate` call in
>> "run_lupv.py"
>>
>> [Bobby R. Bruce] tests: Delete build directory before running KVM in
>> nightly
>>
>> [Bobby R. Bruce] configs: Set CPU vendor to M5 Simulator in apu_se.py
>>
>> [Bobby R. Bruce] stdlib,python: Allow setting of to tick exits via m5
>>
>> [Bobby R. Bruce] stdlib, configs: Updating configs/example/gem5_library
>>
>> [Bobby R. Bruce] arch-arm: Setup TC/ISA at construction time 2nd attempt
>>
>> [Bobby R. Bruce] scons: Remove -Werror for the gem5 v22.1 release
>>
>> [Bobby R. Bruce] base: Update the version to v22.1.0.0
>>
>> [Bobby R. Bruce] python,tests: Update Resource URL path to v22-1
>>
>> [Bobby R. Bruce] stdlib: Update the gem5 resources' version to "v22.1"
>>
>> [Bobby R. Bruce] util-docker: Update gcn-gpu Docker to use v22-1 ROCM
>> patch
>>
>> [Bobby R. Bruce] util-docker: Add v22-1 tag to docker-compose.yaml
>>
>> [Bobby R. Bruce] tests: Update the compiler-tests.sh to use the v22-1
>> images
>>
>> [Bobby R. Bruce] tests: Abstract the docker image tag for Nightly tests
>>
>> [Bobby R. Bruce] tests: Update nightly test docker image tags to v22-1
>>
>> [Bobby R. Bruce] tests: Abstract the docker image tag for Weekly tests
>>
>> [Bobby R. Bruce] tests: Update weekly test docker image tags to v22-1
>>
>> [Bobby R. Bruce] util-gem5art: Fix incorrect type of size in
>> `createArtifact`
>>
>> [Bobby R. Bruce] tests: Update presubmit.sh to use v22-1 docker images
>>
>> [Bobby R. Bruce] ext: Update ext/sst/README.md for v22.1 release
>>
>> [Bobby R. Bruce] python: Remove 'scheduleTickExit' in favor of
>> 'exitSimLoop'
>>
>> [Bobby R. Bruce] configs: Fix x86-gapbs-benchmarks.py example
>>
>> [Bobby R. Bruce] configs: Alter x86-npb-benchmarks.py 

[gem5-dev] Re: Build failed in Jenkins: weekly #99

[Matt Sinclair via gem5-dev]

Hi Matt P & Vishnu,

It appears something with the GPU support must have broken between your
changes this week -- as far as I can tell all of the nightly tests passed
when you checked in your commits, but something in the more complex
benchmarks (BC in this case) is breaking:

gem5.opt: build/GCN3_X86/mem/ruby/system/VIPERCoalescer.cc:265: void
gem5::ruby::VIPERCoalescer::invTCPCallback(gem5::Addr): Assertion
`m_cache_inv_pkt && m_num_pending_invs > 0' failed.

Vishnu, did you test your changes with the weekly tests at all?

Matt P did you test your changes with the weekly tests at all?  And have
you started bisecting yet to find the offending commit?

If not, Vishnu I can show you how to do this.  I will be away next week
(although with intermittent email access) so a fix relying on me may be
delayed ... but hopefully between the three of us we can isolate and figure
out which commit is causing/fixing.  My intuition says that it's probably
one of Vishnu's commits, since Matt P's aren't changing the coherence
protocol at all, but it's not obvious why Vishnu's commits would be
affecting the invalidation calls at all ...

Thanks,
Matt S.

On Fri, Jan 6, 2023 at 9:54 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
> [Bobby R. Bruce] ext: Fix SST Documentation links
>
> [Bobby R. Bruce] tests: Fix the download test
>
> [Bobby R. Bruce] stdlib: Removing incorrect requires.
>
> [Bobby R. Bruce] stdlib: se_binary_workload exits on work items by default
>
> [Bobby R. Bruce] configs: Fix unconnected PCI port in SST gem5 config
>
> [Bobby R. Bruce] mem: Add getAddrRanges in HBMCtrl
>
> [Bobby R. Bruce] system-arm: Fix FEAT_PAuth trapping in AArch64 bootloader
>
> [Bobby R. Bruce] misc: Update version info to v22.0.0.2
>
> [Bobby R. Bruce] misc: Update RELEASE-NOTES.md for v22.0.0.2
>
> [Bobby R. Bruce] stdlib: Fix get_isa_from_str() exception behavior in
> isas.py
>
> [Bobby R. Bruce] dev-amdgpu: Handle ring buffer wrap for PM4 queue
>
> [Bobby R. Bruce] arch-vega: Fix SOPK instruction sign extends
>
> [Bobby R. Bruce] dev-amdgpu: Fix SDMA ring buffer wrap around
>
> [Bobby R. Bruce] arch-x86: X86ISA default vector_string to HygonGenuine
>
> [Bobby R. Bruce] arch-arm: Revert 'Setup TC/ISA at construction time..'
>
> [Bobby R. Bruce] stdlib,configs: Update riscvmatched-fs example docstring
>
> [Bobby R. Bruce] configs,stdlib: Fix import in riscvmatched-fs.py
>
> [Bobby R. Bruce] configs,stdlib,tests: Update riscvmatched-fs.py to-init
>
> [Bobby R. Bruce] tests: Update riscvmatched tests to use ALL/gem5.opt
>
> [Bobby R. Bruce] configs: Add missing `_pre_instantiate` call in
> "run_lupv.py"
>
> [Bobby R. Bruce] tests: Delete build directory before running KVM in
> nightly
>
> [Bobby R. Bruce] configs: Set CPU vendor to M5 Simulator in apu_se.py
>
> [Bobby R. Bruce] stdlib,python: Allow setting of to tick exits via m5
>
> [Bobby R. Bruce] stdlib, configs: Updating configs/example/gem5_library
>
> [Bobby R. Bruce] arch-arm: Setup TC/ISA at construction time 2nd attempt
>
> [Bobby R. Bruce] scons: Remove -Werror for the gem5 v22.1 release
>
> [Bobby R. Bruce] base: Update the version to v22.1.0.0
>
> [Bobby R. Bruce] python,tests: Update Resource URL path to v22-1
>
> [Bobby R. Bruce] stdlib: Update the gem5 resources' version to "v22.1"
>
> [Bobby R. Bruce] util-docker: Update gcn-gpu Docker to use v22-1 ROCM patch
>
> [Bobby R. Bruce] util-docker: Add v22-1 tag to docker-compose.yaml
>
> [Bobby R. Bruce] tests: Update the compiler-tests.sh to use the v22-1
> images
>
> [Bobby R. Bruce] tests: Abstract the docker image tag for Nightly tests
>
> [Bobby R. Bruce] tests: Update nightly test docker image tags to v22-1
>
> [Bobby R. Bruce] tests: Abstract the docker image tag for Weekly tests
>
> [Bobby R. Bruce] tests: Update weekly test docker image tags to v22-1
>
> [Bobby R. Bruce] util-gem5art: Fix incorrect type of size in
> `createArtifact`
>
> [Bobby R. Bruce] tests: Update presubmit.sh to use v22-1 docker images
>
> [Bobby R. Bruce] ext: Update ext/sst/README.md for v22.1 release
>
> [Bobby R. Bruce] python: Remove 'scheduleTickExit' in favor of
> 'exitSimLoop'
>
> [Bobby R. Bruce] configs: Fix x86-gapbs-benchmarks.py example
>
> [Bobby R. Bruce] configs: Alter x86-npb-benchmarks.py to exit after WORKEND
>
> [Bobby R. Bruce] misc: Update .mailmap
>
> [Bobby R. Bruce] tests: Remove get_runtime_isa() from parsec_disk_run.py
>
> [Bobby R. Bruce] misc: Update RELEASE-NOTES.md for v22.1.0.0
>
> [rogerycchang] arch-riscv: add RV32 ADFIMU_Zfh instruction tests
>
> [rtatiefo] base: Remove unused output.hh dependency from trace.cc
>
> [vramadas] gpu-compute,mem-ruby: Add support for GPU cache bypassing
>
> [Bobby R. Bruce] scons: Re-add -Werror for gem5 develop branch
>
> [Bobby R. Bruce] misc: Update version info for develop branch
>
> [matthew.poremba] arch-vega: Fix signed BFE instructions
>
> [matthew.poremba] 

[gem5-dev] Re: Build failed in Jenkins: weekly #7

[Matt Sinclair via gem5-dev]

This should fix weekly error:
https://gem5-review.googlesource.com/c/public/gem5/+/51907

Matt

On Fri, Oct 22, 2021 at 11:23 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
> [Bobby R. Bruce] python: Set a default resource dir to download to
>
> [Bobby R. Bruce] python: Improve the print statements in downloader.py
>
> [mattdsinclair] mem-ruby: fix typo in GPU VIPER TCC comment
>
> [giacomo.travaglini] arch-arm: Do not always print 0 stats in ArmTLB
>
> [giacomo.travaglini] arch-arm: EL2/EL3 TLB invalidations should ignore the
> ASID
>
> [giacomo.travaglini] arch-arm: Define a Lookup structure to simplify TLB
> code
>
> [giacomo.travaglini] arch-arm: Use EL2&0 regime for invalidation only if
> EL2 enabled
>
> [giacomo.travaglini] arch-arm: EL2&0 invalidations do not depend on VMID
>
> [gabe.black] cpu: Eliminate the unused hasBranchTarget method in
> StaticInst.
>
> [mattdsinclair] tests: simplify weekly regression
>
> [giacomo.travaglini] sim-se: Implement mkdirat syscall
>
> [giacomo.travaglini] arch-arm: Add mkdirat implementation to the Syscall
> Table
>
> [giacomo.travaglini] arch-arm: Add mknod implementation to the Syscall
> Table
>
> [gabe.black] scons: Use unions to prevent debug flag destruction.
>
> [gabe.black] scons: Make debug flags respect tags.
>
> [gabe.black] arch: Consolidate common debug flags.
>
> [Bobby R. Bruce] configs,tests: Add "Hello world" example for the gem5
> library
>
> [Bobby R. Bruce] configs,tests: Add Ubuntu boot example for the gem5
> library
>
> [gabe.black] configs,dev: Rename the riscv version of VirtIOMMIO with a
> Riscv prefix.
>
> [gabe.black] scons: Use tags to gate ISA files and not env['TARGET_ISA'].
>
> [mattdsinclair] tests: add HACC to weekly regression
>
> [tom.rollet] python: remove SimObject children on NULL assignment
>
> [giacomo.travaglini] configs: Assign the host gid to the Process.gid in SE
> configs
>
> [giacomo.travaglini] sim-se: Implement mknodat syscall
>
> [giacomo.travaglini] arch-arm: Add mknodat implementation to the Syscall
> Table
>
> [giacomo.travaglini] arch-arm: Add utimes implementation to the Syscall
> Table
>
> [giacomo.travaglini] sim-se: Implement futimesat syscall
>
> [giacomo.travaglini] arch-arm: Add futimesat implementation to the Syscall
> Table
>
> [Jason Lowe-Power] python: Add check to SimObject for __init__
>
> [Jason Lowe-Power] python: Updates to improve debugging output
>
> [gabe.black] arch: Only build GPU switching headers if building the GPU.
>
> [gabe.black] cpu: Move FuncUnit.py, its .cc and StaticInstFlags.py above
> Return.
>
> [Jason Lowe-Power] mem-ruby: Add RISC-V atomic support to Ruby
>
> [Jason Lowe-Power] python: Generalize ruby components in library
>
> [Jason Lowe-Power] python,configs: Add Ruby support to RISC-V board
>
> [Jason Lowe-Power] tests: Add RISC-V Ruby boot tests
>
> [giacomo.travaglini] arch-arm, dev-arm: Use PageTableOps in Arm TableWalker
>
> [giacomo.travaglini] arch-arm: Add TxSZ to PageTableOps::index
>
> [giacomo.travaglini] sim-se: Implement fchmodat syscall
>
> [matthew.poremba] configs: Breakup GPU_VIPER create_system code
>
> [gabe.black] scons: Resolve tags for source files as well as for filters.
>
> [gabe.black] arch: Correct the direction of the arch->gem5 lib tag
> implication.
>
> [giacomo.travaglini] arch-arm: Fix codying style in TableWalker descriptors
>
> [gabe.black] scons: Copy the value of "tags" before adding "add_tags" to
> it.
>
> [giacomo.travaglini] arch: Fixed Packed register view for VecPredReg
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> The recommended git tool is: NONE
> No credentials specified
> Cloning the remote Git repository
> Cloning repository https://gem5.googlesource.com/public/gem5
>  > git init  # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
>  > git config --add remote.origin.fetch
> +refs/heads/*:refs/remotes/origin/* # timeout=10
> Avoid second fetch
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> Checking out Revision 16253e494e9275fb62d900d0f5f7bc7216fd8b3a
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 16253e494e9275fb62d900d0f5f7bc7216fd8b3a # timeout=10
> Commit message: "arch: Fixed Packed register view for VecPredReg"
>  > git rev-list --no-walk 5c8c981cddef9f9f0d02b29628a225acddbf0a58 #
> timeout=10
> [weekly] $ /bin/sh -xe /tmp/jenkins8774652570727622570.sh
> + 

[gem5-dev] Re: Build failed in Jenkins: nightly #10

[Matt Sinclair via gem5-dev]

Thanks Bobby!  Good to know for future reference.  I suspect I need to
update the weekly tests accordingly too.

Matt

On Wed, Oct 13, 2021 at 1:15 PM Bobby Bruce  wrote:

> Fix for the nightly tests here:
> https://gem5-review.googlesource.com/c/public/gem5/+/51607
>
> I've verified this fixes the issue.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Oct 13, 2021 at 10:50 AM Bobby Bruce  wrote:
>
>> Ah, yeah, that's probably the problem. For clarity, all the nightly tests
>> do is run `./tests/nightly.sh 16` from the gem5 root. Likewise, all the
>> weekly tests do is run `./tests/weekly.sh 16` from the gem5 root. If you
>> can update the tests with this assumption in mind, they should pass.
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Wed, Oct 13, 2021 at 10:36 AM Matt Sinclair via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> (Resending as my prior email bounced)
>>>
>>> Matt
>>>
>>> On Wed, Oct 13, 2021 at 10:21 AM Matt Sinclair 
>>> wrote:
>>>
>>>> I believe the weekly tests will fail until this is merged in:
>>>> https://gem5-review.googlesource.com/c/public/gem5/+/51207
>>>>
>>>> Jason, I will follow-up with Kyle today about the additional change you
>>>> requested last night on 51207.
>>>>
>>>> Regarding the nightly tests, where is the test being run from?  I
>>>> tested that everything works correctly on my machine, but I'm running from
>>>> the GEM5_ROOT/tests/ folder.  Looking at the error:
>>>>
>>>> *06:03:29* + wget -qN 
>>>> http://dist.gem5.org/dist/develop/test-progs/square/square*06:03:31* + 
>>>> mkdir -p tests/testing-results*06:03:31* + docker run --rm -u 118: 
>>>> --volume 
>>>> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>>>>  -w /nobackup/jenkins/workspace/nightly/tests/.. 
>>>> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt 
>>>> configs/example/apu_se.py -n3 
>>>> --benchmark-root=/nobackup/jenkins/workspace/nightly/tests/../tests -c 
>>>> square*06:03:31* *fatal: square not found in 
>>>> ['/nobackup/jenkins/workspace/nightly/tests/../tests']*
>>>>
>>>> It seems like you must be assuming a different folder?  I can
>>>> definitely update the nightly tests to fix this, but need to understand
>>>> where the test is being run from first, since things are working for me
>>>> locally with the aforementioned assumption.
>>>>
>>>> Matt
>>>>
>>>> On Wed, Oct 13, 2021 at 9:30 AM Jason Lowe-Power via gem5-dev <
>>>> gem5-dev@gem5.org> wrote:
>>>>
>>>>> Looks like the failure is in the GPU tests (note: the weekly tests are
>>>>> also failing due to GPU errors).
>>>>>
>>>>> https://jenkins.gem5.org/job/nightly/10/console
>>>>>
>>>>> On Wed, Oct 13, 2021 at 4:03 AM jenkins-no-reply--- via gem5-dev <
>>>>> gem5-dev@gem5.org> wrote:
>>>>>
>>>>>> See <
>>>>>> https://jenkins.gem5.org/job/nightly/10/display/redirect?page=changes
>>>>>> >
>>>>>>
>>>>>> Changes:
>>>>>>
>>>>>> [quentin.forcioli] dev-arm: Added trusted DRAM to vexpress Realview
>>>>>>
>>>>>> [giacomo.travaglini] sim-se: Rewrite some syscalls to use a
>>>>>> syscallImpl function
>>>>>>
>>>>>> [giacomo.travaglini] sim-se: Implement at suffixed syscalls
>>>>>>
>>>>>> [giacomo.travaglini] arch-arm: Add existing at impl to ArmLinux32
>>>>>> Syscall Table
>>>>>>
>>>>>> [giacomo.travaglini] sim-se: Implemnt fchownat syscall
>>>>>>
>>>>>> [giacomo.travaglini] arch-arm: Add fchown implementation to the
>>>>>> Syscall Table
>>>>>>
>>>>>> [giacomo.travaglini] arch-arm: Add fchownat implementation to the
>>>>>> Syscall Table
>>>>>>
>>>>>> [mattdsinclair] dev-hsa,gpu-compute: fix bug with gfx8 VAs for HSA
>>>>>&

[gem5-dev] Re: Build failed in Jenkins: nightly #10

[Matt Sinclair via gem5-dev]

(Resending as my prior email bounced)

Matt

On Wed, Oct 13, 2021 at 10:21 AM Matt Sinclair  wrote:

> I believe the weekly tests will fail until this is merged in:
> https://gem5-review.googlesource.com/c/public/gem5/+/51207
>
> Jason, I will follow-up with Kyle today about the additional change you
> requested last night on 51207.
>
> Regarding the nightly tests, where is the test being run from?  I tested
> that everything works correctly on my machine, but I'm running from the
> GEM5_ROOT/tests/ folder.  Looking at the error:
>
> *06:03:29* + wget -qN 
> http://dist.gem5.org/dist/develop/test-progs/square/square*06:03:31* + mkdir 
> -p tests/testing-results*06:03:31* + docker run --rm -u 118: --volume 
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>  -w /nobackup/jenkins/workspace/nightly/tests/.. 
> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt 
> configs/example/apu_se.py -n3 
> --benchmark-root=/nobackup/jenkins/workspace/nightly/tests/../tests -c 
> square*06:03:31* *fatal: square not found in 
> ['/nobackup/jenkins/workspace/nightly/tests/../tests']*
>
> It seems like you must be assuming a different folder?  I can definitely
> update the nightly tests to fix this, but need to understand where the test
> is being run from first, since things are working for me locally with the
> aforementioned assumption.
>
> Matt
>
> On Wed, Oct 13, 2021 at 9:30 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Looks like the failure is in the GPU tests (note: the weekly tests are
>> also failing due to GPU errors).
>>
>> https://jenkins.gem5.org/job/nightly/10/console
>>
>> On Wed, Oct 13, 2021 at 4:03 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/nightly/10/display/redirect?page=changes>
>>>
>>> Changes:
>>>
>>> [quentin.forcioli] dev-arm: Added trusted DRAM to vexpress Realview
>>>
>>> [giacomo.travaglini] sim-se: Rewrite some syscalls to use a syscallImpl
>>> function
>>>
>>> [giacomo.travaglini] sim-se: Implement at suffixed syscalls
>>>
>>> [giacomo.travaglini] arch-arm: Add existing at impl to ArmLinux32
>>> Syscall Table
>>>
>>> [giacomo.travaglini] sim-se: Implemnt fchownat syscall
>>>
>>> [giacomo.travaglini] arch-arm: Add fchown implementation to the Syscall
>>> Table
>>>
>>> [giacomo.travaglini] arch-arm: Add fchownat implementation to the
>>> Syscall Table
>>>
>>> [mattdsinclair] dev-hsa,gpu-compute: fix bug with gfx8 VAs for HSA Queues
>>>
>>> [mattdsinclair] tests: fix square and HeteroSync nightly regression
>>> command
>>>
>>> [giacomo.travaglini] mem-ruby: HTMSequencer stats initialized twice
>>>
>>> [gabe.black] scons: Pull the code which generates debug/flags.cc into a
>>> helper script.
>>>
>>> [gabe.black] scons: Rearrange functions to be next to the code that uses
>>> them.
>>>
>>> [Bobby R. Bruce] tests: Fix argparse description in simple_binary_run.py
>>>
>>> [mail] python: Fix L1 data cache size in cache components
>>>
>>>
>>> --
>>> [...truncated 847.41 KB...]
>>>  [ CXX] GCN3_X86/python/_m5/param_PciMemBar.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PciMemUpperBar.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PciVirtIO.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PerfectCompressor.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PioDevice.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_Platform.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PoolManager.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PowerDomain.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PowerModel.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PowerModelState.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PowerState.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_ProbeListenerObject.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_Process.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_ProtocolTester.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_PyTrafficGen.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSFixedPriorityPolicy.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSMemCtrl.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSMemSinkCtrl.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSMemSinkInterface.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSPolicy.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSPropFairPolicy.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSTurnaroundPolicy.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QoSTurnaroundPolicyIdeal.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_QueuedPrefetcher.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_RandomRP.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_RangeAddrMapper.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_RawDiskImage.cc -> .o
>>>  [ CXX] GCN3_X86/python/_m5/param_RedirectPath.cc -> .o
>>>  [ CXX] 

[gem5-dev] Re: Build failed in Jenkins: Nightly #205

[Matt Sinclair via gem5-dev]

(Reposting since prior message bounced)

As noted by Gabe last night on the review board, this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/40216, should fix the
failure.

Matt

On Sun, Jan 31, 2021 at 3:08 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/Nightly/205/display/redirect?page=changes>
>
> Changes:
>
> [kyleroarty1716] dev-hsa: enable interruptible hsa signal support
>
>
> --
> [...truncated 44.38 KB...]
>  [ CXX] GCN3_X86/mem/cache/prefetch/slim_ampm.cc -> .o
>  [SO PARAM] STeMSPrefetcher -> GCN3_X86/params/STeMSPrefetcher.hh
>  [ CXX]
> GCN3_X86/mem/cache/prefetch/spatio_temporal_memory_streaming.cc -> .o
>  [SO PARAM] StridePrefetcher -> GCN3_X86/params/StridePrefetcher.hh
>  [SO PARAM] StridePrefetcherHashedSetAssociative ->
> GCN3_X86/params/StridePrefetcherHashedSetAssociative.hh
>  [SO PARAM] SetAssociative -> GCN3_X86/params/SetAssociative.hh
>  [ CXX] GCN3_X86/mem/cache/prefetch/stride.cc -> .o
>  [SO PARAM] TaggedPrefetcher -> GCN3_X86/params/TaggedPrefetcher.hh
>  [ CXX] GCN3_X86/mem/cache/prefetch/tagged.cc -> .o
>  [ TRACING]  -> GCN3_X86/debug/TraceCPUData.hh
>  [ TRACING]  -> GCN3_X86/debug/TraceCPUInst.hh
>  [SO PARAM] TraceCPU -> GCN3_X86/params/TraceCPU.hh
>  [  PROTOC] GCN3_X86/proto/inst_dep_record.proto -> GCN3_X86/proto/
> inst_dep_record.pb.cc, GCN3_X86/proto/inst_dep_record.pb.h
>  [  PROTOC] GCN3_X86/proto/packet.proto -> GCN3_X86/proto/packet.pb.cc,
> GCN3_X86/proto/packet.pb.h
>  [ CXX] GCN3_X86/cpu/trace/trace_cpu.cc -> .o
>  [ TRACING]  -> GCN3_X86/debug/RubyQueue.hh
>  [SO PARAM] RubyNetwork -> GCN3_X86/params/RubyNetwork.hh
>  [MAKE INC] GCN3_X86/mem/ruby/common/DataBlock.hh -> protocol/DataBlock.hh
>  [MAKE INC] GCN3_X86/mem/ruby/common/MachineID.hh -> protocol/MachineID.hh
>  [MAKE INC] GCN3_X86/mem/ruby/slicc_interface/Message.hh ->
> protocol/Message.hh
>  [SO PARAM] RubyController -> GCN3_X86/params/RubyController.hh
>  [SO PARAM] RubySystem -> GCN3_X86/params/RubySystem.hh
>  [SO PARAM] RubySequencer -> GCN3_X86/params/RubySequencer.hh
>  [ TRACING]  -> GCN3_X86/debug/RubySlicc.hh
>  [SO PARAM] MessageBuffer -> GCN3_X86/params/MessageBuffer.hh
>  [MAKE INC] GCN3_X86/mem/ruby/slicc_interface/RubyRequest.hh ->
> protocol/RubyRequest.hh
>  [SO PARAM] RubyCache -> GCN3_X86/params/RubyCache.hh
>  [SO PARAM] RubyPort -> GCN3_X86/params/RubyPort.hh
>  [SO PARAM] BasicExtLink -> GCN3_X86/params/BasicExtLink.hh
>  [SO PARAM] BasicIntLink -> GCN3_X86/params/BasicIntLink.hh
>  [SO PARAM] BasicLink -> GCN3_X86/params/BasicLink.hh
>  [SO PARAM] BasicRouter -> GCN3_X86/params/BasicRouter.hh
>  [SO PARAM] RubyDirectoryMemory -> GCN3_X86/params/RubyDirectoryMemory.hh
>  [SO PARAM] SimpleMemory -> GCN3_X86/params/SimpleMemory.hh
>  [ENUMDECL] MessageRandomization -> GCN3_X86/enums/MessageRandomization.hh
>  [ CXX] GCN3_X86/mem/ruby/slicc_interface/AbstractController.cc -> .o
>  [ TRACING]  -> GCN3_X86/debug/RubyCache.hh
>  [ CXX] GCN3_X86/mem/ruby/slicc_interface/AbstractCacheEntry.cc -> .o
>  [LINK]  -> GCN3_X86/mem/cache/prefetch/lib.o.partial
>  [ CXX] GCN3_X86/mem/ruby/slicc_interface/RubyRequest.cc -> .o
>  [ CXX] GCN3_X86/unittest/unittest.cc -> .o
>  [ CXX] GCN3_X86/mem/ruby/network/BasicLink.cc -> .o
>  [LINK]  -> GCN3_X86/unittest/lib.o.partial
>  [ CXX] GCN3_X86/mem/ruby/network/BasicRouter.cc -> .o
>  [ CXX] GCN3_X86/mem/ruby/network/MessageBuffer.cc -> .o
>  [ CXX] GCN3_X86/mem/ruby/network/Network.cc -> .o
>  [LINK]  -> GCN3_X86/cpu/trace/lib.o.partial
>  [ TRACING]  -> GCN3_X86/debug/RubyNetwork.hh
>  [ CXX] GCN3_X86/mem/ruby/network/Topology.cc -> .o
>  [LINK]  -> GCN3_X86/mem/ruby/slicc_interface/lib.o.partial
>  [ CXX] GCN3_X86/systemc/tlm_core/2/generic_payload/gp.cc -> .o
>  [ CXX] GCN3_X86/systemc/tlm_core/2/generic_payload/phase.cc -> .o
>  [LINK]  -> GCN3_X86/systemc/tlm_core/2/generic_payload/lib.o.partial
>  [ TRACING]  -> GCN3_X86/debug/RubyStats.hh
>  [ CXX] GCN3_X86/mem/ruby/structures/DirectoryMemory.cc -> .o
>  [ TRACING]  -> GCN3_X86/debug/HtmMem.hh
>  [ TRACING]  -> GCN3_X86/debug/RubyCacheTrace.hh
>  [ TRACING]  -> GCN3_X86/debug/RubyResourceStalls.hh
>  [ CXX] GCN3_X86/mem/ruby/structures/CacheMemory.cc -> .o
>  [SO PARAM] RubyWireBuffer -> GCN3_X86/params/RubyWireBuffer.hh
>  [ CXX] GCN3_X86/mem/ruby/structures/WireBuffer.cc -> .o
>  [ CXX] GCN3_X86/mem/ruby/structures/PersistentTable.cc -> .o
>  [LINK]  -> GCN3_X86/mem/ruby/network/lib.o.partial
>  [ TRACING]  -> GCN3_X86/debug/RubyPrefetcher.hh
>  [SO PARAM] RubyPrefetcher -> GCN3_X86/params/RubyPrefetcher.hh
>  [ CXX] GCN3_X86/mem/ruby/structures/RubyPrefetcher.cc -> .o
>  [ CXX] GCN3_X86/mem/ruby/structures/TimerTable.cc -> .o
>  [ CXX] GCN3_X86/mem/ruby/structures/BankedArray.cc -> .o
>  [ CXX] GCN3_X86/cpu/testers/gpu_ruby_test/address_manager.cc -> .o
>  

[gem5-dev] Re: Testing fail on GCN3_X86 on Arm machine

[Matt Sinclair via gem5-dev]

Hi Nathanael,

I have personally never tested GCN3 on an ARM machine, so I can't say
definitively if it will work there or not.  But if you are not, I strongly
recommend testing anything you need to test with GCN3 inside the docker we
created:

-
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/gcn-gpu/README.md
- http://www.gem5.org/2020/05/27/modern-gpu-applications.html

Thanks,
Matt

On Mon, Jan 11, 2021 at 8:42 AM Nathanael Premillieu via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi,
>
>
>
> I’m currently working on some changes in gem5 and before submitting them,
> I’m using the testing framework as required.
>
> However, even without my changes, I get failures when building GCN3_X86
> (See the trace at the end).
>
> I guess it is linked to the fact that I’m working on an Arm machine. Do I
> need to set up something to make it work?
>
>
>
> Thanks,
>
> Nathanael Premillieu
>
>
>
> The trace:
>
> /scratch/npremill/gem5_public.git/build/GCN3_X86/gem5.opt
>
> You may want to run with only a single ISA(--isa=), use --skip-build, or
> use 'rerun'.
>
> MOESI_AMD_Base-dir.sm:220: Warning: Non-void return ignored, return type
> is 'bool'
>
> MOESI_AMD_Base-dir.sm:1052: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dir.sm:1056: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dir.sm:1060: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dir.sm:1064: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dir.sm:1068: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dir.sm:1072: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dir.sm:1076: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dir.sm:586: Warning: Unused action: l_queueMemWBReq, Write
> WB data to memory
>
> MOESI_AMD_Base-dir.sm:953: Warning: Unused action:
> mwc_markSinkWriteCancel, Mark to sink impending VicDirty
>
> MOESI_AMD_Base-dir.sm:1051: Warning: Unused action: dl_deallocateL3,
> deallocate the L3 block
>
> MOESI_AMD_Base-dir.sm:1087: Warning: Unused action:
> yy_recycleResponseQueue, recycle response queue
>
> MOESI_AMD_Base-dma.sm:187: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-dma.sm:191: Warning: Non-void return ignored, return type
> is 'Tick'
>
> MOESI_AMD_Base-CorePair.sm:325: Warning: Non-void return ignored, return
> type is 'bool'
>
> MOESI_AMD_Base-CorePair.sm:802: Warning: Non-void return ignored, return
> type is 'Tick'
>
> MOESI_AMD_Base-CorePair.sm:806: Warning: Non-void return ignored, return
> type is 'Tick'
>
> MOESI_AMD_Base-CorePair.sm:810: Warning: Non-void return ignored, return
> type is 'Tick'
>
> MOESI_AMD_Base-CorePair.sm:814: Warning: Non-void return ignored, return
> type is 'Tick'
>
> GPU_VIPER-TCP.sm:166: Warning: Non-void return ignored, return type is
> 'bool'
>
> GPU_VIPER-TCP.sm:451: Warning: Non-void return ignored, return type is
> 'Tick'
>
> GPU_VIPER-TCP.sm:455: Warning: Non-void return ignored, return type is
> 'Tick'
>
> GPU_VIPER-TCP.sm:385: Warning: Unused action: norl_issueRdBlkOrloadDone,
> local load done
>
> GPU_VIPER-SQC.sm:143: Warning: Non-void return ignored, return type is
> 'bool'
>
> GPU_VIPER-SQC.sm:275: Warning: Non-void return ignored, return type is
> 'Tick'
>
> GPU_VIPER-SQC.sm:279: Warning: Non-void return ignored, return type is
> 'Tick'
>
> GPU_VIPER-TCC.sm:168: Warning: Non-void return ignored, return type is
> 'bool'
>
> GPU_VIPER-TCC.sm:551: Warning: Non-void return ignored, return type is
> 'Tick'
>
> GPU_VIPER-TCC.sm:555: Warning: Non-void return ignored, return type is
> 'Tick'
>
> GPU_VIPER-TCC.sm:559: Warning: Non-void return ignored, return type is
> 'Tick'
>
> GPU_VIPER-TCC.sm:583: Warning: Non-void return ignored, return type is
> 'Tick'
>
> MOESI_AMD_Base-L3cache.sm:196: Warning: Non-void return ignored, return
> type is 'bool'
>
> MOESI_AMD_Base-L3cache.sm:611: Warning: Non-void return ignored, return
> type is 'Tick'
>
> MOESI_AMD_Base-L3cache.sm:615: Warning: Non-void return ignored, return
> type is 'Tick'
>
> MOESI_AMD_Base-L3cache.sm:619: Warning: Non-void return ignored, return
> type is 'Tick'
>
> MOESI_AMD_Base-L3cache.sm:623: Warning: Non-void return ignored, return
> type is 'Tick'
>
> MOESI_AMD_Base-L3cache.sm:561: Warning: Unused action:
> rd_copyDataFromRequest, write data to L3
>
> In file included from build/GCN3_X86/dev/hsa/hsa_packet_processor.hh:44,
>
>  from build/GCN3_X86/dev/hsa/hsa_device.hh:43,
>
>  from
> build/GCN3_X86/gpu-compute/gpu_command_processor.hh:50,
>
>  from build/GCN3_X86/gpu-compute/dispatcher.cc:41:
>
> build/GCN3_X86/dev/hsa/hsa.h:93:2: error: #error "BIGENDIAN_CPU or
> LITTLEENDIAN_CPU must be defined"
>
>93 | #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined"
>
>   |  ^
>
> In file included from 

[gem5-dev] Re: Build failed in Jenkins: Nightly #162

[Matt Sinclair via gem5-dev]

Sounds good, thanks Bobby!

Matt

On Fri, Dec 18, 2020 at 11:02 AM Bobby Bruce  wrote:

> I think the Jenkins might have an older Docker image. I'll fix this.
>
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
> Please consider making a submission to GI@ICSE '21:
> http://geneticimprovementofsoftware.com/gi2021icse.html
>
>
> On Fri, Dec 18, 2020 at 7:58 AM Matt Sinclair 
> wrote:
>
>> Hi Bobby,
>>
>> Looks like this failed because the GCN3 stuff requires the older version
>> of Python.  I know we've discussed this before and I believe Kyle/Matt P.
>> had pushed a patch to deal with this, so I'm wondering if perhaps the way
>> you added the GCN3 stuff to the regression is missing that patch?  Or
>> trying to build the GPU code in a different way?
>>
>> Thanks,
>> Matt
>>
>> On Fri, Dec 18, 2020 at 12:56 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/Nightly/162/display/redirect?page=changes>
>>>
>>> Changes:
>>>
>>> [gabe.black] dev: Use BitUnions and a RegisterBank in the Uart8250.
>>>
>>>
>>> --
>>> [...truncated 12.31 KB...]
>>> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library
>>> None... (cached) no
>>> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library
>>> rt... (cached) yes
>>> Checking for C library tcmalloc... (cached) yes
>>> Checking for char temp; backtrace_symbols_fd((void*), 0, 0) in C
>>> library None... (cached) yes
>>> Checking for C header file fenv.h... (cached) yes
>>> Checking for C header file png.h... (cached) yes
>>> Checking for C header file linux/kvm.h... (cached) yes
>>> Checking for C header file linux/if_tun.h... (cached) yes
>>> Checking size of struct kvm_xsave ... (cached) yes
>>> Checking for member exclude_host in struct perf_event_attr...(cached) yes
>>> Checking for hdf5-serial using pkg-config... yes
>>> Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) yes
>>> Checking for H5::H5File("", 0) in C++ library hdf5_cpp... (cached) yes
>>> Checking whether __i386__ is declared... (cached) no
>>> Checking whether __x86_64__ is declared... (cached) yes
>>> Building in 
>>> Using saved variables file <
>>> https://jenkins.gem5.org/job/Nightly/ws/build/variables/POWER>
>>> scons: done reading SConscript files.
>>> scons: Building targets ...
>>>  [ CXX] POWER/mem/ruby/protocol/DMA_Controller.cc -> .o
>>>  [ CXX] POWER/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>>>  [ CXX] POWER/mem/ruby/protocol/Directory_Controller.cc -> .o
>>>  [ CXX] POWER/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>>>  [ CXX] POWER/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>>>  [ CXX] POWER/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>>>  [VER TAGS]  -> POWER/sim/tags.cc
>>>  [ CXX] POWER/python/_m5/param_Uart8250.cc -> .o
>>>  [ CXX] POWER/dev/serial/uart8250.cc -> .o
>>>  [LINK]  -> POWER/mem/ruby/protocol/lib.o.partial
>>>  [ CXX] POWER/sim/tags.cc -> .o
>>>  [LINK]  -> POWER/sim/lib.o.partial
>>>  [LINK]  -> POWER/sim/power/lib.o.partial
>>>  [LINK]  -> POWER/dev/serial/lib.o.partial
>>>  [ CXX] POWER/base/date.cc -> .o
>>>  [LINK]  -> POWER/gem5.opt
>>> scons: done building targets.
>>> *** Summary of Warnings ***
>>> Warning: Your compiler doesn't support incremental linking and lto at
>>> the same
>>>  time, so lto is being disabled. To force lto on anyway, use the
>>>  --force-lto option. That will disable partial linking.
>>> [Nightly] $ /bin/sh -xe /tmp/jenkins7055740102451494397.sh
>>> + pwd
>>> + pwd
>>> + pwd
>>> + docker run -u : --volume :<
>>> https://jenkins.gem5.org/job/Nightly/ws/> -w <
>>> https://jenkins.gem5.org/job/Nightly/ws/> --rm
>>> gcr.io/gem5-test/ubuntu-20.04_all-dependencies bash -c scons
>>> build/RISCV/gem5.opt -j4 || (rm -rf build && scons build/RISCV/gem5.opt -j4)
>>> scons: Reading SConscript files ...
>>> Warning: Your compiler doesn't support incremental linking and lto at
>>> the same
>>>  time, so lto is being disabled. To force lto on anyway, use the
>>>  --force-lto option. That will disable partial linking.
>>> Info: Using Python config: python3-config
>>> Checking for C header file Python.h... (cached) yes
>>> Checking for C library python3.8... (cached) yes
>>> Checking for C library crypt... (cached) yes
>>> Checking for C library pthread... (cached) yes
>>> Checking for C library dl... (cached) yes
>>> Checking for C library util... (cached) yes
>>> Checking for C library m... (cached) yes
>>> Checking Python version... (cached) 3.8.2
>>> Checking for accept(0,0,0) in C++ library None... (cached) yes
>>> Checking for zlibVersion() in C++ library z... (cached) yes
>>> Checking for GOOGLE_PROTOBUF_VERIFY_VERSION in C++ library protobuf...
>>> (cached) yes

[gem5-dev] Re: Build failed in Jenkins: Nightly #162

[Matt Sinclair via gem5-dev]

Hi Bobby,

Looks like this failed because the GCN3 stuff requires the older version of
Python.  I know we've discussed this before and I believe Kyle/Matt P. had
pushed a patch to deal with this, so I'm wondering if perhaps the way you
added the GCN3 stuff to the regression is missing that patch?  Or trying to
build the GPU code in a different way?

Thanks,
Matt

On Fri, Dec 18, 2020 at 12:56 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/Nightly/162/display/redirect?page=changes>
>
> Changes:
>
> [gabe.black] dev: Use BitUnions and a RegisterBank in the Uart8250.
>
>
> --
> [...truncated 12.31 KB...]
> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library
> None... (cached) no
> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library rt...
> (cached) yes
> Checking for C library tcmalloc... (cached) yes
> Checking for char temp; backtrace_symbols_fd((void*), 0, 0) in C
> library None... (cached) yes
> Checking for C header file fenv.h... (cached) yes
> Checking for C header file png.h... (cached) yes
> Checking for C header file linux/kvm.h... (cached) yes
> Checking for C header file linux/if_tun.h... (cached) yes
> Checking size of struct kvm_xsave ... (cached) yes
> Checking for member exclude_host in struct perf_event_attr...(cached) yes
> Checking for hdf5-serial using pkg-config... yes
> Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) yes
> Checking for H5::H5File("", 0) in C++ library hdf5_cpp... (cached) yes
> Checking whether __i386__ is declared... (cached) no
> Checking whether __x86_64__ is declared... (cached) yes
> Building in 
> Using saved variables file <
> https://jenkins.gem5.org/job/Nightly/ws/build/variables/POWER>
> scons: done reading SConscript files.
> scons: Building targets ...
>  [ CXX] POWER/mem/ruby/protocol/DMA_Controller.cc -> .o
>  [ CXX] POWER/mem/ruby/protocol/DMA_Wakeup.cc -> .o
>  [ CXX] POWER/mem/ruby/protocol/Directory_Controller.cc -> .o
>  [ CXX] POWER/mem/ruby/protocol/Directory_Wakeup.cc -> .o
>  [ CXX] POWER/mem/ruby/protocol/L1Cache_Controller.cc -> .o
>  [ CXX] POWER/mem/ruby/protocol/L1Cache_Wakeup.cc -> .o
>  [VER TAGS]  -> POWER/sim/tags.cc
>  [ CXX] POWER/python/_m5/param_Uart8250.cc -> .o
>  [ CXX] POWER/dev/serial/uart8250.cc -> .o
>  [LINK]  -> POWER/mem/ruby/protocol/lib.o.partial
>  [ CXX] POWER/sim/tags.cc -> .o
>  [LINK]  -> POWER/sim/lib.o.partial
>  [LINK]  -> POWER/sim/power/lib.o.partial
>  [LINK]  -> POWER/dev/serial/lib.o.partial
>  [ CXX] POWER/base/date.cc -> .o
>  [LINK]  -> POWER/gem5.opt
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Your compiler doesn't support incremental linking and lto at the
> same
>  time, so lto is being disabled. To force lto on anyway, use the
>  --force-lto option. That will disable partial linking.
> [Nightly] $ /bin/sh -xe /tmp/jenkins7055740102451494397.sh
> + pwd
> + pwd
> + pwd
> + docker run -u : --volume :<
> https://jenkins.gem5.org/job/Nightly/ws/> -w <
> https://jenkins.gem5.org/job/Nightly/ws/> --rm
> gcr.io/gem5-test/ubuntu-20.04_all-dependencies bash -c scons
> build/RISCV/gem5.opt -j4 || (rm -rf build && scons build/RISCV/gem5.opt -j4)
> scons: Reading SConscript files ...
> Warning: Your compiler doesn't support incremental linking and lto at the
> same
>  time, so lto is being disabled. To force lto on anyway, use the
>  --force-lto option. That will disable partial linking.
> Info: Using Python config: python3-config
> Checking for C header file Python.h... (cached) yes
> Checking for C library python3.8... (cached) yes
> Checking for C library crypt... (cached) yes
> Checking for C library pthread... (cached) yes
> Checking for C library dl... (cached) yes
> Checking for C library util... (cached) yes
> Checking for C library m... (cached) yes
> Checking Python version... (cached) 3.8.2
> Checking for accept(0,0,0) in C++ library None... (cached) yes
> Checking for zlibVersion() in C++ library z... (cached) yes
> Checking for GOOGLE_PROTOBUF_VERIFY_VERSION in C++ library protobuf...
> (cached) yes
> Checking for C header file valgrind/valgrind.h... (cached) no
> Checking for clock_nanosleep(0,0,NULL,NULL) in C library None... (cached)
> yes
> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library
> None... (cached) no
> Checking for timer_create(CLOCK_MONOTONIC, NULL, NULL) in C library rt...
> (cached) yes
> Checking for C library tcmalloc... (cached) yes
> Checking for char temp; backtrace_symbols_fd((void*), 0, 0) in C
> library None... (cached) yes
> Checking for C header file fenv.h... (cached) yes
> Checking for C header file png.h... (cached) yes
> Checking for C header file linux/kvm.h... (cached) yes
> Checking for C header 

[gem5-dev] Re: Build failed in Jenkins: Compiler-Checks #33

[Matt Sinclair via gem5-dev]

(Resending so message doesn't bounce on mailing list)

Hi Bobby,

Can you point us to what you would want in testlibs?

Matt

On Mon, Nov 30, 2020 at 2:38 PM Bobby Bruce via gem5-dev 
wrote:

> @Kyle: GCN3 is only built weekly via the compiler tests. Compiling every
> gem5 variant each time we run Kokoro would just be too costly so we only
> target the core ISAs. If you wrote us some testlib tests, we could run
> those as part of our nightly tests.
>
> @Matt: This won't build anywhere. You can just use: `scons
> build/GCN3_X86/gem5.opt` on the latest develop branch pull and you should
> be able to reproduce it. Though it seems Kyle has already identified the
> source of the problem.
>
> --
> Dr. Bobby R. Bruce
> Room 2235,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
> Please consider making a submission to GI@ICSE '21:
> http://geneticimprovementofsoftware.com/gi2021icse.html
>
>
> On Mon, Nov 30, 2020 at 12:27 PM Kyle Roarty  wrote:
>
>> Looks like this commit
>> https://gem5-review.googlesource.com/c/public/gem5/+/37775 broke it, and
>> the solution would be to change "if buildEnv['FULL_SYSTEM']" to "if
>> buildEnv.get('FULL_SYSTEM', False)"
>>
>> Also, looking at that review, kokoro didn't catch the issue. I thought
>> GCN3_X86 was at least built when kokoro runs?
>>
>> Kyle
>> --
>> *From:* Poremba, Matthew 
>> *Sent:* Monday, November 30, 2020 2:22 PM
>> *To:* gem5 Developer List ; Matt Sinclair <
>> msincl...@wisc.edu>; Kyle Roarty ; Bobby Bruce <
>> bbr...@ucdavis.edu>
>> *Subject:* RE: [gem5-dev] Re: Build failed in Jenkins: Compiler-Checks
>> #33
>>
>>
>> [AMD Public Use]
>>
>>
>>
>> I could try and help, but the compiler-test.sh script does not work for
>> me locally and I always get the following error (on multiple machines):
>>
>>
>>
>> Error: No non-leaf 'build' dir found on target path. /gem5
>>
>>
>>
>> That said, probably deleting the whole if block in
>> src/gpu-compute/X86GPUTLB.py could fix the error. Seems like a duplicate
>> definition to me. There is also no full system support for GPU yet anyway.
>>
>>
>>
>>
>>
>> -Matt
>>
>>
>>
>>
>>
>> *From:* Bobby Bruce via gem5-dev 
>> *Sent:* Monday, November 30, 2020 12:11 PM
>> *To:* Matt Sinclair ; Kyle Roarty > >
>> *Cc:* gem5 Developer List ; Bobby Bruce <
>> bbr...@ucdavis.edu>
>> *Subject:* [gem5-dev] Re: Build failed in Jenkins: Compiler-Checks #33
>>
>>
>>
>> [CAUTION: External Email]
>>
>> Hey Matt and Kyle,
>>
>>
>>
>> It seems like the GCN3_X86 isn't building. The following error is being
>> returned:
>> http://jenkins.gem5.org/job/Compiler-Checks/33/artifact/compile-test-out/clang-version-9/GCN3_X86.opt.stderr.txt
>> 
>>
>>
>>
>> Could someone look into fixing this?
>>
>>
>>
>> Kind regards,
>>
>> Bobby
>>
>> --
>>
>> Dr. Bobby R. Bruce
>> Room 2235,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>>
>>
>> web: https://www.bobbybruce.net
>> 
>>
>>
>>
>> Please consider making a submission to GI@ICSE '21:
>> http://geneticimprovementofsoftware.com/gi2021icse.html
>> 
>>
>>
>>
>>
>>
>> On Fri, Nov 27, 2020 at 1:46 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> See <
>> https://jenkins.gem5.org/job/Compiler-Checks/33/display/redirect?page=changes
>> 
>> >
>>
>> Changes:
>>
>> [gabe.black] 

[gem5-dev] Re: AMD GCN3 - HSA Memory Mapping

[Matt Sinclair via gem5-dev]

Hi Sampad,

I don't know the answer to this question directly, but I'm CC'ing the AMD
folks who hopefully can provide the answer.  I mentioned this to Matt P
earlier and he thinks it may be a bug.

Thanks,
Matt

On Fri, Jul 31, 2020 at 10:47 AM Sampad Mohapatra via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi All,
>
> I have two queries related to apu_se.py.
>
> (1)
> In both AMD staging and public/develop, apu_se.py has two unused variables:
>
>   hsapp_gpu_map_vaddr = 0x2
>   hsapp_gpu_map_size = 0x1000
>
> Are they unnecessary or should they actually be used somewhere ?
>
> (2)
> The following is passed as pioAddr to the HSAPacketProcessor.
>   hsapp_gpu_map_paddr = int(Addr(options.mem_size))
>
> And then the following assignment is done.
>   # Map workload to this address space
>   host_cpu.workload[0].map(0x1000, 0x2, 4096)
>
> Should the physical address to the workload map be the same as pioAddr of
> HSAPacketProcessor, i.e. greater than physical memory size and should the
> virtual address of the workload map remain 0x1000 ?
>
> As a whole, are the above mentioned variables related ? If yes, then how ?
> Are some of them accidentally hardcoded and should actually be variables?
> Please advise.
>
> Thank you,
> Sampad
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: AMD GCN3 on Research Cluster. Toolchain Compilation Help.

[Matt Sinclair via gem5-dev]

The AMD staging branch is in the process of being merged into develop.  The
two patches that update that file in particular are the next ones to be
merged in and are currently going through review:

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

In the meantime, you can either use the staging branch:
https://gem5.googlesource.com/amd/gem5/+/refs/heads/agutierr/master-gcn3-staging
(this is what the webpage I sent you suggests, and what the docker does),
or you can cherry pick the appropriate commits that haven't been merged
into develop yet.  I recommend using the staging branch.

Matt

On Sun, Jul 26, 2020 at 12:34 AM Marco Bianchi  wrote:

> Hi Matt,
>
> The apu_se.py in public/gem5/develop seems to be for the old HSAIL model.
> Is there any updated apu_se.py which I can use with GCN3 ?
>
> Thanks,
> Marco
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-7718635553115273484_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sat, Jul 25, 2020 at 11:00 PM Matt Sinclair 
> wrote:
>
>> I recommend starting here:
>> http://www.gem5.org/2020/05/27/modern-gpu-applications.html and here:
>> http://www.gem5.org/documentation/general_docs/gpu_models/GCN3 (old
>> version may also be useful: http://old.gem5.org/GPU_Models.html).  The
>> above includes information about the required driver versions and libraries
>> -- all of which can be installed without sudo/root.  Alternatively, Kyle R
>> has created a Docker that does all of this for you (see first link).  You
>> may also consider looking through the archive for old posts on this.
>>
>> To the best of my knowledge, no one has tried CentOS before though, and I
>> have no idea if it's supported or not though.
>>
>> Matt
>>
>> On Sat, Jul 25, 2020 at 9:51 PM Marco Bianchi via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hi All,
>>>
>>> Are there any documented steps to build the various drivers and
>>> compilers needed to run the GCN3 model ? I am trying to run it on CentOS
>>> release 6.10. Since it is a research cluster I will have to compile
>>> everything from scratch and have no root/sudo access. Previous HSAIL model
>>> needed just the cl-runtime to run. Does GCN3 require the Kernel Driver
>>> running for simulation ?
>>>
>>> To be honest I am not clear as to what all steps need to be taken under
>>> the given circumstances.
>>>
>>> Thanks,
>>> Marco Bianchi
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>> <#m_-7718635553115273484_m_-2829622843747458868_m_-637038485164167120_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: AMD GCN3 on Research Cluster. Toolchain Compilation Help.

[Matt Sinclair via gem5-dev]

I recommend starting here:
http://www.gem5.org/2020/05/27/modern-gpu-applications.html and here:
http://www.gem5.org/documentation/general_docs/gpu_models/GCN3 (old version
may also be useful: http://old.gem5.org/GPU_Models.html).  The above
includes information about the required driver versions and libraries --
all of which can be installed without sudo/root.  Alternatively, Kyle R has
created a Docker that does all of this for you (see first link).  You may
also consider looking through the archive for old posts on this.

To the best of my knowledge, no one has tried CentOS before though, and I
have no idea if it's supported or not though.

Matt

On Sat, Jul 25, 2020 at 9:51 PM Marco Bianchi via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi All,
>
> Are there any documented steps to build the various drivers and compilers
> needed to run the GCN3 model ? I am trying to run it on CentOS release
> 6.10. Since it is a research cluster I will have to compile everything from
> scratch and have no root/sudo access. Previous HSAIL model needed just the
> cl-runtime to run. Does GCN3 require the Kernel Driver running for
> simulation ?
>
> To be honest I am not clear as to what all steps need to be taken under
> the given circumstances.
>
> Thanks,
> Marco Bianchi
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-637038485164167120_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: AMD GPU cache stats correctness

[Matt Sinclair via gem5-dev]

I don't know much about the HSAIL model, and it was deprecated a while ago
in favor of the more up-to-date GCN3 model (which is in the process of
being merged into the develop branch, and is also fully available on its
own staging branch).  If HSAIL is the same as GCN3 though, there weren't
any cache stats in the protocol (which is why they were 0).  Support for
TCP and TCC hits/misses were added here:
https://gem5-review.googlesource.com/c/public/gem5/+/30174.  I have no idea
if this would apply cleanly to HSAIL though.  If not, you'd need to add
similar support.

Matt

On Sat, Jul 25, 2020 at 1:28 PM Marco Bianchi via gem5-dev <
gem5-dev@gem5.org> wrote:

> Which stats specify the various L1, L2 and L3 hit and miss rates for the
> AMD GPU?
>
> Stats such as:
>   system.tcp_cntrl0.L1cache.demand_accesses,
> system.dir_cntrl0.L3CacheMemory.demand_accesses,
> system.tccdir_cntrl0.directory.demand_accesses
> are always 0.
>
> So, I am wondering whether I am looking at the right cache stats, or is
> there some issue in the simulation itself,
> or the stats for GPU related caches are never actually updated (I couldn't
> find a location where these are updated for the TCP, TCC, Directories.
> But they are updated for the cpu core pairs.)
>
> P.S.: I am using the GCN HSAIL model.
>
> Thanks in advance,
> Marco Bianchi
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_4084755903454649598_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: GCN3 Integration

[Matt Sinclair via gem5-dev]

 To add onto what Matt said, Kyle Roarty and I will also be giving a talk
in the gem5 workshop about the docker support we've added for the GPU
model.  We are also working on merging that into develop currently.

Matt S.

On Mon, May 18, 2020 at 1:57 PM Poremba, Matthew via gem5-dev <
gem5-dev@gem5.org> wrote:

> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Daniel,
>
>
> We're in the process of merging it into develop. It should be in gem5
> 20.1. There are a few CLs that need reviews first. Tony and I will be
> giving a talk during the gem5 workshop in 2 weeks.
>
>
> -Matt
>
> -Original Message-
> From: Daniel Gerzhoy via gem5-dev 
> Sent: Monday, May 18, 2020 10:39 AM
> To: gem5 Developer List 
> Cc: Daniel Gerzhoy 
> Subject: [gem5-dev] GCN3 Integration
>
> [CAUTION: External Email]
>
> Hello,
>
> I'm wondering if anyone could give an update on the status of integrating
> the gcn3-staging branch into the main branch?
> (From here:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgem5.googlesource.com%2Famd%2Fgem5data=02%7C01%7Cmatthew.poremba%40amd.com%7Cffbf0f89a0d14ae8a43108d7fb52755e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254203890939524sdata=hJNYBWzfoQuLtL2TG3m3AtabLX7wJx3OHE1y6wkDhNo%3Dreserved=0
>branch: agutierr/master-gcn3-staging)
>
> I saw some emails on this list about it, so I thought I might update to
> the main branch but just from looking into the apu_se.py in the
> develop/19.0 release/20.0 rc I don't see any mention of GPU_VIPER, and a
> couple of other things like the ROCm environment paths that the
> gcn3-staging branch has.
>
> Just hoping to eventually use the main branch if possible.
>
> Cheers and thanks for all the hard work  (and stay safe),
>
> Dan Gerzhoy
> University of Maryland at College Park
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email
> to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s