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 5 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
28 changes: 14 additions & 14 deletions adoc/chapters/opencl_backend.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -144,21 +144,21 @@ units (where each PE maintains its own program counter) or as some
combination of the two.


// From Architecture, Section 3.3.1 (Platform mixed version support)
=== Platform mixed version support

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.
=== Backend specific information descriptors

Some of the SYCL information descriptors are backend-defined. For the OpenCL
backend these information descriptors map directly to OpenCL properties as
described in the table below:

[[table.opencl.info]]
.Mapping of SYCL information descriptors to OpenCL properties
[width="40%",options="header",cols="50%,50%"]
|====
| SYCL | OpenCL
| [code]#info::platform::version# | [code]#CL_PLATFORM_VERSION#
| [code]#info::device::version# | [code]#CL_DEVICE_VERSION#
| [code]#info::device::driver_version# | [code]#CL_DRIVER_VERSION#
|====

=== OpenCL memory model

Expand Down
7 changes: 2 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,7 @@ 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 a backend-defined <<device>> version.

a@
[source]
Expand Down