srkreddy1238 commented on PR #14010: URL: https://github.com/apache/tvm/pull/14010#issuecomment-1437817840
> The advice I'd give here is that is that we don't always need a generic solution to a specific problem, the `--mixed-precision` parameter provides benefits to other `Target`s and doesn't require us creating a new plugin system within `tvmc` - we have similar functionality in the `--alter-layout` parameter. To implement the complete functionality of mixed precision we need passing the list of ops to be converted to mixed precision, precision type and other configurable options for mixed precision pass. All these are use case dependent. If we are good with enabling mixed-precision pass with it's configurable options, I am good to go this way. > What is the use-case for this? I can't think of a use-case for generically bundling things into the eventual output unless I'm missing something, specific `Target`s would likely benefit from it, and they'd better understand the shape of their own dependencies which indicates it should be done in some `Target` hook? (Thinking of the example with CMSIS-NN where-in we may use this kind of hook to bundle the CMSIS kernels or API descriptions) My use case is about embedding additional tuning cache and target precompiled OpenCL binary source into the module itself. These tuning cache and clBinary blobs will be generated by running the compiled modules on real device via RPC. I don't think we now encourage this way from the core compilation flow itself. IMHO, such first time requirements should enabled outside core compiler and later absorbed if there are more similar use cases. > Sounds a bit dangerous to me, generically calling a packed function against a module also means you have access to a plethora of other registered functions - do we want to expose them all to the audience of `tvmc`? I'd also still push for things that are more specific to a given `Target` to be attached to the `Target` itself, so the scripting API and CLI remain aligned. Its a great tool for new comers with it's simplicity and functionality. In my opinion, ```tvmc``` is a good starting point for a newbie to quickly achieve the entire process from CLI. On the other side, packed function system is not some thing we want to hide from users. We encourage users to register their own packed functions into TVM compiler flow as well as use TVM's packed functions. From a newbie point of view, option ```--pre-build-hooks "adreno.mixed_precision_fp16"``` is just a command line option and don't even know about ```packed function``` or there exists a global registry. Without ```tvmc`` support, the user need to learn and switch into python interface for more functionality. We are talking about only two options - Add functionality directly into TVM compiler core (accessible via ```tvmc```) - Use python interface for advanced feature access. I am talking about a staging option. It's like a feature which require some feedback from developers/users before making it a mainline compiler feature (due to it's complexity to implement into mainline compiler or does it have more audience or not). As I see, we have two perspectives here to consider. One being ```tool integrity``` and other ```user experience```. Staging helps ```tool integrity``` as we don't need to take every feature on day one into ```tvmc```. Other hand, these options definitely results good user experience as all the functionality can be achieved through CLI interface. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
