[Mesa-dev] Help! CopyImageSubData is defeating me

[Jason Ekstrand]

On June 25, 2017 3:47:09 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Sun, Jun 25, 2017 at 6:24 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 25.06.2017 23:42, Ilia Mirkin wrote:
>>>
>>> On Sun, Jun 25, 2017 at 5:39 PM, Jason Ekstrand <jason at jlekstrand.net>
>>> wrote:
>>>>
>>>> On June 25, 2017 2:31:56 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>
>>>>> On Sun, Jun 25, 2017 at 5:25 PM, Jason Ekstrand <jason at jlekstrand.net>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On June 25, 2017 1:40:09 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>>>
>>>>>>> On Sun, Jun 25, 2017 at 4:33 PM, Jason Ekstrand <jason at jlekstrand.net>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Anyone have thoughts on this? Am I being foolish for trying to hold
>>>>>>>>> onto GL_RGBA4 texturing? (Any decision here also affects st/nine.)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes.  Chances are that you're also doing texture views wrong.  Are
>>>>>>>> there
>>>>>>>> any
>>>>>>>> 4444 formats supported on nvidia hardware?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Well, any permutation of a 4444 format is easily supportable for
>>>>>>> texturing.
>>>>>>>
>>>>>>> What's wrong with the texture views? Should be fine... unless I'm
>>>>>>> missing something. It's really just this issue with RB <-> Texture
>>>>>>> copies where the RB's internal format is GL_RGBA4 while the *real*
>>>>>>> internal format is RGBA8. Texture views between e.g. RGB565 and
>>>>>>> RGBA4444 should work fine (and the fb will fail to validate as one
>>>>>>> might expect if one were to attach a GL_RGBA4 texture view of a
>>>>>>> GL_RGB565 texture).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> But what if you have a 4444 and you render to as 4444 and then try to
>>>>>> texture from it as 565?
>>>>>
>>>>>
>>>>>
>>>>> If you have a 4444 texture and attach it to a FB, then that FB will
>>>>> not be complete. So you can't render to it in the first place.
>>>>
>>>>
>>>>
>>>> Ok, then I'm confused as to how you have a copy_image problem.  Is the
>>>> issue
>>>> just that gallium won't let you CopyImageSubData into a texture you can't
>>>> render into?  Why not just treat it as R16 when using it as a copy_image
>>>> destination?
>>>
>>>
>>> No, the issue is copying between a GL_RGBA4 RB and GL_RGBA4 texture.
>>> Behind the scenes, the GL_RGBA4 RB gets upgraded to a
>>> 8-bit-per-channel format, while the GL_RGBA4 texture has a
>>> 4-bit-per-channel format. Then when trying to copy-image between them,
>>> you have two totally differently-formatted textures.

Oh, you have different formats for texture vs. renderbuffer.  That's 
awkward but I understand the problem now.

>> Bind the GL_RGBA4 destination texture as a GL_RG8UI or GL_R16UI surface and
>> render to it using a shader that does the conversion manually?
>
> Right, so there are 2 directions here... RGBA4 -> RGBA8 I can do with
> a plain blit. RGBA8 -> RGBA4 I need to do something custom, like you
> said.

Sounds about right.

> Do I also need to worry about component ordering? The RGBA8 thing is
> guaranteed to be the renderbuffer side, which I think has a lot less
> opportunity for weirdness -- most of the texture weirdness comes from
> glTexImage format/type options.

I think you're probably ok there assuming the fallbacks work in a 
reasonable way.