Khronos public bugtracker – Bug 792
Integration of WebCL prototype in Mozilla Firefox engine
Last modified: 2013-11-04 13:36:33 PST
To track the effort to integrate Nokia's WebCL prototype into Firefox
Adding the previous emails for background;
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Jeff Gilbert
Sent: Thursday, January 31, 2013 3:26 PM
To: Fabien Cellier
Cc: firstname.lastname@example.org; Tomi Aarnio
Subject: [WebCL] Re: MQ for firefox?
WebCL code is probably best placed near the WebGL code. Since WebCL isn't Canvas-based like WebGL, it should probably go in /content/webcl.
----- Original Message -----
From: "Fabien Cellier" <email@example.com>
To: "Tomi Aarnio" <firstname.lastname@example.org>, "Jeff Gilbert" <email@example.com>
Sent: Thursday, January 31, 2013 3:15:44 PM
Subject: MQ for firefox?
It is hard to integrate a big code directly in firefox, it is easier to submit many small patches. So the idea is to have 2 repos,one in the project repo and the other one is the mq (mq is only patches that you can easily add/remove : https://developer.mozilla.org/en-US/docs/Mercurial_Queues )
I know it's a little redundant but it will be easier for us to ask webCL integration and it will help firefox reviewers.
I think your code should be in /dom(/src) or /content (and if we add it to window, it will be a little easier to integrate it in webworker). Futhermore, there was some changes in the trunk :
public typedArray API have changed (no context anymore) JS_*RootScope are deprecated ( no more "root as you go", so we should think if there is other changes with the new GC)
We’re now able to build Firefox with WebCL patched in as an XPCOM component under browser/components/webcl.
This is the easiest and most “shallow” kind of integration – we can generate a patch automatically from the WebCL extension codebase, but on the flipside, we can’t get WebGL integration.
The biggest difficulty for us has been that the mozilla-central codebase appears to be broken quite often – it fails to build, even without WebCL. Maybe we’re missing something? Is there some way to know which changesets are in working condition? Is it more likely for a build to fail if we have disabled things like Ogg, Dash, WebM, crashreporter and accessibility in mozconfig?
Anyhow, we’d be ready to push our code to the projects/webcl repo. Fabien, are you OK if we wipe out your old code and replace it with the new, or shall we set up a separate branch?
I’ve just pushed our WebCL codebase to http://hg.mozilla.org/projects/webcl, integrated with mozilla-central trunk, and confirmed that it builds on at least Scientific Linux 6.0 (64-bit).
There was a minor complication, though – I had to add “CLOSED TREE” to the commit message to avoid getting rejected by something called ‘treestatus’. Any advice on how to resolve that in a nicer way?
Now, how should I proceed to get nightly/weekly builds running on Mozilla build servers?
Tomi mentioned that "it was pointed out before, there’s no WebCL code in mozilla-central. It’s in the Mozilla “projects” repo".