Step 1 here I think is get CompositingModeReporter/Software compositing mode decisions set up with --enable-viz. There's todos in VizProcessTransportFactory, RenderProcessHostImpl, and BrowserMainLoop to address.

I don't know much about the service-side software compositing code (such as viz::SoftwareRenderer) but I've looked at the code for allocating SharedBitmaps before. Viz should allow all clients to request a SharedBitmapAllocationNotifier interface. The client should pass the InterfacePtr to ClientSharedBitmapManager and the delivery of SharedBitmaps to Viz should just work. When the mojo connection is closed, Viz should destroy all of the child's SharedBitmaps to avoid leaking memory (Currently we depend on RenderProcessHostImpl to tell us the child has died. See SharedBitmapAllocationNotifierImpl::ChildDied). This will hopefully make software compositing work but  crbug.com/734058  will happen. Probably we can add the code I added to RednerWidgetHostImpl (See https://chromium-review.googlesource.com/c/chromium/src/+/565645) to CompositorFrameSinkImpl and it'll solve that issue. I don't worry about restartability because Viz in software mode is not supposed to crash.

SwiftShader is probably not fast enough for a launchable implementation. I think that the high road is to use SkiaRenderer but turn off Ganesh. And ideally, restart would still work even in software mode unless it's much harder to implement?

Right there is no plan to use swiftshader for compositing.

I'd like restart to work because raster code is moving to the gpu process and renderers can restart if raster breaks, it'd be nice if the browser didn't break after moving it to the gpu process. I don't think it'll be any harder than gpu restart.

Migrating from Internals>Viz to Internals>Services>Viz.

Oh I've been working on this over in 730660