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
I discovered this issue while working generated OpenCL headers for extensions (see #113).
We currently handle interop API headers (e.g. DX headers for DX interop) inconsistently:
For CL-GL sharing, we do not include any OpenGL headers and instead define opaque handles for GL objects.
For EGL sharing, we also do not include any EGL headers and instead define opaque handles for EGL objects.
For DX10 and DX11 sharing, we unconditionally include d3d10.h or d3d11.h for all platforms and operating systems.
For DX9 media sharing, we include d3d9.h only for Windows platforms.
The Intel VAAPI sharing extension unconditionally includes va.h.
The interop API header for DX9 media sharing is most inconsistent. Should we continue to guard the include for d3d9.h, or should we include it unconditionally, similar to DX10, DX11, and VAAPI sharing?
In practice, I think another way to phrase this question is: Should an application be responsible for including the header for DX9 sharing only platforms where the DX9 headers are available, or should the interop API headers attempt to be include-able for all platforms?
The text was updated successfully, but these errors were encountered:
Note the extra outermost check for #if defined(_WIN32).
Is this difference intentional? Or can we drop the guard for _WIN32? I can't imagine how the header would work without _WIN32, and indeed our testing checks for _WIN32 before including the DX9 media sharing header:
I discovered this issue while working generated OpenCL headers for extensions (see #113).
We currently handle interop API headers (e.g. DX headers for DX interop) inconsistently:
d3d10.h
ord3d11.h
for all platforms and operating systems.d3d9.h
only for Windows platforms.va.h
.The interop API header for DX9 media sharing is most inconsistent. Should we continue to guard the include for
d3d9.h
, or should we include it unconditionally, similar to DX10, DX11, and VAAPI sharing?In practice, I think another way to phrase this question is: Should an application be responsible for including the header for DX9 sharing only platforms where the DX9 headers are available, or should the interop API headers attempt to be include-able for all platforms?
The text was updated successfully, but these errors were encountered: