Repository navigation
Conversation
As discussed in the December 10th teleconference.
|
Discussed in the January 7th teleconference. We're going to keep tracking the unified SVM test plan using this PR, at least for now. We will use PR suggestions to propose changes or additions, or to tick off items on the task list, as various tests are merged. |
Adds a unified SVM consistency check test, as per the description in #2150. Note that the target branch for this PR is the cl_khr_unified_svm branch, not the main branch.
|
I just updated the test plan with the tests that are implemented so far. |
Since the specification removed support for blocking frees, there are no flags or properties that need to be tested, so the testing via the fixture is sufficient.
…SuggestedTypeIndexKHR
|
|
||
| ## Test Plan | ||
|
|
||
| ### Consistency Check |
There was a problem hiding this comment.
We don't currently have any consistency checks for unified SVM capabilities and OpenCL 2.0 SVM capabilities (CL_DEVICE_SVM_CAPABILITIES). Should we add this? If so, do we want consistency checks in both directions, or in just one?
- Old -> New: If a device exposes the OpenCL 2.0 SVM capabilities and supports unified SVM, then the device should support the same functionality via unified SVM.
- New -> Old: If a device exposes functionality via unified SVM, then the device should support the same functionality via OpenCL 2.0 SVM capabilities, also.
Regarding (1), an implementation could conceivably / theoretically want to expose OpenCL 2.0 SVM capabilities for backwards compatibility, but not support the same capabilities for newer code (that may only be checking for unified SVM capabilities). Is this a scenario we would want to support?
I cannot think of a reason an implementation would not want to do (2) off the top of my head.
|
|
||
| ## Test Plan | ||
|
|
||
| ### Consistency Check |
There was a problem hiding this comment.
With the addition of the concurrent access atom size query, we should add a few more consistency checks:
- For each set of SVM capabilities, if the capabilities includes the concurrent access capability, then the concurrent access atom size must be non-zero. Otherwise, when the capabilities does not include the concurrent access capability, the concurrent access atom size must be zero.
Please note, this PR targets a cl_khr_unified_svm branch, not the main branch, as we discussed.
It has an initial proposed test plan, for review.
see: #2149