[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Please review WebGL multiple render target extension proposal



On Fri, Feb 15, 2013 at 9:08 PM, Gregg Tavares <gman@google.com> wrote:
> I've been writing the conformance tests for EXT_draw_buffers and a few
> things have come up and I'd like to suggest we make it WEBGL_draw_buffers
> and add a few changes
>
> 1) Let's require minimum 4 drawing buffers.
>
> EXT_draw_buffers only requires 1 buffer. That seems rather pointless. Why
> make devs have to check twice, once for the extension and again that it's
> useful?
>
> Can we decide the minimum is 4 draw buffers? GPUs that support more than 1
> all support at least 4 AFAICT. ES 3.0 requires 4.

This sounds good.


> 2) Let's require that MAX_COLOR_ATTACHMENTS be >= MAX_DRAW_BUFFERS
>
> The spec doesn't require this. MAX_COLOR_ATTACHMENTS could be 2 and
> MAX_DRAW_BUFFERS could be 4 which would be useless. I can't imagine a GPU
> that would do that so why allow it in the spec and therefore force devs to
> deal with that situation should some crazy GPU maker ship something like
> that

This sounds fine too. If it happened the GPU reported a
MAX_DRAW_BUFFERS > MAX_COLOR_ATTACHMENTS the WebGL implementation
could just clamp it, yes?



> 3) Let's require that attaching GL_RGBA/GL_UNSIGNED_BYTE to all attachment
> points be required to work
>
> I might have missed this in the spec but I believe OpenGL ES 3.0 still
> allows drivers to fail any combination of attachments. Let's pick at least
> one format that devs can count on.

It looks like the ES 3.0 spec requires that attaching valid textures
and renderbuffers results in a complete framebuffer, modulo
implementation dependent restrictions. See the subsection "Required
Framebuffer Formats" on page 210 of the ES 3.0.1 spec:

"Implementations must support framebuffer objects with up to
MAX_COLOR_ATTACHMENTS color attachments, a depth attachment, and a
stencil attachment. Each color attachment may be in any of the
required color formats for textures and renderbuffers described in
sections 3.8.3 and 4.4.2."

EXT_draw_buffers (deliberately?) doesn't include any of the language
from the ES 3.0 spec about which formats and color attachments are
required to be supported.

Seems OK to me to require this and test it in the conformance suite,
but how would a WebGL implementation reasonably test this at runtime
before returning the EXT_draw_buffers extension object?


> 3b) Let's (maybe) require that attaching less than the max draw buffers be
> required to work
>
>    In other words, if MAX_DRAW_BUFFERS = 4 then
>
>       COLOR_ATTACHMENT0 = GL_RGBA/GL_UNSIGNED_BYTE
>
>       and
>
>       COLOR_ATTACHMENT0 = GL_RGBA/GL_UNSIGNED_BYTE
>       COLOR_ATTACHMENT1 = GL_RGBA/GL_UNSIGNED_BYTE
>
>       and
>
>       COLOR_ATTACHMENT0 = GL_RGBA/GL_UNSIGNED_BYTE
>       COLOR_ATTACHMENT1 = GL_RGBA/GL_UNSIGNED_BYTE
>       COLOR_ATTACHMENT2 = GL_RGBA/GL_UNSIGNED_BYTE
>
>       and
>
>       COLOR_ATTACHMENT0 = GL_RGBA/GL_UNSIGNED_BYTE
>       COLOR_ATTACHMENT1 = GL_RGBA/GL_UNSIGNED_BYTE
>       COLOR_ATTACHMENT2 = GL_RGBA/GL_UNSIGNED_BYTE
>       COLOR_ATTACHMENT3 = GL_RGBA/GL_UNSIGNED_BYTE
>
>   All work. No requirement that sparse attachments work (0 & 3) or (2) etc
> work. Just starting from 0 up to MAX.

Seems reasonable. Same question about how this could be verified at
run-time before returning an instance of the extension object.


> 3c) Let's require that #3 and #3b work with a DEPTH or DEPTH_STENCIL
> attachment
>
> I'm assuming all GPUs that support MRTs do this

Seems reasonable; same question.


> 4) Should we disallow having 2 or more attachment points point to the same
> attachment?
>
> In other words, make a single texture and attach it to both
> COLOR_ATTACHMENT0 and COLOR_ATTACHMENT1. The spec does not cover what
> happens there. The worry is someone will attach the same texture by mistake
> to 2 attachment points and depending on the GPU/Driver they'll get different
> results.

I think we should postpone this; it sounds like there are multiple
ways this might be handled and we can make progress without solving it
now.

-Ken



> Thoughts?
>
>
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------