[Mesa-dev] ARB_copy_image support in Gallium

[Roland Scheidegger]

I just realized that there's actually another difference if you'd use
the util_is_format_compatible to see whether resource_copy_region may be
used: d3d style, this would exclude things like rg16 being compatible
with r32 completely, swizzled or not (this is how d3d10 typeless groups
work). Granted it never really was documented that well... But if you'd
want to allow uncompressed->compressed copies too that definitely should
be documented.

I think that generally you'd prefer resource_copy when you can, because
blit can do a lot more in general. Though of course nothing prevents you
to detect blits which you can do with (say) a dma engine.
resource_copy should also work with all type of resources, buffers and
the like which are also excluded from blits (anything non-renderable).

But of course the resource_copy stuff is way older than GL's view
classes, so it's not surprising it isn't quite specced to be able to do
everything ARB_copy_image can, since GL's view classes turned out to be
fairly incompatible compared to d3d10 typeless groups.

Roland



Am 21.07.2015 um 18:01 schrieb Marek Olšák:
> I don't think resource_copy_region is a good match for all possible
> cases that can occur with ARB_copy_image and I extensively explained
> this to Ilia on IRC. The format swizzling is the problem.
> 
> Assume you have a copy from RGBA8 to R32F. This is equivalent to
> copying RGBA8 to RGBA8, because it's just memcpy and therefore
> pipe->blit can use dst.format=RGBA8 instead of R32F. Now, where I'm
> going with this... If the source is actually BGRA8, you can set the
> source format to that and it will properly swizzle the texture and
> store it as dst.format=RGBA8 directly into the R32F texture. This
> resolves the swizzling issue nicely using the existing functionality
> without needing other hacks or changes in the format selection code.
> 
> As for whether to use blit or resource_copy_region, I don't think that
> question is important and either would work in a lot of cases. Drivers
> that prefer resource_copy_region over blit should use
> util_try_blit_via_copy_region in their blit implementation. The only
> case where resource_copy_region must be used is copying compressed
> textures.
> 
> Marek
> 
> 
> On Mon, Jul 20, 2015 at 9:56 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> 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 at 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 at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=MV4lSzJKa56LzbAd_Ql4tgZaXQNePNCBhtoJ7KZXy5I&s=Pzbw_CMJFH28cqmrJRl-P5rRsC4gKVQ2uHWM57KzURE&e=