Tl;dr: while you can copy the code, I suspect it will be very painful to get these to work.
This is the response I got in 2020 when asking a similar question: "I took a look at the code and I apologize for the confusion. I now realize we did not make it clear that we deprecated those protocols in Tony's staging branch. We should explicitly remove them ... The reason for deprecation depends on the protocol. For RFO, we choose to deprecated (sic) it because it is incompatible with the underlining assumption of the compiler. As you know, the compiler will insert wait cnts and cache invalidate instructions that are unnecessary for RFO. Also write instructions now expect a 2-phase callback which is also incompatible with RFO. Perhaps we could have modified the GPU coalescer to get around these issues, but that seemed more work that it is worth. Meanwhile the VIPER Region/Baseline protocols should technically work with the latest branch, but I do not believe they have ever been tested with Tuan's new GPU tester. If your student wants those protocols to work, I suggest he start with the tester. I believe the particular issue your student is currently encountering is directly related to the RFO protocol py file not being updated to the latest interface changes. Depending how good the student is, they may be able to figure that out by replicating the changes made to the VIPER py file in the staging branch. Eventually the student will hit the "hard part" and notice the code we ripped out of the GPUCoalescer. If you do a diff of the following two files, you'll see that the "assumingRfOCoherence" flag is missing from Tony's staging branch. That will take some effort and thinking to determine how to fix. https://gem5.googlesource.com/amd/gem5/+/refs/heads/agutierr/master-gcn3-staging/src/mem/ruby/system/GPUCoalescer.cc https://gem5.googlesource.com/amd/gem5/+/refs/heads/master/src/mem/ruby/system/GPUCoalescer.cc We absolutely plan to support the public branch long-term, but yes, currently we were hoping to only support VIPER." From: Poremba, Matthew via gem5-users <gem5-users@gem5.org> Sent: Wednesday, February 8, 2023 2:43 PM To: The gem5 Users mailing list <gem5-users@gem5.org> Cc: VIPIN PATEL <patelvipi...@gmail.com>; Poremba, Matthew <matthew.pore...@amd.com> Subject: [gem5-users] Re: Unavailability of GPU_RfO and GPU_VIPER_Region protocol in gem5 v21 [AMD Official Use Only - General] Hi, GPU_RfO and GPU_VIPER_Region were deprecated, mostly because there is no one to help maintain all of the GPU protocols, so we opted to focus on just one. I don't think there have been any Ruby/SLICC changes that would have broken the ability to build them though, so I suspect you could simply copy them from an older gem5 version and it would work. Basically you'll want to make sure you have all the files listed in src/mem/ruby/protocol/GPU_RfO.slicc, the GPU_RfO build_opts file (or use the scons variable), and similarly for GPU_VIPER_Region. -Matt From: VIPIN PATEL via gem5-users <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Sent: Monday, February 6, 2023 7:48 PM To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Cc: VIPIN PATEL <patelvipi...@gmail.com<mailto:patelvipi...@gmail.com>> Subject: [gem5-users] Unavailability of GPU_RfO and GPU_VIPER_Region protocol in gem5 v21 Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. Dear All, The GPU_RfO and GPU_VIPER_Region protocol were part of the gem5 v20.1.0.5<https://gem5.googlesource.com/public/gem5/+/refs/tags/v20.1.0.5/src/mem/ruby/protocol/> but were removed from v21.0.0.0<https://gem5.googlesource.com/public/gem5/+/refs/tags/v21.0.0.0/src/mem/ruby/protocol/> onwards. The removal of these protocols is not mentioned in the release notes<https://gem5.googlesource.com/public/gem5/+/refs/tags/v21.0.0.0/RELEASE-NOTES.md>. I had a few queries: a) Are these protocols merged into other protocols or deprecated? b) Can we port the Ruby and SLICC state machine files for GPU_RfO and the Viper protocol to a newer version of Gem5? What engineering challenges need to be addressed? Regards, Vipin
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
