On 13.10.2016 17:15, Ilia Mirkin wrote:
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?
I think the spec is pretty clear that the "req.rend." column of that
table is only for renderbuffers.
It's a lot less clear about what really matters for this question. In
section 9.4.3 (Required Framebuffer Formats), there's the curious sentence:
Each color attachment may be in any of the color-renderable
formats described in section 9.4 (although implementations
are not required to support creation of attachments in all
color-renderable formats).
Color-renderable formats are those which have a checkmark in the CR
column according to section 9.4. That means pretty much _all_
non-compressed formats (except for the shared exponents one). I doubt
that the intention is to force stuff like R3_G3_B2 to be renderable.
It's kind of funny that the sentence says that the attachments may be in
any of these formats, but you may not be able to create the attachments?
I think what that's trying to say is that the implementation MUST reject
color attachments that are not CR according to table 8.12, and it MAY
reject color attachments of any format it likes.
So I tend to side with the interpretation that exposing RGBA4 as texture
format but not allowing to render to it is okay by the spec, and the
application has a bug. It's pretty ridiculous though that apparently the
spec doesn't even mandate that RGBA8 must be renderable.
Cheers,
Nicolai
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
