On Sun, Jun 25, 2017 at 6:24 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > On 25.06.2017 23:42, Ilia Mirkin wrote: >> >> On Sun, Jun 25, 2017 at 5:39 PM, Jason Ekstrand <ja...@jlekstrand.net> >> wrote: >>> >>> On June 25, 2017 2:31:56 PM Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> >>>> On Sun, Jun 25, 2017 at 5:25 PM, Jason Ekstrand <ja...@jlekstrand.net> >>>> wrote: >>>>> >>>>> >>>>> On June 25, 2017 1:40:09 PM Ilia Mirkin <imir...@alum.mit.edu> wrote: >>>>> >>>>>> On Sun, Jun 25, 2017 at 4:33 PM, Jason Ekstrand <ja...@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. > > > 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. 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. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
