[Development] Future of QtOpenCL
qt at leemes.de
Sat Jun 29 22:18:04 CEST 2013
> 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
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.
> 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!
> 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  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?
> 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?
> Many thanks,
More information about the Development