[Mesa-dev] ARB_copy_image support in Gallium

Brian Paul 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.
>> 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.

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 
code too.

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 mailing list