April 2013 - Pro-apps-dev - lists.apple.com

Re: GPU FxPlugs - what happens if the image is too big?
by Darrin Cardani 30 Apr '13

30 Apr '13

On Apr 30, 2013, at 10:30 AM, Paul Miller <paul(a)fxtech.com> wrote: > On 4/30/2013 12:07 PM, Darrin Cardani wrote: >> >> On Apr 30, 2013, at 10:01 AM, Paul Miller <paul(a)fxtech.com> wrote: >> >>> On 4/30/2013 11:56 AM, Darrin Cardani wrote: >>>> >>>> On Apr 30, 2013, at 7:44 AM, Paul Miller <stelefx(a)gmail.com> wrote: >>>> >>>>> Is it possible to fall back automatically to the CPU path if something "goes wrong" when attempting to process the filter in GPU mode? >>>>> >>>>> I tried returning NO from the renderOutput function, but it just put up an alarming screen saying it couldn't render, even though I had CPU mode enabled as well (I expected it to call renderOutput again in CPU mode). >>>> >>>> If you can detect that your GPU render failed (and you are then returning "NO" from your -renderOutput: method), you can simply try again yourself instead of returning "NO", can't you? (That is, you can download the input from the card, process it, and upload it back to the card when done.) We assume that you've exhausted your available options if you return NO, hence the red screen saying that we couldn't process. >>> >>> I suppose so. I figured FCP would just do this for me in the case of the GPU path failing. This implies there is not a good reason to set YES for both GPU and CPU. >> >> Well, for what it's worth, there are paths we take that are CPU-preferred (such as generating thumbnails in FCPX, iirc). In those cases, it can be a win to have a CPU path, as the extra work of upload/downloading to/from the card can slow things down. But we will handle it if you only support one or the other. > > Fair enough. > > Is there a case where either host will attempt to tile the filter? I'm seeing a bizarre case in Motion where the bottom-left quadrant of the image looks different than the rest of the image. We never ask an FxPlug to render a tile because the API doesn't currently have support for such functionality. Internally, the apps' rendering does tile. So it could be that something is causing a problem with our internal tiling as we attempt to create one large texture to give to your plug-in, or something like that. It's probably worth a Radar with an example project attached. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: GPU FxPlugs - what happens if the image is too big?
by Paul Miller 30 Apr '13

30 Apr '13

On 4/30/2013 12:07 PM, Darrin Cardani wrote: On Apr 30, 2013, at 10:01 AM, Paul Miller <paul(a)fxtech.com> wrote: On 4/30/2013 11:56 AM, Darrin Cardani wrote: On Apr 30, 2013, at 7:44 AM, Paul Miller <stelefx(a)gmail.com> wrote: Is it possible to fall back automatically to the CPU path if something "goes wrong" when attempting to process the filter in GPU mode? I tried returning NO from the renderOutput function, but it just put up an alarming screen saying it couldn't render, even though I had CPU mode enabled as well (I expected it to call renderOutput again in CPU mode). If you can detect that your GPU render failed (and you are then returning "NO" from your -renderOutput: method), you can simply try again yourself instead of returning "NO", can't you? (That is, you can download the input from the card, process it, and upload it back to the card when done.) We assume that you've exhausted your available options if you return NO, hence the red screen saying that we couldn't process. I suppose so. I figured FCP would just do this for me in the case of the GPU path failing. This implies there is not a good reason to set YES for both GPU and CPU. Well, for what it's worth, there are paths we take that are CPU-preferred (such as generating thumbnails in FCPX, iirc). In those cases, it can be a win to have a CPU path, as the extra work of upload/downloading to/from the card can slow things down. But we will handle it if you only support one or the other. Fair enough. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Is there a case where either host will attempt to tile the filter? I'm seeing a bizarre case in Motion where the bottom-left quadrant of the image looks different than the rest of the image.

1 0

Re: GPU FxPlugs - what happens if the image is too big?
by Darrin Cardani 30 Apr '13

30 Apr '13

