Bug 1684781 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

BlitFramebuffer rb->rb is absolutely supposed to work, but likely all createRenderbuffer RBs in ANGLE have D3D11_BIND_SHADER_RESOURCE. I'm not sure why the resource has DXGI_USAGE_SHADER_INPUT but the D3D11Texture doesn't have D3D11_BIND_SHADER_RESOURCE.

There's a risk that going BGRA->RGBA is a less efficient path. There's no real reason this can't be just as efficient, but it happens sometimes in drivers.

I'm surprised that we're blitting *from* a DComp texture! Why is the picture cache tile a dcomp surface? (Maybe I'm misunderstanding what "picture cache tile" is?) Is this a blit-from-dcomp;edit;blit-back-to-dcomp?

We could upstream something to handle the true-renderbuffer-with-no-D3D11_BIND_SHADER_RESOURCE path.

It sounds like we need to have the formats actually match in D3D, so I doubt CopyImageSubData does any better here. Apparently this is something where GL is more permissive via BlitFramebuffer than D3D is via CopySubresourceRegion, unless I'm reading the docs here wrong for D3D.
BlitFramebuffer rb->rb is absolutely supposed to work, but likely all CreateRenderbuffer RBs in ANGLE have D3D11_BIND_SHADER_RESOURCE. I'm not sure why the resource has DXGI_USAGE_SHADER_INPUT but the D3D11Texture doesn't have D3D11_BIND_SHADER_RESOURCE.

There's a risk that going BGRA->RGBA is a less efficient path. There's no real reason this can't be just as efficient, but it happens sometimes in drivers.

I'm surprised that we're blitting *from* a DComp texture! Why is the picture cache tile a dcomp surface? (Maybe I'm misunderstanding what "picture cache tile" is?) Is this a blit-from-dcomp;edit;blit-back-to-dcomp?

We could upstream something to handle the true-renderbuffer-with-no-D3D11_BIND_SHADER_RESOURCE path.

It sounds like we need to have the formats actually match in D3D, so I doubt CopyImageSubData does any better here. Apparently this is something where GL is more permissive via BlitFramebuffer than D3D is via CopySubresourceRegion, unless I'm reading the docs here wrong for D3D.
BlitFramebuffer rb->rb is absolutely supposed to work, but likely all (single-sampled) CreateRenderbuffer RBs in ANGLE have D3D11_BIND_SHADER_RESOURCE. I'm not sure why the resource has DXGI_USAGE_SHADER_INPUT but the D3D11Texture doesn't have D3D11_BIND_SHADER_RESOURCE.

There's a risk that going BGRA->RGBA is a less efficient path. There's no real reason this can't be just as efficient, but it happens sometimes in drivers.

I'm surprised that we're blitting *from* a DComp texture! Why is the picture cache tile a dcomp surface? (Maybe I'm misunderstanding what "picture cache tile" is?) Is this a blit-from-dcomp;edit;blit-back-to-dcomp?

We could upstream something to handle the true-renderbuffer-with-no-D3D11_BIND_SHADER_RESOURCE path.

It sounds like we need to have the formats actually match in D3D, so I doubt CopyImageSubData does any better here. Apparently this is something where GL is more permissive via BlitFramebuffer than D3D is via CopySubresourceRegion, unless I'm reading the docs here wrong for D3D.

Back to Bug 1684781 Comment 9