-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Ecal Phase2 Weights-based Reconstruction, Alpaka integration #47124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ecal Phase2 Weights-based Reconstruction, Alpaka integration #47124
Conversation
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-47124/43345
|
A new Pull Request was created by @Jakub-Gajownik for master. It involves the following packages:
@cmsbuild, @jfernan2, @mandrenguyen can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
type ecal |
enable gpu |
1 similar comment
enable gpu |
please test |
+1 Size: This PR adds an extra 32KB to repository Comparison SummarySummary:
GPU Comparison SummarySummary:
|
assign heterogeneous |
+1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this code tested in any workflow?
EcalPhase2DigiToPortableProducer::EcalPhase2DigiToPortableProducer(edm::ParameterSet const &ps) | ||
: inputDigiToken_(consumes<EBDigiCollectionPh2>(ps.getParameter<edm::InputTag>("BarrelDigis"))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are in a process of requiring the Alpaka-based EDProducers to pass the edm::ParameterSet
to the base class constructor (with the goal of preventing base class default constructor in 15_0_0_pre3). It would be helpful to do that already in this PR. I'd suggest to rebase to 15_0_0_pre2 (or any IB of this year) and
EcalPhase2DigiToPortableProducer::EcalPhase2DigiToPortableProducer(edm::ParameterSet const &ps) | |
: inputDigiToken_(consumes<EBDigiCollectionPh2>(ps.getParameter<edm::InputTag>("BarrelDigis"))), | |
EcalPhase2DigiToPortableProducer::EcalPhase2DigiToPortableProducer(edm::ParameterSet const &ps) | |
: EDProducer<>(ps), | |
inputDigiToken_(consumes<EBDigiCollectionPh2>(ps.getParameter<edm::InputTag>("BarrelDigis"))), |
digisHostCollView.size() = i; | ||
|
||
//copy collection from host to device | ||
alpaka::memcpy(event.queue(), digisDevColl.buffer(), digisHostColl.buffer()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this EDProducer only copies data from host to device (without any kernels), in 15_0_0_pre2 this explicit copy from host to device could be avoided by the EDProducer producing the EcalDigiPhase2HostCollection
as a host-side data product (i.e. with edm::EDPutTokenT
). The framework would then implicitly copy that to the device (see https://github.com/cms-sw/cmssw/blob/80d1847/HeterogeneousCore/AlpakaCore/README.md#edproducer for more details).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you clarify whether the Digi producer in this case becomes a normal edm::global producer and should be moved outside of the Alpaka namespace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should still be an alapaka-based producer in the ALPAKA_ACCELERATOR_NAMESPACE
namespace.
See EventFilter/HcalRawToDigi/plugins/alpaka/HcalDigisSoAProducer.cc for an example.
|
||
#include "DataFormats/EcalDigi/interface/alpaka/EcalDigiPhase2DeviceCollection.h" | ||
#include "DataFormats/EcalRecHit/interface/alpaka/EcalUncalibratedRecHitDeviceCollection.h" | ||
#include <alpaka/alpaka.hpp> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be more clear to have the #include
s of external packages and CMSSW headers in separate "blocks", and order the CMSSW headers in alphabetical order.
template <typename TAcc> | ||
ALPAKA_FN_ACC void operator()(TAcc const &acc, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be
template <typename TAcc> | |
ALPAKA_FN_ACC void operator()(TAcc const &acc, | |
ALPAKA_FN_ACC void operator()(Acc1D const &acc, |
}; | ||
|
||
template <typename TAcc> | ||
ALPAKA_FN_ACC void Phase2WeightsKernel::operator()( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There would be less repetition (of function arguments) if the implementation would be at the function declaration few lines above.
@@ -0,0 +1,2 @@ | |||
import RecoLocalCalo.EcalRecProducers.ecalUncalibRecHitPhase2WeightsProducerPortable_cfi as _mod | |||
ecalUncalibRecHitPhase2Portable = _mod.ecalUncalibRecHitPhase2WeightsProducerPortable.clone() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose of this file? I mean, is it useful to have both ecalUncalibRecHitPhase2WeightsProducerPortable_cfi
and ecalUncalibRecHitPhase2Portable_cfi
?
|
||
private: | ||
const edm::EDGetTokenT<EBDigiCollectionPh2> inputDigiToken_; | ||
const device::EDPutToken<EcalDigiPhase2DeviceCollection> outputDigiDevToken_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiousity, does the EcalDigiPhase2DeviceCollection
have other potential use than the input for EcalUncalibRecHitPhase2WeightsProducerPortable
, or do you foresee other alternative modules that would produce EcalDigiPhase2DeviceCollection
as well?
I'm asking only because if there is high certainty that this and EcalUncalibRecHitPhase2WeightsProducerPortable
will always come together, and nothing else won't use EcalDigiPhase2DeviceCollection
(or EcalDigiPhase2HostCollection
), then these two modules could be merged into one module (that would lead to a somewhat simpler setup especially in the configuration). I'm not suggesting to change the setup in this PR, but only to give an aspect to think about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we have other modules in mind. The weights producer is a baseline, but we are thinking of porting the multifit as well.
|
||
namespace ALPAKA_ACCELERATOR_NAMESPACE { | ||
|
||
class EcalPhase2DigiToPortableProducer : public stream::EDProducer<> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this module could be very easily made global::EDProducer<>
.
namespace ALPAKA_ACCELERATOR_NAMESPACE { | ||
namespace ecal { | ||
namespace weights { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These could be expressed as
namespace ALPAKA_ACCELERATOR_NAMESPACE { | |
namespace ecal { | |
namespace weights { | |
namespace ALPAKA_ACCELERATOR_NAMESPACE::ecal::weights { |
in order to have shorter indentation in the code below.
double const *timeWeightsdata, | ||
EcalDigiPhase2DeviceCollection::ConstView digisDev, | ||
EcalUncalibratedRecHitDeviceCollection::View uncalibratedRecHitsDev) const { | ||
constexpr int nsamples = EcalDataFrame_Ph2::MAXSAMPLES; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest to use either ecalPh2::sampleSize
or EcalDataFrame_Ph2::MAXSAMPLES
(I see the latter is defined to be the same as the former) both here and where weightsData
and timeWeightsdata
are allocated/defined so that a future reader can easily convince themselves that the loop below does not go over the bounds of weightsData
/timeWeightsdata
.
Change the UncalibratedRecHitsProducer to a global producer Run code-checks and code-format
-1 Failed Tests: RelVals-CUDA RelVals-CUDA
Comparison SummarySummary:
ROCM Comparison SummarySummary:
|
ignore tests-rejected with ib-failure |
I've opened #47918 to track the follow-up issues discussed here and elsewhere. |
+heterogeneous |
For me it's fine to work on the follow up issues in separate PRs. |
+1 |
+Upgrade |
+pdmv |
This pull request is fully signed and it will be integrated in one of the next master IBs (test failures were overridden). This pull request will now be reviewed by the release team before it's merged. @mandrenguyen, @rappoccio, @sextonkennedy, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
PR validation: