Replies: 2 comments 3 replies
-
I wanted to get a feel for how expensive option 2 would be, as it requires some rewriting of the test. I grepped for "UNSUPPORTED pre-sm-". There are 253 hits.
I fear option 1 and 2 might not work very well with the atomics and barrier headers (the 154 tests for SM70), because they are simply guarded at include time by My gut instinct would be to rewrite the 26 tests that rely on SM80 or SM90 (i.e. option 2) and leave the SM60 and SM70 tests as they are. |
Beta Was this translation helpful? Give feedback.
-
Option 3 is a non-starter imo. A key requirement is our testing should reflect how users use our code, and that means compiling a TU for multiple architectures. Filtering out a request to compile multiple archs to actually compile for one would be counter to that goal. All other things being equal, option 2 would be my preference because it most closely mirrors what user code would look like. That said, it would be a lot of manual work. Could we combine options 1&2 by preprocessing the header and adding another wrapper around the |
Beta Was this translation helpful? Give feedback.
-
Libcudacxx Test Architecture Changes
Our tests in libcudacxx currently have several issues. If a test excludes certain SMs, it won't be built, even if there are architectures that do support the test. This means that tests ultimately can deny large SM matrix builds from giving coverage. Worse, testing requires a CUDA device, I think it's reasonable to allow testing purely on CPU if a GPU or incompatible GPU is present.
Possible solution
Ideally libcudacxx tests should build every SM possible and simply exclude the incompatible SMs. This means if a test has no effect on SM70 and below, then SM70- should be no-ops. The kernels can be empty, or not launched. This allows everything else to build, CPU tests to execute, and if possible still launch on supported SMs.
An example process for
lit
with a test file that excludes SMs.The above requires changes to parsing in lit. This is easily handled by adding a new parser in our config. However rejecting incompatible SMs in
main
or blocking includes intest.pass.cpp
will likely require substantial changes. Possible options are:These are just a couple ideas of ways we could try to solve the problem, I'm sure there are more and would like to field those as well.
Beta Was this translation helpful? Give feedback.
All reactions