[Mesa-dev] ARB_copy_image support in Gallium

[Roland Scheidegger]

Am 21.07.2015 um 02:10 schrieb Ilia Mirkin:
> On Mon, Jul 20, 2015 at 7:53 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 20.07.2015 um 22:46 schrieb Ilia Mirkin:
>>> On Mon, Jul 20, 2015 at 3:53 PM, Brian Paul <brianp at vmware.com> wrote:
>>>> On 07/20/2015 01:19 PM, Ilia Mirkin wrote:
>>>>
>>>>> On Mon, Jul 20, 2015 at 2:44 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>> As an aside, here's a very naive implementation of the ext, which
>>>>> fails for lots of reasons not the least of which is that we default to
>>>>> BGRA instead of RGBA. Perhaps we could create a resource_copy_region
>>>>> version that also takes (or knows about) swizzles... that should also
>>>>> cover many (all?) of the situations I think.
>>>>
>>>>
>>>> One of our interns did the implementation (with some contributions from me).
>>>> I need to do a lot of clean-up before posting the patches here though.  I
>>>> was hoping to do that in the next month or two.  If you need it sooner, I'll
>>>> can see what I can do.
>>>
>>> As there's a decent chance that tessellation and subroutine support
>>> will land in the next release (thus exposing GL 4.1 in several
>>> drivers), and there is an actual released game that requires
>>> ARB_copy_image, it would definitely be nice to see support land before
>>> the next mesa release is branched off, which should happen in about a
>>> month's time I guess.
>>>
>> Are you sure it actually requires ARB_copy_image (not just optionally
>> uses it)? Seems like it shouldn't be, since officially it only needs GL
>> 4.1, and this extension only became core with 4.3.
>> (There's also a mac version which doesn't support that feature neither).
> 
> I don't personally have the game myself. However the report is that on
> top of nouveau that (accurately) exposes GL 4.1 (i.e. has tess and
> subroutines merged in), it starts calling glCopyImageSubData without
> ARB_copy_image having been exposed. Mesa naturally returns
> INVALID_OPERATION, and nothing is drawn other than the cursor and
> subtitles. My naive implementation (earlier in the thread) makes the
> game operate properly.
> 
Ah ok then. Maybe the game developers figured this feature is exposed on
just about any (newer) drivers which support 4.1 anyway as everybody
certainly can support it. Or they don't query for the availability
correctly (i.e. the old-age beginner error of querying for a gl function
pointer and assuming it works when the pointer is non-null though at
this point I thought everybody would get that one right...).

Roland