Disable MTLCommandBufferErrorOptionEncoderExecutionStatus in release mode#40453
Disable MTLCommandBufferErrorOptionEncoderExecutionStatus in release mode#40453dnfield merged 2 commits intoflutter:mainfrom
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
This is useful when there is a GPU fault and we are trying to pinpoint the faulting command buffer and get additional context on the fault. A log from this mechanism would come in handy if we were able to get it for the iOS screen flickering issue for example. It is added speculatively and if it is causing issues, we can back it out. |
2 participants
See flutter/flutter#122906
The best I can tell from Instruments when running that test 1000 times over is that Apple has some bug around leaking these.
I'm not really clear on how much value we really get out of the tracing here and hope that @bdero or @chinmaygarde can explain that further. It seems possible to me that in some kind of add-to-app scenario it would be possible to hit limitations around this. In local testing, I was consistently seeing OOM related issues after either 49 or 240 runs of the compute unittests. With this block commented out I could do 1000 and memory stayed relatively flat.