You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the next PR, I think it'd be useful to create an FXReport object. What I'm thinking is:
Create a new function called fx_report (not Thunder-specific)
Return a FXReport object from fx_report
The FXReport object has a sequence of FXGraphReport objects, one per fx graph in the original program
Each FXGraphReport has a method to write a reproducer script
The method should be able to easily select whether the reproducer uses PyTorch eager, torch.compile, or thunderfx (with some supported options)
For total control, the method should allow writing an arbitrary executor string and allow for extending what's imported with arbitrary import strings, in case someone wants to use a very special version of thunderfx or torch.compile or PyTorch eager
Each FXGraphReport should allow its FXGraph's inputs to be queried (they can just be FakeTensors for now)
And that would generate four reproducers for each of the FX graphs in the program, each one using the different requested executor.
Writing the reproducers directly like this may not be super interesting in isolation, but once that's working we can add more of the data that thunderfx_report makes available, and that will become really interesting really fast. It would also be great if the existing reporting functionality, like thunderfx_report could be updated to use FXGraphReport and FXReport objects internally for consistency. Using modular Python objects for the report data and analysis should make it easier for us to develop and for others to extend.
For the next PR, I think it'd be useful to create an FXReport object. What I'm thinking is:
fx_report
(not Thunder-specific)fx_report
So someone could do something like:
And that would generate four reproducers for each of the FX graphs in the program, each one using the different requested executor.
Writing the reproducers directly like this may not be super interesting in isolation, but once that's working we can add more of the data that
thunderfx_report
makes available, and that will become really interesting really fast. It would also be great if the existing reporting functionality, likethunderfx_report
could be updated to useFXGraphReport
andFXReport
objects internally for consistency. Using modular Python objects for the report data and analysis should make it easier for us to develop and for others to extend.What are your thoughts, @kiya00?
Originally posted by @mruberry in #1636 (comment)
The text was updated successfully, but these errors were encountered: