CUDA version lulesh.cu CalcTimeConstraintsForElems function, stream usage
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 123
- Forks
- 101
- PR merge metrics
- No merged PRs in 30d
Description
Vector_d* dev_mindtcourant= Allocator< Vector_d >::allocate(dimGrid);
Vector_d* dev_mindthydro = Allocator< Vector_d >::allocate(dimGrid);
CalcTimeConstraintsForElems_kernel <<>>
(length,qqc2,dvovmax,
domain->matElemlist.raw(),domain->ss.raw(),domain->vdov.raw(),domain->arealg.raw(),
dev_mindtcourant->raw(),dev_mindthydro->raw());
// TODO: if dimGrid < 1024, should launch less threads
CalcMinDtOneBlock <<<2,max_dimGrid, max_dimGrid*sizeof(Real_t), domain->streams[1]>>>(dev_mindthydro->raw(),dev_mindtcourant->raw(),domain->dtcourant_h,domain->dthydro_h, dimGrid);
cudaEventRecord(domain->time_constraint_computed,domain->streams[1]);
Allocator >::free(dev_mindtcourant,dimGrid);
Allocator >::free(dev_mindthydro,dimGrid);
I am not sure, but wouldn't it be an issue as dev_mindtcourant is used in streams[1] and will be free in the default stream?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in lulesh.cu at CalcTimeConstraintsForElems and trace the allocation, kernel launch, event recording, and frees for dev_mindtcourant and dev_mindthydro. Check the CUDA stream behavior around domain->streams[1] and determine whether the reported free is ordered safely; done means the lifetime is correct or the issue is documented with evidence.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- hpc
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100