[Beignet] [PATCH] Add clGetKernelSubGroupInfoKHR to _cl_icd_dispatch table

Pan, Xiuli xiuli.pan at intel.com
Tue Oct 11 02:46:40 UTC 2016


Hi, 
The api clGetKernelSubGroupInfoKHR for OpenCL 1.2 is added for the extension  cl_intel_subgroups.
https://www.khronos.org/registry/cl/extensions/intel/cl_intel_subgroups.txt

And I add it in https://cgit.freedesktop.org/beignet/commit/?id=aa3ee67c825fbef5f68b31345c060c981bf35ad3

Now I see that the problem is the API cannot be used through ICD, but in OpenCL1.2 it is a vender extension. Should we use the ICD OpenCL2.0 API table of it?
Or maybe we should not use clGetExtensionFunctionForPlatform or clGetExtensionFunction to get the API clGetKernelSubGroupInfoKHR?

Thanks
Xiuli


-----Original Message-----
From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On Behalf Of Rebecca N. Palmer
Sent: Tuesday, October 11, 2016 7:07 AM
To: Yang, Rong R <rong.r.yang at intel.com>; beignet at lists.freedesktop.org
Subject: Re: [Beignet] [PATCH] Add clGetKernelSubGroupInfoKHR to _cl_icd_dispatch table

> This patch causes a warning:
> /home/yr /beignet/src/cl_khr_icd.c:187:3: warning: initialization from incompatible pointer type
>    clGetKernelSubGroupInfoKHR,
>
> /home/yr/maintain/beignet/src/cl_khr_icd.c:187:3: warning: (near 
> initialization for ‘cl_khr_icd_dispatch.clUnknown136’)

I see that as well, but it does work (with both old and new ocl-icd).

> clGetKernelSubGroupInfoKHR is available from OpenCL2.0, also need OpenCL version check in beignet?
>
> BTW: ocl-icd 2.2.8's OCL_ICD_IDENTIFIED_FUNCTIONS is 128, is it a typo?

#ifdef CL_VERSION_* checks in current Beignet always give 1.2, the version of Beignet's copy of CL/cl.h, but what we actually care about here is the version ocl-icd (the ICD loader) was built with: the #if (OCL_ICD_IDENTIFIED_FUNCTIONS > 110) is an "OpenCL >=2.0" check for that.  (I got the idea from pocl,
https://anonscm.debian.org/cgit/collab-maint/pocl.git/tree/lib/CL/clGetPlatformIDs.c)

This matters because the ICD loader has a table of function names (function_description), while the ICD has a table of function addresses
(_cl_icd_dispatch) **but no way to tell the loader how long this table is**, and the ICD loader's clGetExtensionFunctionForPlatform does "search the name table for the requested name, if found return that slot in the address table (even if that's NULL or off-the-end garbage), if not found in the name table ask the ICD's
clGetExtensionFunctionForPlatform":
https://www.khronos.org/registry/cl/sdk/2.1/docs/man/xhtml/clGetExtensionFunctionAddressForPlatform.html
https://forge.imag.fr/plugins/scmgit/cgi-bin/gitweb.cgi?p=ocl-icd/ocl-icd.git;a=blob;f=icd_generator.rb;h=d299dbd252ac4b25e62d2e44c0c40dcd179ca3f6;hb=HEAD#l576

Hence, functions that are in the ICD loader's name table but not the ICD's address table are impossible to use via ICD, and trying to do so may even crash.

The reverse, i.e. having functions in the address table but not the name table, is harmless as long as you don't overflow the table's total length (now OCL_ICD_IDENTIFIED_FUNCTIONS+50 but was +20 pre-2.0, https://forge.imag.fr/plugins/scmgit/cgi-bin/gitweb.cgi?p=ocl-icd/ocl-icd.git;a=blob;f=icd_generator.rb;h=d299dbd252ac4b25e62d2e44c0c40dcd179ca3f6;hb=HEAD#l72);
hence my use of one #if (OCL_ICD_IDENTIFIED_FUNCTIONS > 110) for the whole OpenCL 2.0 block, rather than separate ones for 2.0-core (positions 123-135, not currently implemented in Beignet,
OCL_ICD_IDENTIFIED_FUNCTIONS>110) and clGetKernelSubGroupInfoKHR (position 136, >120).

_______________________________________________
Beignet mailing list
Beignet at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/beignet


More information about the Beignet mailing list