TextureFromImageYes, Graphite has a different model on handling of SkImages than Ganesh. Specifically, in Graphite the client has to specifically create SkImages that are GPU backed. Previously in Ganesh this was done behind the scenes if a client passed in a CPU/Bitmap/etc backed SkImage. In many ways this was convenient but it also led to hidden performance surprises to clients when they weren't expecting large uploads to happen (especially when things would move in and out of our internal cache). Now we require the client to explicitly make a graphite backend SkImage so they know there is work involved and they are responsible for keeping that SkImage alive as long as they want it.
To create a graphite backed SkImage you can simply call `SkImages::TextureFromImage` or any of the similar factory functions in `graphite/Image.h.` Additionally when making a Recorder in graphite you can pass in a RecorderOptions struct. On this struct there is a field for a ClientImageProvider. If this is provided, the Graphite backend will call a client provided callback anytime it encounters a non graphite backed SkImage. The callback will give the client an opportunity to return a new SkImage that is Graphite backend. You'll still need to use the factories mentioned above, but the ClientImageProvider callback is a way to catch cases you may have missed to make Graphite SkImages. Additionally it gives you extra information for e.g. should the SkImage be mipmapped or not based on the draw request.
One final side note, in Graphite all SkSurfaces and SkImages held by the client no longer count against Skia's internal GPU budget. Instead the client is responsible for caching them and managing the budget for them. Graphite now only considers memory it is using and allocating internally against its budget.