Comments (8)
Want to confirm I understand this proposal because I agree having clear messaging to users on how to deal with API changes is a nice improvement.
The goal is that users will be able to write code like this?
// Application code.
#if CL_FOO_KHR_VERSION == 1
clFooKHR(bar);
#elif CL_FOO_KHR_VERSION == 2
clFooKHR(baz);
#endif
And in cl_ext.h
we'd define the macro like:
// cl_ext.h
#define CL_FOO_KHR_VERSION N
// APIs for revision N ....
// No APIs for revisions earlier than N
And ideally the version macro would be generated from the revision
component in the XML <extension>
entry using gen_headers.py
.
Is that what you had in mind?
from opencl-headers.
It seems like you would need a runtime query for the actual extension version supported by the driver, rather than statically compiling against the version that happens to be in the header file you built the app with?
from opencl-headers.
That's a good point, a runtime could return a different signature from clGetExtensionFunctionAddressForPlatform than the signature that the app was built with.
We do have an existing runtime query CL_DEVICE_EXTENSIONS_WITH_VERSION that we could leverage.
from opencl-headers.
@EwanC That's exactly what I had in mind.
@oddhack We already have runtime queries but we're missing a mechanism for compile-time checks similar to the *_SPEC_VERSION
macros that the Vulkan headers provide. It's particularly problematic for provisional extensions that are less stable and for which breaking changes can occur between released versions of the headers.
from opencl-headers.
FWIW, the Vulkan experience led to our current approach where we disallow breaking changes in extension revisions - they are only to indicate fixes to spec language, not behavior. If a shipping extensions is fundamentally broken then we may do a new extension that replaces or modifies it, which is thankfully infrequent.
There are two exceptions I can think of offhand:
- Occasionally a vendor ships a new vendor extension and almost immediately realizes something was wrong with it. Since the burden is entirely on that vendor, if they want to make a breaking change that's their call.
- Provisional extensions can change in an arbitrary fashion and as you say, we do have the compile-time macro to rely on, but not the runtime query as you do. The burden is on the ISV to ensure they are using a driver consistent with their header, which has not led to complaints so far (or at least, not that I'm aware of - vendors may be getting negative feedback we don't hear about).
from opencl-headers.
One of the cases we discussed was that of an application that does not bundle headers. Different environments could use a different released version of the headers, possibly with incompatible or missing definitions. Having a macro could be helpful in some scenarios. An application could add preprocessor checks and emit warnings/errors if the version is not as expected. They could also potentially adapt to behaviour changes or other compile-time breaking changes. The one thing they could not always do is build a single binary that would work with a range of versions (at least not without providing definitions themselves).
Another case we discussed was that of backwards-compatible additions to extensions that we do allow in CL. v2 of an extension could add a new enum or command whose use could be cleanly guarded by a version macro (it is possible in some cases to use #ifdef
on the definitions themselves but not always).
but not the runtime query as you do
Couldn't VkExtensionProperties::specVersion
be used for this?
from opencl-headers.
Assigning myself to try draft this up, because I think it effectively blocks KhronosGroup/OpenCL-Docs#1045 if want users to have a good experience of handling that API break.
from opencl-headers.
Related Issues (20)
- how can i generate libOpenCL.so HOT 2
- 【question】: Is cl.hpp removed? HOT 5
- WiFi cracker HOT 1
- should the headers include an extension version?
- #include <libclew/ocl_init.h> HOT 1
- Why cannot find <CL\opencl.h> when using Android NDK Building? HOT 1
- Generate tests that use all definitions provided by the headers HOT 1
- missing POCL vendor ID
- Added this repo as a submodule HOT 2
- Increment CMake Version Number HOT 1
- re-enable testing in test_half
- How to install OpenCL SDK for FreeBSD?
- Build warning/note
- install *.pc below CMAKE_INSTALL_DATADIR HOT 3
- clEnqueueWriteHostPipeINTEL XML discrepancy HOT 3
- XML and header discrepancy for clSetMemObjectDestructorAPPLE HOT 1
- Random value when use pragma unroll
- Guard definitions for provisional extensions with a dedicated opt-in macro
- update copyright dates to 2024
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opencl-headers.