[Development] Future of QtOpenCL

Nagy-Egri Máté Ferenc nagymatef at freemail.hu
Sat Jun 29 20:50:07 CEST 2013


I myself would be interested also. RIght now I’m implementing a giant project using the cl.hpp headers to make use of RAII.

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.

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)

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)

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).

Also, geting QtOpenCL to work would require reimplementing cl.hpp, as those headers change fairly quickly (every 6 months, when the AMD APPSDK is released, as the C++ headers are not truly standard, but a sideproject of AMD that Khronos publishes on their webpage), so I fear that the quality of portability that Qt requires would not allow us to use those headers, given the rate they change.

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.

If you need any help or theoretical input, I would be glad to help.



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?


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,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130629/4f490eb6/attachment.html>
-------------- next part --------------
Development mailing list
Development at qt-project.org

More information about the Development mailing list