On Apr 30, 2013, at 10:01 AM, Paul Miller <paul(a)fxtech.com> wrote: > On 4/30/2013 11:56 AM, Darrin Cardani wrote: >> >> On Apr 30, 2013, at 7:44 AM, Paul Miller <stelefx(a)gmail.com> wrote: >> >>> Is it possible to fall back automatically to the CPU path if something "goes wrong" when attempting to process the filter in GPU mode? >>> >>> I tried returning NO from the renderOutput function, but it just put up an alarming screen saying it couldn't render, even though I had CPU mode enabled as well (I expected it to call renderOutput again in CPU mode). >> >> If you can detect that your GPU render failed (and you are then returning "NO" from your -renderOutput: method), you can simply try again yourself instead of returning "NO", can't you? (That is, you can download the input from the card, process it, and upload it back to the card when done.) We assume that you've exhausted your available options if you return NO, hence the red screen saying that we couldn't process. > > I suppose so. I figured FCP would just do this for me in the case of the GPU path failing. This implies there is not a good reason to set YES for both GPU and CPU. Well, for what it's worth, there are paths we take that are CPU-preferred (such as generating thumbnails in FCPX, iirc). In those cases, it can be a win to have a CPU path, as the extra work of upload/downloading to/from the card can slow things down. But we will handle it if you only support one or the other. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: GPU FxPlugs - what happens if the image is too big?
by Paul Miller 30 Apr '13

30 Apr '13

On 4/30/2013 11:56 AM, Darrin Cardani wrote: On Apr 30, 2013, at 7:44 AM, Paul Miller <stelefx(a)gmail.com> wrote: Is it possible to fall back automatically to the CPU path if something "goes wrong" when attempting to process the filter in GPU mode? I tried returning NO from the renderOutput function, but it just put up an alarming screen saying it couldn't render, even though I had CPU mode enabled as well (I expected it to call renderOutput again in CPU mode). If you can detect that your GPU render failed (and you are then returning "NO" from your -renderOutput: method), you can simply try again yourself instead of returning "NO", can't you? (That is, you can download the input from the card, process it, and upload it back to the card when done.) We assume that you've exhausted your available options if you return NO, hence the red screen saying that we couldn't process. Also, what happens if I try to edit 4K footage on a machine with a 256MB graphics card? Does FCP just skip the GPU path in that case, or does it try to tile somehow, or does it just punt and tell you to upgrade? (the last is my personal preference - attempting to support 5 year old hardware is not terribly fun). I believe we crop the image to the max allowed by the user's card. I'm not sure why the decision was made to crop instead of scale, as that decision was made many many years ago. One option you have is to check the user's config, and if it will likely cause this type of problem, return "NO" for "canRenderHardware" in your -frameSetup method. That way you seamlessly switch from GPU to CPU when appropriate and the user gets their render. Fair enough. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com I suppose so. I figured FCP would just do this for me in the case of the GPU path failing. This implies there is not a good reason to set YES for both GPU and CPU.

1 0

Re: GPU FxPlugs - what happens if the image is too big?
by Darrin Cardani 30 Apr '13

30 Apr '13

On Apr 30, 2013, at 7:44 AM, Paul Miller <stelefx(a)gmail.com> wrote: > Is it possible to fall back automatically to the CPU path if something "goes wrong" when attempting to process the filter in GPU mode? > > I tried returning NO from the renderOutput function, but it just put up an alarming screen saying it couldn't render, even though I had CPU mode enabled as well (I expected it to call renderOutput again in CPU mode). If you can detect that your GPU render failed (and you are then returning "NO" from your -renderOutput: method), you can simply try again yourself instead of returning "NO", can't you? (That is, you can download the input from the card, process it, and upload it back to the card when done.) We assume that you've exhausted your available options if you return NO, hence the red screen saying that we couldn't process. > Also, what happens if I try to edit 4K footage on a machine with a 256MB graphics card? Does FCP just skip the GPU path in that case, or does it try to tile somehow, or does it just punt and tell you to upgrade? (the last is my personal preference - attempting to support 5 year old hardware is not terribly fun). I believe we crop the image to the max allowed by the user's card. I'm not sure why the decision was made to crop instead of scale, as that decision was made many many years ago. One option you have is to check the user's config, and if it will likely cause this type of problem, return "NO" for "canRenderHardware" in your -frameSetup method. That way you seamlessly switch from GPU to CPU when appropriate and the user gets their render. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

GPU FxPlugs - what happens if the image is too big?
by Paul Miller 30 Apr '13

