Skip to content

ParaView: Allow choosing a CUDA architecture.#20623

Merged
tldahlgren merged 1 commit intospack:developfrom
RemiLacroix-IDRIS:paraview
Jan 5, 2021
Merged

ParaView: Allow choosing a CUDA architecture.#20623
tldahlgren merged 1 commit intospack:developfrom
RemiLacroix-IDRIS:paraview

Conversation

@RemiLacroix-IDRIS
Copy link
Copy Markdown
Contributor

This is useful when the "native" architecture cannot be guessed.

This is useful when the "native" architecture cannot be guessed.
description='Use module kits')
variant('cuda_arch', default='native', multi=False,
values=('native', 'fermi', 'kepler', 'maxwell',
'pascal', 'volta', 'turing', 'all', 'none'),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to skip ampere, which is supported by two of vtk-m's options (80 and 86)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I think I have looked at the code from the latest version of vtk-m and seen no mention of ampere: https://gitlab.kitware.com/vtk/vtk-m/-/blob/v1.5.1/CMake/VTKmDeviceAdapters.cmake#L161.

It seems to be in the master branch though so I can add it to be future-proof.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just looking at the vtk-m package so was more curious. I haven't investigated when the ampere options were added.

Copy link
Copy Markdown
Contributor

@tldahlgren tldahlgren Jan 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO that can be addressed in a subsequent PR if it becomes an issue.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure!

Copy link
Copy Markdown
Contributor

@tldahlgren tldahlgren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@tldahlgren tldahlgren merged commit 18d14eb into spack:develop Jan 5, 2021
@tldahlgren
Copy link
Copy Markdown
Contributor

Thank you for your contribution!

@RemiLacroix-IDRIS RemiLacroix-IDRIS deleted the paraview branch January 5, 2021 18:42
bollig pushed a commit to bollig/spack that referenced this pull request Jan 12, 2021
This is useful when the "native" architecture cannot be guessed.
loulawrence pushed a commit to loulawrence/spack that referenced this pull request Jan 19, 2021
This is useful when the "native" architecture cannot be guessed.
@sethrj
Copy link
Copy Markdown
Contributor

sethrj commented Jul 13, 2021

@RemiLacroix-IDRIS The cuda_arch names in this PR override and conflict with the numeric ones defined in the base CudaPackage, which was made a subclass of the paraview package in #12996 two years ago. Were you aware of the existing cuda_arch definition when you did that? Can one of the maintainers @chuckatkins @danlipsa @vicentebolea comment ?

(When I try concretizing nalu-wind in spack with the clingo concretizer, I see an error:

spack.variant.InvalidVariantValueError: invalid values for variant "cuda_arch" in package "paraview": ['10']

)

@RemiLacroix-IDRIS
Copy link
Copy Markdown
Contributor Author

@sethrj: I think I was aware of it but didn't think much about it back then. Before my change the cuda_arch variant was inherited from CudaPackage but not used. I could have kept the numeric values for that variant and done a "translation" but I didn't think about it.

I think there are probably some other cases like this where the "native" CUDA arch understood by the build script was preferred over the generic CUDA arch inherited from Spack.

@vicentebolea
Copy link
Copy Markdown
Member

@sethrj @RemiLacroix-IDRIS this is being resolved at #23257.

The reason of the ParaView pkg having a cuda_arch with the names of the CUDA architectures instead of its numbers is that VTK-m, a dependency of ParaView, to specify the CUDA architecture expects the name (not the number).

@sethrj
Copy link
Copy Markdown
Contributor

sethrj commented Jul 13, 2021

OK, so perhaps the error I'm getting is a problem with the concretizer rather than the override. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants