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).
> 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.
>> On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> 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.
>>> mesa-dev mailing list
mesa-dev mailing list