30 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Is it possible to fall back automatically to the CPU path if something "goes wrong" when attempting to process the filter in GPU mode? I tried returning NO from the renderOutput function, but it just put up an alarming screen saying it couldn't render, even though I had CPU mode enabled as well (I expected it to call renderOutput again in CPU mode). Also, what happens if I try to edit 4K footage on a machine with a 256MB graphics card? Does FCP just skip the GPU path in that case, or does it try to tile somehow, or does it just punt and tell you to upgrade? (the last is my personal preference - attempting to support 5 year old hardware is not terribly fun).

1 0

Re: numerous kernel panics when using OpenCL inside FCPX
by Peter Litwinowicz 26 Apr '13

26 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: numerous kernel panics when using OpenCL inside FCPX
by Paul Miller 26 Apr '13

26 Apr '13

On 4/26/2013 3:05 PM, Darrin Cardani wrote: On Apr 26, 2013, at 12:56 PM, Paul Miller <paul(a)fxtech.com> wrote: On 4/26/2013 1:47 PM, Garrick Meeker wrote: Some drivers do have bugs. The AMD driver in 10.6, in particular, may not be worth supporting. It doesn't support OpenCL images (requiring buffers only) and while we did work around that, we found the OpenCL/OpenGL interop so buggy that we disabled FxPlug hardware rendering for these cards/OS (instead transferring from host memory to the card). AMD 6xxx cards in 10.7 had issues (something I found with local memory) but an update seemed to fix that. FOUND IT. In some cases (in this case, D1) the input and output bitmaps are different sizes. The input image was one line taller than the output image. Since I assumed they were the same size, I was doing all the processing at the input size, and when I tried to read it back to the output image, it barfed. Funny, I had solved this problem before, but as this is all new clean code, I didn't incorporate the fix. Need to keep track of all of these little gotchas somewhere. Paul, Glad to hear it's working for you! It sounds like we should be giving you an input and output buffer of the same size in this case. If you want to file a bug with a simple repro case, I'll take a look at it. I seem to recall we've run into this sort of problem before, but I had thought we fixed it. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Bug #13751398 filed. This one has been around awhile. Funny, I never would have run into it (twice) if I'd just grabbed the output FxBitmap size. Or just asserted() that they were the same size!

1 0

Re: numerous kernel panics when using OpenCL inside FCPX
by Darrin Cardani 26 Apr '13

26 Apr '13

On Apr 26, 2013, at 12:56 PM, Paul Miller <paul(a)fxtech.com> wrote: > On 4/26/2013 1:47 PM, Garrick Meeker wrote: >> Some drivers do have bugs. The AMD driver in 10.6, in particular, may not be worth supporting. It doesn't support OpenCL images (requiring buffers only) and while we did work around that, we found the OpenCL/OpenGL interop so buggy that we disabled FxPlug hardware rendering for these cards/OS (instead transferring from host memory to the card). AMD 6xxx cards in 10.7 had issues (something I found with local memory) but an update seemed to fix that. > > FOUND IT. > > In some cases (in this case, D1) the input and output bitmaps are different sizes. The input image was one line taller than the output image. > > Since I assumed they were the same size, I was doing all the processing at the input size, and when I tried to read it back to the output image, it barfed. > > Funny, I had solved this problem before, but as this is all new clean code, I didn't incorporate the fix. Need to keep track of all of these little gotchas somewhere. Paul, Glad to hear it's working for you! It sounds like we should be giving you an input and output buffer of the same size in this case. If you want to file a bug with a simple repro case, I'll take a look at it. I seem to recall we've run into this sort of problem before, but I had thought we fixed it. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: numerous kernel panics when using OpenCL inside FCPX
by Paul Miller 26 Apr '13

26 Apr '13

On 4/26/2013 1:47 PM, Garrick Meeker wrote: Some drivers do have bugs. The AMD driver in 10.6, in particular, may not be worth supporting. It doesn't support OpenCL images (requiring buffers only) and while we did work around that, we found the OpenCL/OpenGL interop so buggy that we disabled FxPlug hardware rendering for these cards/OS (instead transferring from host memory to the card). AMD 6xxx cards in 10.7 had issues (something I found with local memory) but an update seemed to fix that. FOUND IT. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com In some cases (in this case, D1) the input and output bitmaps are different sizes. The input image was one line taller than the output image. Since I assumed they were the same size, I was doing all the processing at the input size, and when I tried to read it back to the output image, it barfed. Funny, I had solved this problem before, but as this is all new clean code, I didn't incorporate the fix. Need to keep track of all of these little gotchas somewhere.

1 0