Khronos Public Bugzilla
Bug 826 - Re-evaluate non-visibility of parameters in WebCL for Device Info: clGetDeviceInfo (relative to OCL 1.1-Embedded)
Re-evaluate non-visibility of parameters in WebCL for Device Info: clGetDevic...
Status: RESOLVED FIXED
Product: WebCL
Classification: Unclassified
Component: Specification
1.0
All All
: P3 normal
: ---
Assigned To: WebCL Mailing List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-12 16:30 PDT by Tasneem Brutch
Modified: 2013-11-22 13:51 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tasneem Brutch 2013-03-12 16:30:26 PDT
Opening a bug to re-evaluate the non-visibility of parameters in WebCL, for Device Info: clGetDeviceInfo.  Currently the following are noted as "not visible" in Chapter 7 (Differences between WebCL and OpenCL 1.1 Embedded Profile) of the working draft.

DEVICE_VENDOR_ID	Not Visible
DEVICE_MAX_COMPUTE_UNITS	Not Visible
DEVICE_NATIVE_VECTOR_WIDTH_*	Not Visible
DEVICE_MAX_CLOCK_FREQUENCY	Not Visible
DEVICE_MEM_BASE_ADDR_ALIGN	Not Visible
DEVICE_MIN_DATA_TYPE_ALIGN_SIZE	Not Visible
DEVICE_SINGLE_FP_CONFIG	Not Visible
DEVICE_GLOBAL_MEM_CACHE_TYPE	Not Visible
DEVICE_GLOBAL_MEM_CACHELINE_SIZE	Not Visible
DEVICE_GLOBAL_MEM_CACHE_SIZE	Not Visible
DEVICE_GLOBAL_MEM_SIZE	Not Visible
DEVICE_ERROR_CORRECTION_SUPPORT	Not Visible
DEVICE_PROFILING_TIMER_RESOLUTION	Not Visible
DEVICE_COMPILER_AVAILABLE	Not Visible
DEVICE_EXECUTION_CAPABILITIES	Not Visible
DEVICE_NAME	Not Visible
DEVICE_VENDOR	Not Visible
DRIVER_VERSION	Not Visible
DEVICE_EXTENSIONS	Not Visible
Comment 1 steven eliuk 2013-03-13 16:07:56 PDT
Understanding which device to use and how to distribute work is tightly coupled with knowing these parameters. 

DEVICE_MAX_COMPUTE_UNITS	Not Visible
DEVICE_NATIVE_VECTOR_WIDTH_*	Not Visible
DEVICE_MAX_CLOCK_FREQUENCY	Not Visible


Likewise, understanding which atomics are supported is extremely important as they can be HW accelerated under certain platform.

DEVICE_EXTENSIONS	        Not Visible


Therefore, I would propose to have these visible.
Comment 2 Igor Oliveira 2013-03-13 16:14:00 PDT
We should not mix WebCL and OpenCL extensions.
If atomics are important they need to be an *WebCL* extension.

