Anyone else have opinions on this? Should st/mesa be adding PIPE_BIND_RENDER_TARGET for all textures of the internal formats listed in table 8.12? (Which would, in this case, force RGBA8 to be used since RGBA4 is non-renderable.) Or is it perfectly legal for a format to be not renderable when used as a texture vs renderbuffer?
On Wed, Sep 7, 2016 at 1:19 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > Right, but it'd break st/nine which doesn't (didn't?) support > fallbacks like st/mesa does. > > I'm trying to better understand what the required logic is based on > the spec, not how to fix this particular application's rendering with > nouveau (which I'm much less concerned about, tbh). > > -ilia > > On Wed, Sep 7, 2016 at 1:16 PM, Marek Olšák <mar...@gmail.com> wrote: >> Dropping texturing support for RGBA4 would resolve that issue. >> >> Marek >> >> On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> Hello, >>> >>> Is there a concept in OpenGL that certain internal formats *must* be >>> supported for rendering? An issue we're running into is that NVIDIA >>> hardware supports sampling from RGBA4 textures, but does not support >>> that as a render format. So if you create a tex image with GL_RGBA4, >>> we use that as the TexFormat, since we can sample from it. However >>> then attaching the image to a fbo makes that fbo incomplete. >>> >>> At least one application isn't ready to handle that situation. Is the >>> application wrong, or must we support GL_RGBA4 as a renderable texture >>> attachment format, thus meaning that we should never actually make use >>> of the hw's RGBA4 sampling capabilities (since we never know if a >>> texture will later be used for rendering)? >>> >>> The spec is a bit unclear about this. Table 8.12 of the GL 4.5 core >>> spec marks GL_RGBA4 as "required renderable", but I think that only >>> affects renderbuffers (which st/mesa handles properly by falling back >>> to RGBA8 when the requested format is not renderable). >>> >>> Any advice welcome. >>> >>> Cheers, >>> >>> -ilia >>> _______________________________________________ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
