KhronosGroup / KhronosGroup/OpenCL-CTS
requiredAllocSize in min_max_mem_alloc_size does not match current CL_DEVICE_MAX_MEM_ALLOC_SIZE minimum for either profile
- Dominant language
- C++
- Stars
- 232
- Forks
- 235
- Avg merge
- 8d 7h
- Merged PRs (30d)
- 18
Description
Related to #2795
`min_max_mem_alloc_size` in `test_conformance/api/test_api_min_max.cpp` hardcodes:
```
if (gIsEmbedded)
requiredAllocSize = 1 * 1024 * 1024;
else
requiredAllocSize = 128 * 1024 * 1024;
```
Current spec text for `CL_DEVICE_MAX_MEM_ALLOC_SIZE`:
> Max size of memory object allocation in bytes. The minimum value is max(min(1024 x 1024 x 1024, 1/4th of CL_DEVICE_GLOBAL_MEM_SIZE), 32 x 1024 x 1024).
That puts the actual floor at 32 MB for full profile, not 128 MB.
`CL_DEVICE_MAX_MEM_ALLOC_SIZE` has no entry in the embedded profile relaxation table (embedded-device-queries-table in embedded_profile.asciidoc), so the same 32 MB floor applies to embedded devices too. The 1 MB used here is roughly 32x below that.
Questions:
- Should requiredAllocSize be lowered to 32 MB for both profiles to match the documented minimum, or is there a reason CTS intentionally holds a stricter bar for full profile and a laxer one for embedded?
- If the latter, should the spec wording be revisited instead?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in test_conformance/api/test_api_min_max.cpp at min_max_mem_alloc_size, then compare its profile-specific values with the CL_DEVICE_MAX_MEM_ALLOC_SIZE specification and embedded_profile.asciidoc. Resolve whether the CTS expectation or specification is authoritative, update the affected documentation or test behavior accordingly, and run the relevant API conformance test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100