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

[Kenneth Russell <kbr@google.com>]

Gregg, thanks for your suggestions. EXT_draw_buffers has been renamed
to WEBGL_draw_buffers in order to support stricter rules in WebGL, and
your suggested requirements have been added to the draft extension
spec:

http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/

Please review and comment.

Thanks,

-Ken


On Tue, Feb 19, 2013 at 12:55 PM, Kenneth Russell <kbr@google.com> wrote:
> 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
-----------------------------------------------------------