[Development] Future of QtOpenCL

[Sebastian Lehmann]

Hi Máté,

> Also, geting QtOpenCL to work would require reimplementing cl.hpp [...]
> I fear that the quality of portability that Qt requires would not   
> allow us to use those headers, given the rate they change.

I also think that we shouldn't depend on cl.hpp, only on cl.h. AFAIK,  
the old QtOpenCL implementation only uses cl.h.

> I too think that having a Qt-ish interface would be beneficial, but   
> only if all entities are QObjects, able to operate on their own (in   
> a seperate thread if one wishes). That could greatly facilitate many  
>  things.

I'm not yet sure, but it sounds good for most classes. But I think we  
should allow copying QOpenCLBuffer / Vector classes for convenience.  
Not sure yet, as I said. But not many classes of the old QtOpenCL  
derive from QObject (if any?).

> Having generic parallel algorithms is a good thought, however   
> implementing it in a performance-portable manner is no small feat. I  
>  consider myself to be a black-belt OpenCL programmer (having worked  
>  with OpenCL since it?s first beta releases with AMD Stream SDK),  
> but  even I would think twice about implementing STL-like algorithms  
> in  OpenCL, and claim them to be worthwhile using for someone who  
> know  practically nothing about things under the hood. (Bolt and  
> stuff  like that aim just this, and I wouldn?t claim I could do  
> nearly as  good of a job as the OpenCL vendor implementors themselves)

Yes, I see your point. I also think that implementing generic CL algos  
is very challenging. I thought of starting with basic algorithms like  
transform and reduction. In my current project, I implemented them in  
a very generic way: they can operate on any type and with any  
expression, both decided during runtime using strings (as they are  
compiled into the kernel). I think of something like QOpenCLType and  
QOpenCLFunctor which can then be used in the CL algorithm library  
analogous to template types and functors in STL. A 1:1 mapping is too  
hard, though (if even possible).

But we shouldn't spend too much thoughts on this yet, as this makes  
only sense if the rest works.

> I have thought about reviving the project myself, but bounced off   
> the burden of contributing rules, and means. (gerrit, git and the   
> likes, although I do use git myself with collegues)

This would be my very first contribution to Qt. This is why I need  
others, as developing a new Qt module is not something I think I'm  
capable of without any help.

> Anyhow, through the summer I would be happy to help designing the   
> interfae and commenting on your work, but I fear I cannot promise   
> anything more than that (actual code submission).

We should start with a proper design anyhow, which I guess will take a  
couple of months.

> As a sidenote, I think QOpenCL... class names would be a lot better,  
>  having QOpenGL... taking over QGL classes.

+1

> The biggest advantage of implementing QOpenCL would be if it were to  
>  interoperate with the existing QOpenGL classes, and that is where   
> the nasty stuff begin. I have created several interop applications,   
> I am roughly familiar with OpenGL (able to write simple shaders   
> myself, know a few advanced features) and designing the interop part  
>  is not easy either.

I think we should split the interop in two "layers": First, make it  
possible to use the CL interop functionalities with the raw GL types.  
For example: to create a QOpenCLBuffer from a GLint, not from a  
QOpenGLBuffer. Then, we can add simple convenience functions which use  
QOpenGLBuffer::bufferId instead. I already worked with CL/GL interop,  
but I might have too little experience to see difficulties beyond  
this. Maybe we need more input on this.

By the way, the old QtOpenCL was split into two modules: QtOpenCL +  
QtOpenCLGL. We should do the same. And *if* we decide to implement  
algos, this should be in a third module.

I'm already looking forward on making progress with CL in Qt!

Happy coding,

Sebastian


>
>
> Feladó: Laszlo Papp
> Elküldve: ?szombat?, ?2013?. ?június? ?29?. ?19?:?40
> Címzett: Sebastian Lehmann
> Másolat: development at qt-project.org
>
>
> On Sat, Jun 29, 2013 at 8:00 PM, Sebastian Lehmann <qt at leemes.de> wrote:
>
>
>
> Hello Qt developers,
>
> I'm sadly noting that the QtOpenCL project [1] is dead since end 2010,
> yet it's still
> usable. I want to bring this module back to life. Currently, the
> module has a couple of
> issues such as const-correctness and missing support for Qt5.
>
> I see two options with that: Either rewriting the whole module with a
> new design, or
> improving the existing code base.
>
> Also, I'd love to have some basic, generic and reusable algorithms
> implemented in OpenCL
> and available with an interface similar to QtConcurrent. This could be
> in a separate
> module. I have some nice ideas for the design of this.
>
> Some people say that there's no big advantage in having a QtOpenCL
> module, as everything
> can also be done with CL library function calls.
>
>
>
>
> It is good to have a choice, at least!
>
>
>
> But both the
> advantage of RAII as well
> as having a Qt'ish interface are a huge help when writing applications
> with a lot of
> GPGPU computations, as the raw CL functions are way too painful to
> write (and read).
>
> How's your opinion about bringing QtOpenCL back to life (especially in
> Qt5)? Any concrete
> ideas or suggestions?
>
>
>
>
>
> +1
>
>
>
>
> Disclaimer: I am not a maintainer, but I was also thinking of   
> contributing 1-2 patches in that area. There were always other toys   
> to play with though. ;-)
>
>
>
>
> I am sure, Sean for instance will support such a playground project   
> as a (Qt3D) maintainer.
>
>
>
> Anyone out there who wants to help? How is the typical "workflow" for
> new modules in Qt5?
>
>
>
>
>
> http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt
>
>
>
>
>
> Many thanks,
>
> Laszlo