WRT to broken plugins moving forward, should that happen, I for one would gladly take re-tooling my plugin suite knowing that QC has a modern future. I expect others might feel the same - presuming they have stuck with it and are as stubborn as I and haven’t already re-tooled their entire engine.
QC already indicates unsafe patches, why not a runtime version where "QC next" would have a compatibility mode, or hell, you could even do ‘context sharing' between GL 4/3 and 2 via IOSurfaceRef backed QCImages as you state - since you cannot do real context sharing. This is a distraction however because technical solutions require the will and resources to implement. Regardless of what the rendering back end is, knowing QC has active development, support structure and is on the radar somewhere at Apple would be very helpful and reassuring. Without sounding overly dramatic, it feels a bit like QC is on life support, and someone, somewhere, at any moment, could make a tough call to turn the machines off. Its hard to invest time and energy when the doctors don’t tell you how the patient is doing. Its also a bad negative feedback loop in terms of community, usage, bug reports and ensuring the doctors know the patient is ‘worth’ saving. Core Image, Core Animation, SceneKit and other modern API’s developed by Apple all are being discussed, and are moving towards modern APIs much more openly. SceneKit specifically has similar issues as QC wrt to transitioning API back ends. If you’ve written custom SceneKit code to render SCNNodes with your own OpenGL calls (like, ahem, I might have), you cannot easily benefit from the transition to Metal. And yet movement is happening. Regardless, QC solves a niche that NO OTHER existing node based tool does that I’ve seen, on any platform - Its embeddable within a larger context, can be procedurally driven, and is highly extensible. That is worth saving. 2¢ ++ p.s. Who do I have to get drunk and bribe in upper management to get that ball rolling? I’m half joking. > On Jun 25, 2015, at 4:12 PM, Troy Koelling <tkoell...@apple.com> wrote: > > 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 >> <mailto: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/doktorp%40mac.com > > This email sent to dokt...@mac.com
_______________________________________________ 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
