Ben Ashbaugh

> So overall I'm a concerned that reality just doesn't match the spec here and that OpenCL runtimes already work around "broken" applications by implicitly flushing in some cases where...

I was thinking about this over the weekend but I didn't have any epiphanies. It's a tricky problem - as long we have implementation-defined flushing behavior there are going to...

> I still think that callabcks should be called if the event is past it's status. I agree. Without this behavior it seems like you'd either be in a race...

I think this is an interesting question. While I agree that the OpenCL API queries and the OpenCL C feature macros will usually match on most implementations (and certainly will...

I did an initial review of this extension, mostly comparing against [cl_intel_packed_yuv](https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_packed_yuv.html) and [cl_intel_planar_yuv](https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_planar_yuv.html). In short, I don't think we'd be able to support this extension as-written. Here are a...

We can create separate issues for parts of this discussion if it would be easier to track them that way. Regarding swizzles and mapping to vector components: > 1. Presumably,...

Thanks for making the task list. I think that will be good enough for now. I think I have a solution to the YUV order from the read_image built-ins. I...

Odd, I'm surprised I didn't notice this. I was trying to follow "best practices" as described here: https://github.com/asciidoctor/asciidoctor-pdf/issues/1397 Specifically: > I strongly recommend against defining the footnote macro in an...

I've found a couple of possible ways to "fix" this and I would like input to decide what we want to do. 1. We could assign footnotes an ID every...

Discussed in the October 4th teleconference: - Do we need to define and document any interactions with YUV extensions (#722)? - Are there any interactions to consider when creating an...