There seems to be some misunderstanding here that is worth clearing up. > On Jun 23, 2015, at 12:16 AM, James Bush <theokn...@icloud.com> wrote: > > Metal and OpenCL are micro-architecture programming languages; one cannot be > faster unless one provides more access to the hardware than the other. > > A perfect example is provided by Quartz Composer, in that it uses a subset of > OpenGL (OpenGL ES)— not the full language. As a consequence, it is the > slowest fastest markup language that one could use for GPU programming. But, > for every function it shares with its parent, and and any similar functions > it shares with other languages using the same hardware, the speed is the same.
Quartz Composer is currently built upon OpenGL 2.0. OpenGL ES is a subset of OpenGL 3.0. To transition to 3.0, QC would probably gain some improvements, but it would also break quite a few compositions. I cannot say if or when QC might adopt GL 3.0 and the Core Profile, but the request is known. Any additional bugs would help management understand the demand, but just this once I'll recommend you don't spend too much time on such a bug since it will be quickly duped to the known request. > > The distinction between Metal and OpenCL will never amount to anything more > significant and language design specifications. Metal is for game > programming; OpenCL is a generic, all-encompassing open-source language. You > can achieve the same thing with both, but it would take a lot of kludging > with Metal to make it do anything but what it was designed for—games. It is > Apple's answer to a similarly purposed language by Google, which is extremely > popular among Android developers. The distinction between games and not-games seems off track here. As seen at WWDC, Adobe announced it is adopting Metal in their suite of apps—not games. An app like Quartz Composer which is not designed for making games would probably benefit from adopting Metal. OpenCL is still used in games and non-game applications. I'm afraid I don't have enough experience with either OpenCL or Metal to know where they overlap but my understanding is that Metal is less about leveraging the GPU for parallel computation, and more about drawing efficiently. > > So, as you can see, it's a left-field question to think of Quartz Composer > has a part in any of that. It's a graphics tool that belongs to a package of > many other such tools, and as useful as a pocket calculator. Small, fast, > convenient, essential—but you put it away once you've made your calculations, > right before you start building the real thing. > > I don't think it's misguided to ask how much QC and Metal can work together, and at this point the answer is very little. You'd have to avoid the drawing portions of the QC pipeline altogether. QC can pass IOSurfaceRefs to Core Image and other subsystems through CVPixelBuffer image types (https://developer.apple.com/library/ios/qa/qa1781/_index.html <https://developer.apple.com/library/ios/qa/qa1781/_index.html>) so it may be possible to leverage Metal somehow through custom plugins, but you would not be able to create a Metal context for use in QCView, QCRender, etc. I am tentatively going to say this would not be the recommended way to develop Metal apps, since the overhead of QC would probably eliminate any benefits of Metal. Other folks may have a more definitive answer.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
