第一个人说写了一个支持windows平台的patch，用于支持opencl解码，还没试过

这位老兄提了4个建议：

1. 是否有必要建立单独的Cl/目录？似乎应该是外部opencl toolkit提供的

2. 在新的c文件中包含license声明

3. libjpeg-turbo支持动态地指定底层算法，希望opencl也能采用这种方式实现

4. opencl的相关检测应该不暴露出来

这哥接着回复：我加单独的opencl目录是为了那些没有安装opencl sdk的哥们能够独立使用我们的版本而不需要单独再安装

一个新的哥们提了个建议，说用流水线的方式实现huffman以及SIMD处理。

这位老兄说了新的理解，看出 Huffman不太好并行化，话说offload是个什么鬼

这里关于版权license问题的讨论好专业，留待参考

这里提了这样几个问题：

b) pipeline特性是怎样开启关闭的

c) 在结构中新加的字段打破了ABI兼容

d) 使用者应该对opencl的增加是不感知的，也就是说，不应该有单独的针对opencl的api与其它api相独立

e) 问他是不是每一次都分配了供4096*4096的图处理的内存区域？这样很浪费而且容易出错

f) jdcoefct.c的185行有segfault错误

这里第5点提到他们预分配一块大内存的好处，一个是只用分配一次，一个是DMA操作和kernel running在同一块内存区域比每一次都重新分配的话要快

哈哈，这位哥仍然纠结于静态分配16MB内存中

两位的钻研精神我真是给跪了

这里的上下文是提交的哥们把gating测试代码给改了，引得项目维护人一阵吐槽......

这里这哥一阵好解释

很有趣的一个sourceforge论坛对话，主题关于libjpegturbo的opencl patch