Skip to content

Update device and platform version descriptions #231

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
keryell merged 6 commits into from
May 5, 2022
Merged

Update device and platform version descriptions #231

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
663c3e4
Update device and platform version descriptions
npmiller Feb 24, 2022
2ecbb67
Deprecate device version and don't report spec revision
npmiller Mar 25, 2022
c499eee
Clarify information descriptor mapping for OpenCL backend
npmiller Mar 30, 2022
2806ab0
Revert "Deprecate device version and don't report spec revision"
npmiller Mar 30, 2022
aa1a98a
Define device version as backend defined
npmiller Mar 30, 2022
694a51a
Leave the driver version up to vendors
npmiller Mar 31, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 11 additions & 9 deletions adoc/chapters/opencl_backend.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,15 +149,17 @@ combination of the two.

The SYCL system presents the user with a set of devices, grouped into some
number of platforms.
The device version is an indication of the device's
capabilities, as represented by the device information returned by the
[code]#sycl::device::get_info()# member function. Examples of attributes
associated with the device version are resource limits and information
about functionality beyond the requirements in the <<core-spec>>.
The version returned corresponds to the highest version of the OpenCL
specification for which the device is conformant, but is not higher than
the version of the device's platform which bounds the overall capabilities
of the runtime operating the device.

The version returned by [code]#sycl::platform::get_info()# and
[code]#sycl::device::get_info()# for the attributes
[code]#info::platform::driver_version# and [code]#info::device::driver_version#
respectively, represents the OpenCL software driver version in the form:
[code]#major_number.minor_number#.

@gmlueck gmlueck Mar 25, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it the intent that this number corresponds to the OpenCL specification version? For example, "1.2" would indicate that the backend conforms to OpenCL 1.2 and "3.0" would indicate that it conforms to OpenCL 3.0?

When I read this before, I though the intent was for each vendor to return some vendor-specific version number of the device driver. This is what DPC++ does currently. For example, we currently return this for one of our OpenCL devices:

"2021.13.11.0.23_160000"

@npmiller npmiller Mar 30, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the intent for the device driver version is to report whatever the OpenCL implementation reports for CL_DRIVER_VERSION, and that's defined in the OpenCL 1.2 spec as:

OpenCL software driver version string in the form major_number.minor_number

Which, looking at a couple other OpenCL implementation seems to be a vendor specific number but still supposed to be a major_number.minor_number string, which is fairly arbitrary.

Since this part is for the OpenCL backend maybe we should just spell out what OpenCL properties these are intended to map to rather than copy-paste the definition from the OpenCL spec.

@npmiller npmiller Mar 30, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've re-worked this paragraph into a table referring to the OpenCL properties which I think should be much clearer.

However I noticed that in the comments this section was referring to another one from the main spec: Platform mixed version support.

But I can't really make sense of what this section is trying to say or how this part of the OpenCL backend spec was addressing it, does it have something to do with the abandoned idea of mixing SYCL 1.2 and 2.2 devices as @keryell suggested?

@keryell keryell Apr 15, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think this is to suggest that while the top-level supported version has some SYCL versions but using some platform might supporting only an older SYCL version. But since we no longer have true feature inclusion, I am not sure it still makes sense.


The version returned for the device corresponds to the highest version of the
OpenCL specification for which the device is conformant, but is not higher than
the version of the device's platform which bounds the overall capabilities of
the runtime operating the device.


=== OpenCL memory model
Expand Down
8 changes: 3 additions & 5 deletions adoc/chapters/programming_interface.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1187,7 +1187,7 @@ info::platform::version
----

@ [.code]#std::string#
a@ Returns the software driver version of the <<device>>.
a@ Returns a backend-defined <<platform>> version.

a@
[source]
Expand Down Expand Up @@ -2401,8 +2401,6 @@ info::device::driver_version

@ [.code]#std::string#
a@ Returns a backend-defined driver version as a [code]#std::string#.
If using the OpenCL backend, the returned value represents the
OpenCL software driver version in the form: major_number.minor_number.

@gmlueck gmlueck Mar 30, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that the OpenCL backend interop spec says this corresponds to CL_DRIVER_VERSION. OpenCL 3.0 defines that as:

OpenCL software driver version string. Follows a vendor-specific format.

Since OpenCL doesn't mandate any specific format, should we just say this in the SYCL spec directly? The SYCL definition would then be something like:

A vendor-defined string describing the version of the underlying backend software driver.

@npmiller npmiller Mar 31, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh it got updated in 3.0! That's a better definition for sure.

A vendor-defined string describing the version of the underlying backend software driver.

I feel like this a bit in conflict with the idea of having it backend-defined, the way I see it we say it's backend-defined in the main spec, then in the backend spec we can define it further to vendor-defined if we want, for the OpenCL plugin saying it's CL_DRIVER_VERSION defers it to the OpenCL spec which ends up being vendor defined anyway.

But then for say a CUDA backend we could define it to the compute capability in the format major.minor for example rather than having it vendor defined.

But if we just say it's vendor defined in the main spec I feel like we can't really give more details on what it's supposed to be in the backend spec.

@gmlueck gmlueck Mar 31, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the motivation for specifying this query as backend-defined, though? Most of our queries are not backend-defined. If the intent of driver_version is to return the version string of the vendor's device driver, it's hard to see why a backend would mandate any specific format. Wouldn't we want each vendor to have the freedom to decide it's own format?

@npmiller npmiller Mar 31, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right! I was still thinking about the version rather than the driver_version, since the driver_version was already backend specific before my patch.

But now that I think about it, I do think you're right that it makes more sense to have the driver_version simply be vendor specific, I'll change it as well.

@npmiller npmiller Mar 31, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the driver_version as suggested and removed the CL_DRIVER_VERSION part from the OpenCL backend spec.


a@
[source]
Expand Down Expand Up @@ -2431,8 +2429,8 @@ info::device::version
----

@ [.code]#std::string#
a@ Returns the SYCL version as a [code]#std::string# in the form:
[code]#<major_version>.<minor_version>#.
a@ Returns the year based SYCL version as a [code]#std::string#. This
property is deprecated.

a@
[source]
Expand Down
2 changes: 2 additions & 0 deletions adoc/chapters/what_changed.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -262,6 +262,8 @@ that only selects devices that have all the requested aspects.
The device query [code]#info::fp_config::correctly_rounded_divide_sqrt# has
been deprecated.

The device query [code]#info::device::version# has been deprecated.

A new reduction library consisting of the [code]#reduction# function and
[code]#reducer# class was introduced to simplify the expression of variables
with <<reduction>> semantics in SYCL kernels. See <<sec:reduction>>.
Expand Down