perspective + filters + gpu + conservative_rasterclip ?

Issue description

SkGpuDevice has an override for forceConservativeRasterClip. If this returns true, we compute a conservative version of the rasterclip for any clipFoo calls made to the canvas. The intent is that the gpu-device doesn't care about the rasterclip anyway, so its fine to cheat and go faster.
However, if we draw certain gms through perspective with this enabled, we get different bits than with this disabled.
[*] 12 ExpectationsMismatch: blurrects_gpu.png bigblurs_gpu.png imageblurtiled_gpu.png matrixconvolution_gpu.png dropshadowimagefilter_gpu.png skbug1719_gpu.png imageresizetiled_gpu.png xfermodeimagefilter_gpu.png blurquickreject_gpu.png imagefilterscropped_gpu.png verttext_gpu.png imagefiltersclipped_gpu.png
Why is this happening? Bug in the conservative code, or bug in canvas or bug in filters?

Pixel-moving image filters (blur, matrixconvolution, drop shadow) are pretty broken with a perspective matrix -- they do a best-effort to apply the CTM, but they do a pretty poor job if there's anything but scale & translate. So if just rebaselining the tests and calling it a day is an option, I'd do that.
However, I notice that there are more than just image filters changed here: blurrects and bigblurs are both mask blurs, IIRC. Maybe Greg could speak to those.