This is maybe a silly idea, but i'd like inputs from the D3D experts: We have seen that some intel drivers fail to sample from shared surface in shaders, but can copy the surfaces with D3D11. If we can detect that this is happening (and Jeff has a minimal testcase that we could run at startup to check that), we could have D3D11 TextureHosts, copy their data into a TextureSource rather than let the TextureSource sample from the shared texture directly. This would trun the D3D11 TextureHost into an internally buffered texture (which is a behavior that we support and ship on fennec (and Mac?)). We'd only do that if we detect that the driver has this particular issue, but it would let us use D3D11 for the affected users (currently a lot of users get their driver blacklisted over this issue). thoughts?

I'm not extremely opposed though it seems like it could cause a noticeable memory/bandwidth increase.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #1) > I'm not extremely opposed though it seems like it could cause a noticeable > memory/bandwidth increase. I agree, and that concerns me, especially on Intel devices with SMA. What I'd suggest if we wanted to go this route is rather open the shared texture on the content thread, do a copy there into a non-shared texture belonging to the composition device, and use that form of 'double buffering' rather than our current flipping logic. That would be a lot of code though to support a relatively small group of users. I'm not convinced we want that.