Do we really need distinct image and buffer properties?

[AlexeySachkov]

Specification Version

SYCL 2020 (Revision 10)

Section Number(s)

• 4.7.2.1. Buffer interface
• 4.7.2.2. Buffer properties
• 4.7.3.3. Image properties
• 4.7.6.4. Properties

Issue Description

This was prompted by me working on #814. I realized that buffer and [sampled|unsampled]_image classes accept the same set of properties, but those properties are actually defined twice within different namespaces. I.e. we have sycl::property::buffer::use_mutex and sycl::property::image::use_mutex.

Why do we have them defined twice? They seem to be doing the same thing, just for a different class. Moreover, 4.7.2.2. Buffer properties says:

The use_mutex property is valid for the SYCL buffer, unsampled_image and sampled_image classes.

However, 4.7.3.3. Image properties says:

The properties that can be provided when constructing the SYCL unsampled_image and sampled_image classes are described in Table 30.

As if buffer::use_mutex cannot be used together with unsampled_image. So, which is it?

Should we maybe deprecate both and document those properties once within sycl::property like it is done for no_init (4.7.6.4. Properties)?

Code Example (Optional)

No response

[Pennycook]

I agree. In addition to the duplication issue, I've always found the multiple levels of namespace nesting confusing. I don't use these properties very often, but when I do I tend to mix things up and write sycl::buffer::property::use_mutex by mistake -- probably because "buffer property" is closer in English to what the value represents.

It might be a good idea to clean this up if/when we introduce a compile-time properties interface. Then any new sycl::property::use_mutex (or sycl::properties::use_mutex) type could be defined in a way that's compatible with that interface, and the old type would only work with run-time property lists.

At the risk of derailing this discussion: I think we have similar issues with lots of the info definitions, too. I've never understood why we need (for example) sycl::info::platform::name and sycl::info::device::name when a simple sycl::info::name would suffice.