Theoretically resource_copy_region should be the right function for that. Both ARB_copy_image and d3d10 ResourceCopyRegion define this as essentially the equivalent of memcpy. I guess the difficulty is that GL's view classes are a bit different compared to d3d10 typeless groups - d3d10 doesn't allow ResourceCopyRegion with swizzling (actually there are not even ANY formats which would have just different swizzling anyway in d3d10, though some got added back later). So, right now this does NOT require the same formats, but it is loosely specced in docs for the formats to be compatible. See util_is_format_compatible, according to that RGBA vs. RGBX would be compatible, though a depth and corresponding color format would be not (which is ok for gl but not d3d), things like RGBA8_UNORM vs. RGBA8_SINT would certainly qualify.
Not sure though if I like the "memcpy with swizzling" idea. Sounds like that might not be easily implementable in general, unless you revert back to a quad blit, which is not the intention of either gl's nor d3d10's function. Sounds to me like it may be better to leave things as-is, with a fallback to quad blit if the formats require swizzling (or make sure not formats with different swizzling are picked in the first place). Roland Am 20.07.2015 um 20:44 schrieb Ilia Mirkin: > Hi Brian, > > You marked off ARB_copy_image (and ARB_clear_texture) as in-progress > by VMware some months ago -- has there been any movement on that? It > appears that Bioshock Infinite requires ARB_copy_image so might be > nice to get that added in. > > The complication in implementing ARB_copy_image was that st/mesa will > pick potentially different PIPE_FORMAT enums for the same internal > format, depending on the parameters to the glTexImage call. A > developer (irc handle Leftmost, I forget his real name, sorry) tried > to wrestle with the issues this presents, but as I recall ended up > coming up short. > > The final implementation probably needs some combination of > resource_copy_region and blit. I think resource_copy_region currently > is spec'd to require identical formats in src and dst, but that could > be relaxed. > > Anyways, would be interested in hearing whether you guys have made any > progress, or if you had thoughts on proper implementation. > > Cheers, > > -ilia > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=Of_nhwBq9J9BBkf9U_Kjb0VmZ0CyO1GKG1YhKRVSfqk&s=eng7skR_1fpZKpxc7xRJD-tfOjNKaHl0rRr3iBr7_QU&e= > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
