[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Please review WebGL multiple render target extension proposal
- To: Gregg Tavares <gman@google.com>
- Subject: Re: [Public WebGL] Please review WebGL multiple render target extension proposal
- From: Kenneth Russell <kbr@google.com>
- Date: Tue, 5 Mar 2013 17:27:34 -0800
- Cc: Florian Bösch <pyalot@gmail.com>, Brandon Jones <bajones@google.com>, Colin Mackenzie <sinisterchipmunk@gmail.com>, Jeff Gilbert <jgilbert@mozilla.com>, Cedric Vivier <cedricv@neonux.com>, public webgl <public_webgl@khronos.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PjxcT+qaAAmqXgb2GjqKtJceyPTHIJljccZD6GlmmlE=; b=k3Zpx0FaEhKDjvCXRKrByp7MV143LWHoBoMRIaEzGYJG7N4ObfVTP9WPAItmjLYuAd 64hBr0IkJYpamz25kCQrR9qT/36A24UcdBovx3JsgOkD9cIWb0GJ2Q484puqaTiS2TnM hMuwbEt0hLdZihNRbS05xcXcr9CGj9IAkXZqF04ypHvV20TvRamYNndJ1xrtOGaADSmn ozCIhDVy40L3SftlR4YqzqfBNnL6qn6jGJHZApfIILucjVhl/aLSUaaFMcGryJM9ZXtu l9E1YYhkPKUiUgcoiyOWmF1U7+fPZ2skijuPfWFj83mDSiMIxFFTscYdmWeN6cDhG4LH 4kew==
- In-reply-to: <CAMYvS2dQuhGOWapB+s10We62QUFPR0B-ANvrhk-kBxNSXDg8UA@mail.gmail.com>
- List-archive: <https://www.khronos.org/webgl/public-mailing-list/archives/>
- List-id: Public COLLADA Mailing List <public_webgl.khronos.org>
- List-owner: <mailto:owner-public_webgl@khronos.org>
- List-post: <mailto:public_webgl@khronos.org>
- List-subscribe: <mailto:majordomo@khronos.org?body=subscribe%20public_webgl>
- List-unsubscribe: <mailto:majordomo@khronos.org?body=unsubscribe%20public_webgl>
- References: <CAOK8ODj2YiYF3SBrRXeKRnKbgvG0yVwPzDQPqSCHQeuc3hiYPA@mail.gmail.com> <1962493783.26851480.1352252165428.JavaMail.root@mozilla.com> <CAOK8ODjWD3JtZXupzVmnsn=Hih3VKQfD1-sy-sZBAjC0CyvUCQ@mail.gmail.com> <CA+a=8J3Wu+Vb=O6adLHifP2H5mCJPtRCN-Jy2huU7arOrWxHCQ@mail.gmail.com> <CAEGwwi3dQ93304q2z5aq=GpRREoP8AzL3HcAPRPi_6vtrMj_FQ@mail.gmail.com> <CAOK8ODiXSqbF_Cz3fQ8b-+kGKDzgWRdHnpuMGNLLKTm_3FGS+w@mail.gmail.com> <CAMYvS2exBEt0+QxFP0bx1rvNkhwDpktLCM4RasDQbkJYm0Na3Q@mail.gmail.com> <CAOK8ODgSAeU=Gk5grgaKRCzocz5Y5JYwrNFjXbvtkU3F+jetLA@mail.gmail.com> <CAMYvS2fC0Hh1WkLsuqLjj18F1BYBgXWr-5423Uo81CFn2ZMx1w@mail.gmail.com> <CAOK8ODgHboxPeccfVouahMMbBFKLw_rknTa0C5Wwen0DN186pg@mail.gmail.com> <CAMYvS2fBh5-neZVnZcCrUBkqM9SAF4VSEytBEz1M-CSfv8DsqA@mail.gmail.com> <CAKZ+BNpzM-jgnSd=gnOuYbejqPERMHkbnBGO_ghx+1dokdz5bg@mail.gmail.com> <CAMYvS2dQuhGOWapB+s10We62QUFPR0B-ANvrhk-kBxNSXDg8UA@mail.gmail.com>
- Sender: owner-public_webgl@khronos.org
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
-----------------------------------------------------------