(In reply to comment #1)
> Understanding which device to use and how to distribute work is tightly
> coupled with knowing these parameters. 
> 
> DEVICE_MAX_COMPUTE_UNITS	Not Visible
> DEVICE_NATIVE_VECTOR_WIDTH_*	Not Visible
> DEVICE_MAX_CLOCK_FREQUENCY	Not Visible
> 
> 
> Likewise, understanding which atomics are supported is extremely important
> as they can be HW accelerated under certain platform.
> 
> DEVICE_EXTENSIONS	        Not Visible
> 
> 
> Therefore, I would propose to have these visible.
Comment 3 steven eliuk 2013-03-13 16:35:13 PDT
Good point Igor,

I was thinking superficially about wanting to understand what atomic support is available.

What is the current provision if a kernel wants/tries to use an atomic operation?
Comment 4 Igor Oliveira 2013-03-13 17:18:29 PDT
The validator needs to handle those cases.

(In reply to comment #3)
> Good point Igor,
> 
> I was thinking superficially about wanting to understand what atomic support
> is available.
> 
> What is the current provision if a kernel wants/tries to use an atomic
> operation?
Comment 5 steven eliuk 2013-03-14 08:08:07 PDT
There is basic atomic support in OpenCL 1.1,
http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/atomicFunctions.html

For the current WebCL-WD this is adequate,

If one wants long and ulong support an extension is needed in OpenCL 1.1, we can add this support to the next revision, as traditionally only precision sensitive apps are effected by this and these are not the target audience at this point.

Given the performance tuning possibility with these visible, I believe the following should be made visible:

DEVICE_MAX_COMPUTE_UNITS	Not Visible
DEVICE_NATIVE_VECTOR_WIDTH_*	Not Visible
DEVICE_MAX_CLOCK_FREQUENCY	Not Visible
Comment 6 Tomi Aarnio 2013-03-18 09:10:30 PDT
(In reply to comment #5)
> There is basic atomic support in OpenCL 1.1,

The built-in atomics are optional in the Embedded Profile. Would any embedded hardware vendors object to making them mandatory in WebCL?

> DEVICE_MAX_COMPUTE_UNITS	Not Visible
> DEVICE_MAX_CLOCK_FREQUENCY	Not Visible

Not sure about the clock frequency, but the number of compute units is fairly important information for developers. Perhaps the clock frequency could be exposed, but rounded to the nearest, say, 0.5 GHz? That wouldn't give out too many useful bits of information for fingerprinting.

> DEVICE_NATIVE_VECTOR_WIDTH_*	Not Visible

I'd say that DEVICE_PREFERRED_VECTOR_WIDTH_* should suffice.
Comment 7 steven eliuk 2013-04-25 00:50:38 PDT
DEVICE_MEM_BASE_ADDR_ALIGN	Visible


As for the F2F, required to specify correct 'origin' location and 'offset' for subBuffer creation. If this is not visible, one is just guessing for alignment.
Comment 8 Tomi Aarnio 2013-04-26 07:52:01 PDT
The following are to be made visible by default:

DEVICE_MAX_COMPUTE_UNITS (can be deduced by benchmarking)
DEVICE_MEM_BASE_ADDR_ALIGN (needed for createSubBuffer)
DEVICE_SINGLE_FP_CONFIG (can be deduced with test kernels)
DEVICE_COMPILER_AVAILABLE (always returns true, so can be exposed)

The following are kept not visible:

DEVICE_VENDOR_ID
DEVICE_NATIVE_VECTOR_WIDTH_*
DEVICE_MAX_CLOCK_FREQUENCY
DEVICE_MIN_DATA_TYPE_ALIGN_SIZE (was removed in OpenCL 1.2)
DEVICE_ERROR_CORRECTION_SUPPORT
DEVICE_PROFILING_TIMER_RESOLUTION
DEVICE_EXTENSIONS (available through getExtensions)
DRIVER_VERSION

Still undecided on these:

DEVICE_GLOBAL_MEM_CACHE_TYPE
DEVICE_GLOBAL_MEM_CACHELINE_SIZE
DEVICE_GLOBAL_MEM_CACHE_SIZE
DEVICE_GLOBAL_MEM_SIZE
DEVICE_EXECUTION_CAPABILITIES
DEVICE_NAME
DEVICE_VENDOR
Comment 9 steven eliuk 2013-08-07 14:03:00 PDT
The translator work has ran into numerous cases where global-memory is checked to make sure the computation would not fail on the device.

One could naturally create a program that kept trying to allocate until it failed, hence reached the allowable size; therefore, we should make DEVICE_GLOBAL_MEM_SIZE visible because it can be inferred.



(In reply to comment #8)
> The following are to be made visible by default:
> 
> DEVICE_MAX_COMPUTE_UNITS (can be deduced by benchmarking)
> DEVICE_MEM_BASE_ADDR_ALIGN (needed for createSubBuffer)
> DEVICE_SINGLE_FP_CONFIG (can be deduced with test kernels)
> DEVICE_COMPILER_AVAILABLE (always returns true, so can be exposed)
> 
> The following are kept not visible:
> 
> DEVICE_VENDOR_ID
> DEVICE_NATIVE_VECTOR_WIDTH_*
> DEVICE_MAX_CLOCK_FREQUENCY
> DEVICE_MIN_DATA_TYPE_ALIGN_SIZE (was removed in OpenCL 1.2)
> DEVICE_ERROR_CORRECTION_SUPPORT
> DEVICE_PROFILING_TIMER_RESOLUTION
> DEVICE_EXTENSIONS (available through getExtensions)
> DRIVER_VERSION
> 
> Still undecided on these:
> 
> DEVICE_GLOBAL_MEM_CACHE_TYPE
> DEVICE_GLOBAL_MEM_CACHELINE_SIZE
> DEVICE_GLOBAL_MEM_CACHE_SIZE
> DEVICE_GLOBAL_MEM_SIZE
> DEVICE_EXECUTION_CAPABILITIES
> DEVICE_NAME
> DEVICE_VENDOR
Comment 10 Tomi Aarnio 2013-08-08 08:45:25 PDT
OK, here's the current status:

The following are to be made visible by default:

DEVICE_MAX_COMPUTE_UNITS (can be deduced by benchmarking)
DEVICE_MEM_BASE_ADDR_ALIGN (needed for createSubBuffer)
DEVICE_GLOBAL_MEM_CACHE_TYPE (can be deduced by benchmarking)
DEVICE_SINGLE_FP_CONFIG (can be deduced with test kernels)
DEVICE_COMPILER_AVAILABLE (always returns true, so can be exposed)
 
The following are kept not visible:

DEVICE_VENDOR_ID
DEVICE_NATIVE_VECTOR_WIDTH_*
DEVICE_MAX_CLOCK_FREQUENCY
DEVICE_MIN_DATA_TYPE_ALIGN_SIZE (was removed in OpenCL 1.2)
DEVICE_ERROR_CORRECTION_SUPPORT
DEVICE_PROFILING_TIMER_RESOLUTION
DEVICE_EXTENSIONS (available through getExtensions)
DRIVER_VERSION

Still undecided on these:

DEVICE_GLOBAL_MEM_CACHELINE_SIZE
DEVICE_GLOBAL_MEM_CACHE_SIZE
DEVICE_EXECUTION_CAPABILITIES
DEVICE_NAME
DEVICE_VENDOR
Comment 11 Tomi Aarnio 2013-08-08 08:47:29 PDT
Please ignore my previous comment, did a copy-paste typo there. Here's the current status:

The following are to be made visible by default:

DEVICE_MAX_COMPUTE_UNITS (can be deduced by benchmarking)
DEVICE_GLOBAL_MEM_SIZE (can be deduced by benchmarking)
DEVICE_MEM_BASE_ADDR_ALIGN (needed for createSubBuffer)
DEVICE_SINGLE_FP_CONFIG (can be deduced with test kernels)
DEVICE_COMPILER_AVAILABLE (always returns true, so can be exposed)
 
The following are kept not visible:

DEVICE_VENDOR_ID
DEVICE_NATIVE_VECTOR_WIDTH_*
DEVICE_MAX_CLOCK_FREQUENCY
DEVICE_MIN_DATA_TYPE_ALIGN_SIZE (was removed in OpenCL 1.2)
DEVICE_ERROR_CORRECTION_SUPPORT
DEVICE_PROFILING_TIMER_RESOLUTION
DEVICE_EXTENSIONS (available through getExtensions)
DRIVER_VERSION

Still undecided on these:

DEVICE_GLOBAL_MEM_CACHELINE_SIZE
DEVICE_GLOBAL_MEM_CACHE_SIZE
DEVICE_GLOBAL_MEM_CACHE_TYPE
DEVICE_EXECUTION_CAPABILITIES
DEVICE_NAME
DEVICE_VENDOR
Comment 12 Tomi Aarnio 2013-08-09 00:52:08 PDT
Mikael Sevenier suggested over email that it would do no harm to expose the DEVICE_GLOBAL_MEM_* queries, i.e. these ones:

  DEVICE_GLOBAL_MEM_CACHELINE_SIZE
  DEVICE_GLOBAL_MEM_CACHE_SIZE
  DEVICE_GLOBAL_MEM_CACHE_TYPE

As you may recall, there are two reasons for hiding platform-specific information: 

  1) Prevent malware from fingerprinting the device.
  2) Discourage developers from writing non-portable code.

Now, I haven't done any research on this, but I have a feeling that these three pieces of information about the device cache do not yield too many unique bits for fingerprinting. CACHE_TYPE is probably always READ_WRITE, and the other two are heavily correlated with other attributes that are already visible or can be inferred by benchmarking (such as CPU vs. GPU, global memory size, constant memory size).

As for code portability, I don't see how anyone would write code that only works with a certain cache size. Optimizing for certain cache sizes, yes, but I don't see any harm in that.

The main argument against exposing these attributes, for me, is that the values seem to be either garbage (on the CPU) or all-zero (on both GPUs) on my 2008 MacBook Pro running OSX 10.7.5. Obviously, having false information is worse than having no information at all. I wonder if that's fixed in later versions?
Comment 13 Sharath Kamath 2013-08-25 23:17:10 PDT
Updated visible device getInfo params also needs to be added to the WebCL interface to be used by device.getInfo(...).
The recently changed parameters are missing in WebCL interface declaration.

Also DEVICE_EXECUTION_CAPABILITIES is made visible in the specification. 
As per the last status its undecided on the visibility of DEVICE_EXECUTION_CAPABILITIES.
Comment 14 Tomi Aarnio 2013-09-12 05:09:22 PDT
Someone remind me again why DEVICE_ERROR_CORRECTION_SUPPORT and DEVICE_PROFILING_TIMER_RESOLUTION are hidden? Do they enable device fingerprinting or promote non-portable coding practices? I don't think so. 

Why hide the profiling timer resolution? What's the point of having profiling support in the API, then hiding the timer resolution?

Moreover, every enum that we decide to hide makes it just a tiny bit harder to port existing OpenCL code to WebCL, particularly by automated means like webcl-emscripten.

In my opinion, there's only one device query enum that really should be removed (DEVICE_MIN_DATA_TYPE_ALIGN_SIZE), and that's only because it was deprecated in OpenCL 1.2.

I can understand the motivation behind hiding stuff like vendor name and id, but I would argue that the decision should be made by each individual implementation, not the spec.
Comment 15 steven eliuk 2013-09-12 07:09:58 PDT
I find the decision on what to hide should be handled by the browser, and restrictions would be better off dictated by specific browser's underlining conventions or normative behavior.

Here is another train of thought, if the WD specifically defines what info is not visible, and a browser decides to make some extra info visible, will it fail certain tests in the conformance suite? The answer is yes... Therefore, one should not really define the restrictions at the specification level and let the browser decide.
Comment 16 Tomi Aarnio 2013-10-02 08:09:42 PDT
(In reply to comment #15)

> I find the decision on what to hide should be handled by the browser, 

I agree. We've already found out the hard way that any restrictions we put in place are going to be more or less arbitrary. Why don't we just expose all the standard OpenCL platform and device query attributes?
Comment 17 steven eliuk 2013-10-08 15:39:53 PDT
I concur, the browser is likely going to override what is exposed...

Are any not in favor of exposing everything, at least at the specification level?

We may want to leave this until the F2F at Samsung next month to get more opinions...
Comment 18 steven eliuk 2013-10-17 15:24:18 PDT
As per the Telco on 10-17-13, there was the suggestion to replace the 'Not Visible' declaration with 'Optionally Visible'. There have been several param-names identified that must be made visible to the programmer to ensure portability, and for this reason, those should be declared visible at the specification level. The other more questionable, and non-essential, can be phrased 'optionally visible'. This means the conformance suite can test for those deemed mandatory. This would preserve a reliable, and normative, WebCL experience for the application developer.

Any arguments for, or against, this approach?
Comment 19 Tomi Aarnio 2013-10-23 06:16:43 PDT
(In reply to comment #18)

> As per the Telco on 10-17-13, there was the suggestion to replace the 'Not
> Visible' declaration with 'Optionally Visible'. 

I like this approach. But that brings us back to square one: how do we decide what goes where? What are the essential properties that are required for writing portable code, or porting existing code from OpenCL? Which ones can be dropped?

I took a stab at this by just changing the "Hidden" attributes to "Optionally Visible" (except for the single deprecated property that I marked as "Removed"). All the Visible attributes I left as such, because they all look pretty important to me, particularly if you consider porting existing OpenCL code using automated tools.

I'm closing this ticket for now; please review the spec and reopen if necessary.
Comment 20 Igor Oliveira 2013-11-05 09:34:45 PST
Discussed again at the Samsung F2F:
1. If the enums are optionally visible the browser vendors does not need to implement them, making these enums not useful.
2. If they are in the core spec and they are optionally visible, the browser vendors needs to know why each one them are optionally visible so they can decide make them visible.

After the points raised above the WG decide to make it an extension so all the points can be clarified
Comment 21 Tomi Aarnio 2013-11-06 05:12:33 PST
(In reply to comment #20)
> After the points raised above the WG decide to make it an extension so all
> the points can be clarified

If "making it an extension" means that we take the same approach as in WebGL (see http://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/), then I have no objections. 

More precisely:

  1. All query params are visible and return "some" information.
  2. The browser may mask information that could identify the user.
  3. The un-masked information is available through an extension.
  4. The extension is only available to privileged content.

For example, querying for DEVICE_VENDOR on a regular web page might return "Mozilla" or "WebKit", but doing the same in a browser add-on would return "NVIDIA" or "Intel".

Are we on the same page?
Comment 22 steven eliuk 2013-11-22 13:51:50 PST
WEBCL_debug_info extension has been drafted,

https://github.com/KhronosGroup/WebCL/tree/master/extensions/WEBCL_debug_info