Open plynkus opened 5 years ago
The submission highlights IMTLRenderCommandEncoder.SetFragmentTexture, though I think it applies to a number of vertex- and fragment-related methods on the interface. The issue is that some of these methods (and the latched state they represent on the encoder) should support null values (which are the valid defaults) per the Apple docs.
We are attempting to track down an egregious texture memory leak during a high rate texture streaming use case that so far seems to boil down to whether or not we bind these textures via the encoder at all (i.e. leak only when referenced on the encoders---we can background load/dispose without issue otherwise). In attempting to clear bound state wherever we can as a debugging exercise, we observed the apparent API binding discrepancy.
In the interim we have substituted a permanent proxy/singleton 1x1 as our clear value while we try and identify why our should-be-jettisoned textures remain in memory.
I just checked the header file, and yes I can confirm we've missing a number of null attributes. Invoking those APIs with null should work.
It is possible that we bound some of these in an older version of the header that did not have them, or that they were just missed.
We'll look at fixing all of the affected APIs, but given the number it might not get done right away. If there is a small number of APIs that you need to be unblocked, let me know and I can get you a "manual binding", a chunk of code you can paste into your project to work around the bug.
Thanks for the timely response, Chris. At the moment this is non-blocking for our current leak hunt, so a workaround manual binding is not required. I appreciate the offer.
Steps to Reproduce
Expected Behavior
The call is accepted.
Actual Behavior
Unhandled Exception:
System.ArgumentNullException: Value cannot be null. Parameter name: texture
Environment