Hi Chris Thanks so much for the prompt reply .
Ive noticed some interesting things in terms of chaining multiple ‘QCImage’ backing causing issues. My chaining terminology refers to : rendering a QCRenderer or providing an appropriate image type (CIImage CVOpenGLTextureRef, etc), rendering said renderer at time, getting the valueForOutputKey:key ofType:@“QCImage” and setting that to the valueForInputKey: of the next QCRenderer in the chain. all renderers use the same GL context, save for one, which uses a shared GL context / and an attached drawable to view the results. -- if I chain a series of QCCompositions/Renderers which use pure CIImage filters, as provided by the OS, and no other processing I have no problem. if I chain a series of QCCompositions/Renderers which use plugins which vend textures as QCOutputImageProviders in series, I have no problem. If I chain a mix of the above, I have a problem. if I load a *single* QC Composition/Renderer which has a custom plugin, and within that composition that plugin is fed, or feeds, a custom CIKernel, I have the problem. This is on MacBook Pro (Retina, 15-inch, Mid 2014) NVIDIA GeForce GT 750M 2048 MB 10.11.2 (15C50) About to use GFXCardStatus to see if the pixel format swizzling as you pointed out is a GPU or something else issue. Thanks again for the quick reply. Right now my reproduction case is admittedly complex - I’m going to see if I cant boil it down some more. > On Feb 1, 2016, at 1:29 PM, Chris Wright <christopher_wri...@apple.com> wrote: > > Looks like that _might_ be due to a CoreImage change (note a few frames down, > it’s doing a ABGR8 -> ARGB8 conversion, which possibly implies a request for > a pixel format that isn’t what the GPU’s currently using). I only say CI > because QC’s use of pixel formats hasn’t meaningfully changed in quite a > while, so this would be a surprising behavior change for QC. > > Do you happen to have configuration info, or if this behaves similarly on > other families of GPUs? It looks like you’re on some family of GeForce > (nvidia), so Intel or AMD behavior might be helpful if it’s a quirk below QC. > > Can you please file a radar for this? It may well affect several other > things negatively. > > >> On Feb 1, 2016, at 9:38 AM, Anton Marini <dokt...@mac.com> wrote: >> >> Hi >> >> My application uses the QCRenderer API to input and output images in the >> opaque QCImage format and send them through a chain of published input and >> output images in QCCompositions/Renderers I control. >> >> Ive noticed in 10.11, performance seems worse. Looking into it, I’m noticing >> that *certain* configurations of Core Image filters and custom QC Plugins / >> output images vended as QCImages cause read back to occur on the CPU. >> >> Ive tried to account for various different causes - like pixel format >> issues, color space issues, etc, but I cannot get rid of the CPU read back, >> which I am 99.999% positive didn’t happen in older Quartz Composer >> framework/API versions as older hardware got better frame rates - likely >> keeping things on the GPU where they belong™. >> >> Has anyone else seen regressions in performance with QC? >> >> Specifically, I am seeing stacks like the following (see attached image). >> >> https://www.dropbox.com/s/s7sqn56gdcogxsj/PastedGraphic-1.png?dl=0 >> >> Any hints as to why there might be rendering path changes in QC or Core >> Image? >> >> Thank you. > > -- > Chris Wright > christopher_wri...@apple.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
