[Mesa-dev] ARB_copy_image support in Gallium
brianp at vmware.com
Mon Jul 20 12:53:50 PDT 2015
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.
> 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.
There were several aspects to it:
1. Fix a few issues in the copyimage.c code. The business of wrapping
renderbuffer src/dest surfaces with new texture objects made a mess in
the state tracker so I refactored that code. Had to update the i965
2. The state tracker needed some tweaks in the format selection code to
make better choices.
3. Still need to add a new PIPE_CAP so drivers can opt-in as they're
4. The util_resource_copy_region() code need a bunch of changes to allow
softpipe/llvmpipe to work.
5. A lot of work in our VMware/svga driver.
More information about the mesa-dev