You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The level zero API does not natively support querying out information about its image and sampler handles. We could implement this support by storing all the information that can be queried out in the UR handle during construction, but this falls over if we ever implement SamplerCreateWithNativeHandle or ImageCreateWithNativeHandle - these are ways to construct the objects without providing all the information we'd need to store to support the queries.
In practice not supporting these queries isn't a big deal for current users of UR images, sycl image support works just fine on level zero because the sycl implementation stores image info in its own objects rather than relying on the backend API. In principal there's maybe an argument to be made that if something resembling these queries is supported by anything we want to implement with UR then they should be supported by UR, the fact that the sycl implementation we currently support doesn't need them doesn't necessarily reflect the requirements we need to encode in the spec.
As I see it there's two options:
Image and sampler queries remain a non-optional feature in the spec, we say we are going to implement them for level zero with the caveat that they will not work for objects created from native handles. This would be tricky to communicate clearly, and if we ever get to the point of supporting native handle images and image queries on the level zero adapter I feel it would inevitably lead to someone trying to use them together and being confused when it doesn't work.
Image and sampler queries are all made optional, either by the definition of optional described in Explicitly define which info queries are optional. #1332 or by adding some "image queries" device info flag. Also would probably require a bit of clarification in the spec for the image support flag around what entry points and functionality reporting "image support" actually means. This could have the same problem as the first option in that it's unintuitive and not easy to communicate clearly - like we can write it in the spec but whether that's enough to prevent someone seeing that the level zero adapter is reporting image support and then being confused when the queries don't work is debatable.
The text was updated successfully, but these errors were encountered:
The level zero API does not natively support querying out information about its image and sampler handles. We could implement this support by storing all the information that can be queried out in the UR handle during construction, but this falls over if we ever implement
SamplerCreateWithNativeHandle
orImageCreateWithNativeHandle
- these are ways to construct the objects without providing all the information we'd need to store to support the queries.In practice not supporting these queries isn't a big deal for current users of UR images, sycl image support works just fine on level zero because the sycl implementation stores image info in its own objects rather than relying on the backend API. In principal there's maybe an argument to be made that if something resembling these queries is supported by anything we want to implement with UR then they should be supported by UR, the fact that the sycl implementation we currently support doesn't need them doesn't necessarily reflect the requirements we need to encode in the spec.
As I see it there's two options:
The text was updated successfully, but these errors were encountered: