Ben Ashbaugh comments

Results 432 comments of


                                            Ben Ashbaugh

Potential OpenCL Spec Error in 3.2.4

Yes, good catch! I'll fix this. I'll also try to remove some of the duplicated text between this paragraph and the preceding paragraph about work-group functions.

CL_INVALID_IMAGE_FORMAT_DESCRIPTOR error condition

I looked at this a bit more after the discussion in the September 2nd teleconference and the problem actually goes back much further than cl_ext_image_from_buffer: If I go all the...

Memory Consistency for Memory Objects Created from SVM Allocations

It's probably most intuitive to think of the "memory object" in the descriptions above as being a buffer memory object, but for added "fun", what if it is an image...

Memory Consistency for Memory Objects Created from SVM Allocations

We introduced this issue in the May 6th memory subgroup but we did not have any time to discuss in detail. The key difference between the two scenarios is that...

Memory Consistency for Memory Objects Created from SVM Allocations

I started writing some tests to see whether implementations have address equivalence when a buffer memory object is created from an SVM allocation. Let's discuss next steps in our meeting...

Fix profiling_timebase error, the global work size shouldn't be NULL,…

See https://github.com/KhronosGroup/OpenCL-CTS/pull/2241

Fix profiling_timebase error, the global work size shouldn't be NULL,…

Hi! This PR hasn't been merged because a `NULL` global work size is valid. We recently merged a change to the OpenCL specification to clarify this because the requirement was...

Clarify behavior of fmin(+0,-0) and fmax(+0, -0) in spec

There was a CTS PR/discussion recently about NaNs and fmin/fmax also. Not completely relevant, since this issue is about +0/-0, but linking for completeness: https://github.com/KhronosGroup/OpenCL-CTS/pull/2285 Do you have a specific...

Allocating local mem in device functions is not explictly forbidden by the SPIR-V OpenCL Env

The easiest thing to do here would be to add text similar to that in the OpenCL C spec, something like: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#_usage_for_declaration_scopes_and_variable_types > Variables declared in the outermost compound statement...

Allocating local mem in device functions is not explictly forbidden by the SPIR-V OpenCL Env

Actually, maybe we don't need to do anything. The SPIR-V spec already says: https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_logical_layout_of_a_module >All [OpVariable](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpVariable) instructions in a function must have a [Storage Class](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#Storage_Class) of Function. This means that...