[Mesa-dev] pfn_notify in clCreateContext()

Giuseppe Bilotta giuseppe.bilotta at gmail.com
Sun Mar 5 21:28:53 UTC 2017


On Fri, Feb 24, 2017 at 5:30 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> I'd like to point out that when I hooked up this logic in clover
> (after my triumphant addition of KHR_debug in gallium), I had no idea
> how OpenCL stuff worked. I still don't. If you think passing this type
> of information is inappropriate, or that some of the message types
> should be filtered out, you should go ahead and do that.
>
> src/gallium/state_trackers/clover/core/queue.cpp::debug_notify_callback
>
> The API was mostly modeled after the KHR_debug capabilities, so if it
> doesn't fit well with what OpenCL wants, you can also just revert my
> commit that hooked it up. It was purely speculative, without an actual
> use-case in mind.

Some of that information could be made available via OpenCL APIs (for
example, LDS via clGetKernelInfo, and the the wavefront count via
clGetKernelSubGroupInfo, available since 2.1
https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/clGetKernelSubGroupInfo.html,
also available on Intel platforms via an extension on 1.2
implementations), however I can't find any clGet*Info where all of the
information could be stuffed in coherently (on 1.x there's the
clGetKernelWorkGroupInfo() cal which requires a kernel and a device,
and would thus be suited, but the name doesn't really fit).

I think the information can potentially be interesting, but it might
be necessary to design an extension to expose all of it (or at least
the part not already available in 1.x APIs). Something like
clGetKernelResourceUsageMESA(), taking a kernel and device (plus the
usual set of parameter name, size, pointer, return size), with one key
per info?

-- 
Giuseppe "Oblomov" Bilotta


More information about the mesa-dev mailing list