[Development] Future of QtOpenCL

Nagy-Egri Máté Ferenc nagymatef at freemail.hu
Sun Jun 30 20:25:24 CEST 2013

The way I see it, is that Qt would definately benefit from stable, Qt interface to a cross-platform compute API. There are many things under the hood, that could be acomplished through it, if it is stable enough.

The very long term plan of integrating it into QtConcurrent is practically what Microsoft is doing with their concurrent:: namespace and C++AMP. Problem is, that it is not implemented at all outside the MS ecosystem, while OpenCL can be called widespread enough (although there are some concerns with the NV implementation, but in the long run, they will have to stand in the long line of stable implementors).

About community power for actual code writing, that is exactly why I said that I am very much interested, I might even be able to submit code (given the fact how much I am fascinated by the usability of Qt as a somewhat newbie to it), but I am a PhD physicist with a full-time administrator job, so my spare time is very limited. My contribution will most likely consist of code comments, and API design suggestions. Since I have a somewhat larger project (as part of my PhD thesis) built atop Qt, and I very much fancy readable/maintainable code, I would very much like having a cleaner, globally Qt-like infrastructure under the hood.

I understand the concerns, but believe that 2-3-4 people could put the module together in 3-4-5 months time. (Educated guess)

I am interested too how Qt module interfaces are designed. How much do the tools and strategies vary between module to module?

Feladó: Sebastian Lehmann
Elküldve: ‎vasárnap‎, ‎2013‎. ‎június‎ ‎30‎. ‎14‎:‎45
Címzett: development at qt-project.org

Quoting Uwe Rathmann <Uwe.Rathmann at tigertal.de>:

> On Sat, 29 Jun 2013 22:18:04 +0200, Sebastian Lehmann wrote:
>>> 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)
> Before starting with this project you should ask yourself if it is better
> to do develop it inside or outside of Qt - or in other words: what is the
> advantage of being a Qt module compared to addons like Qxt or Qwt ?

I see the strong developer community behind Qt as a huge advantage.
QtOpenCL currently has to be considered dead. Of course, being a Qt
module doesn't mean every developer of Qt helps developing this
module. But things like release plans of Qt enforce that the module
gets stable some time. I see the same advantage currently at Qt3D. It
wasn't a Qt module until now AFAIK, but now it is going to be, so now
we have "clear plans" to release it with Qt 5.2. Maybe I'm too new to
Qt development to see the advantages / disadvantages clearly. Thanks
for discussing alternatives.

> The very first issue for an existing project is about checking its
> license. At the time when I was asking myself the same question for my
> project I would have had to change the license - giving Nokia control.
> Beside the fact, that I didn't want this: any change of the license
> requires permission of all contributors to the existing code - hard to
> collect for a project with some history ( in my case 16 years ). Hope
> this has changed nowadays.

The old QtOpenCL seems to be LGPL, even more permissive? (LGPL_EXCEPTION.txt)

> But even then you should be aware, that being a Qt module means
> administrative overhead and you should have an idea what real advantages
> to expect. Being a Qt module only because of being one doesn't make the
> project more useful or attractive to other users/developers.

The old QtOpenCL was a labs project, but it has been written with
becoming an official Qt module some day in mind. We could first
develop a new QtOpenCL module in the same way before making it an
official Qt module.


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

More information about the Development mailing list