Am 21.07.2015 um 02:10 schrieb Ilia Mirkin: > On Mon, Jul 20, 2015 at 7:53 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 20.07.2015 um 22:46 schrieb Ilia Mirkin: >>> On Mon, Jul 20, 2015 at 3:53 PM, Brian Paul <bri...@vmware.com> wrote: >>>> On 07/20/2015 01:19 PM, Ilia Mirkin wrote: >>>> >>>>> On Mon, Jul 20, 2015 at 2:44 PM, Ilia Mirkin <imir...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
