[Testing] Improve "program" testing to better match the DPC++ e2e tests #1503
Conversation
RossBrunton
force-pushed
the
ross/e2e_program
branch
11 times, most recently
from
8a560e3
to
f9883fd
Compare
RossBrunton
force-pushed
the
ross/e2e_program
branch
18 times, most recently
from
2b1e40d
to
5594569
Compare
| @@ -1,3 +1,4 @@ | |||
| urProgramCreateWithILTest.BuildInvalidProgram/Intel_R__OpenCL___{{.*}}_ | |||
There was a problem hiding this comment.
is this based on an e2e test that passes on any platforms? if not it might not be worth testing, none of the adapters that support IL pass and realistically we aren't going to write something to validate IR for each of those adapters just to pass a cts test
There was a problem hiding this comment.
I thought it did, but apparently the error was coming from urProgramBuild rather than create. I've added a quick test case for that.
Despite not passing in CI, this test does pass for me locally, so some devices handle it correctly.
If we aren't going to validate IR, should we amend the spec to explicitly call out that it's not required for implementations to validate that the IR is correct?
There was a problem hiding this comment.
Yeah it would be good to note that validation doesn't necessarily happen at the ProgramCreate step
RossBrunton
force-pushed
the
ross/e2e_program
branch
7 times, most recently
from
097ec9f
to
bb2dec8
Compare
github-actions
bot
added
loader
RossBrunton
force-pushed
the
ross/e2e_program
branch
8 times, most recently
from
59731cf
to
1b80a22
Compare
This adds a number of conformance tests to test things that are required for the "program" DPC++ e2e tests. Note that these tests don't all pass. Adapter testing infrastructure for level zero has been added, and a single test has been added to check their specific handling of linker errors (they write it to the build log of the output program). Other than that, test additions are as follows: * A few specialization constant tests to test usage of a kernel with multiple specialization constants defined. * Testing of the default specialization values. * KernelGetInfo outputs the correct kernel name and context pointer. * Compiling an (valid or invalid) program produces a valid (though unspecified) build log. * The "num devices" program info is sensible.
RossBrunton
force-pushed
the
ross/e2e_program
branch
from
1b80a22
to
722f6c0
Compare
This adds a number of conformance tests to test things that are required for the "program" DPC++ e2e tests.
Adapter testing infrastructure for level zero has been added, and a single test has been added to check their specific handling of linker errors (they write it to the build log of the output program).
Other than that, test additions are as follows: