[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The state of MRTs
The attached picture illustrates our WebGL extension approval process.
To my memory, it's been since the first rumors about WebGL that the benefits of MRT have been enumerated. If we still need to bring examples of why they are good if not crucial (@Florian: I quoted you just for reasoning (: ), I think that something bigger is under the hood that prevent MRT to be included in WebGL. If it is like so, I'd like to hear a clear NO from the WG, so we can just stop dreaming/speculating and don't be stuck in a loop.
No need for far-fetched explanations here.Rather, as far as I'm concerned, just a mix of:
- Me not understanding, until Gregg's email today, how useful and widely used MRTs are
- I'm more interested in making the current WebGL feature-set work better, than extending the feature-set. I.e., just priorities.
- In this instance, extending the feature-set comes at the apparent cost of losing some portability on mobile devices. (I understand Gregg's argument about how "all devices allow N RTs, just with N=1 sometimes" but that's exactly like the VTF situation and we've been bitten there, with real-world WebGL demos not working on mobile devices (like Tegra and Tegra2) because of lack of VTF support, or if you prefer, "VTF with N=0".
I want to add that the above is NOT arguing against MRTs now. It's an explanation of why personally I haven't supported that proposal so far.
If people agree that the usefulness of MRTs is high enough given the cost (distracting from other WebGL work, reducing portability) then I can understand that. I just don't agree with statements that there is no reason at all against doing MRTs now.
On Tue, Mar 27, 2012 at 9:52 PM, Florian Bösch <email@example.com>
On Tue, Mar 27, 2012 at 9:38 PM, Gregg Tavares (勤) <firstname.lastname@example.org>
All devices currently support MRT. Low end devices support N render targets where N = 1.
For some weird reason OpenGL ES choose not to forward-compatible the FBO featureset by allowing for N>1 rendertargets. I don't understand why that was done this way, if it hadn't been, we could get a clear picture now what mobile devices actually support MRT and they would not have to discuss/ratify another set of extensions for ES. Any insight as to what the ES-WG plan in regards to MRT would be, would be appreciated.
MRT was introduced in 2003, over 9 years ago. It's been used nearly every PC game since Half Life 2. Getting more adoption by top game developers means adding more features they need to make their games.
This problem won't go away ever. Waiting a year or 2 years, or 5 years won't change the fact that there will always be devices where MAX_COLOR_ATTACHMENTS is less than other devices.
With a support rate around 80%, everybody on desktops has to do an alternative renderingpath to MRTs anway. But that number isn't gonna go down. 2 or 5 years from now, not only will the problem not go away, it will be worse, because 2-5 years from now 98% of desktops will have MRT support. If you do it now, like right now, it's the least pain you're ever gonna get, the pain's not gonna get any smaller by any amount of waiting.
MRT is a perf improvement. A huge one.
I do actually think that MRT support is a bigger boon to mobile devices than to desktops. Desktops often do have enough juice to simply render a scene multiple times. Doing the same on mobiles is disproportionally more expensive because they have far less GPU power. So speeding up techniques that require multiple outputs (like normal, depth, color, specularity etc.) is a disproportional advantage in mobiles.
Marco Di Benedetto, Ph.D.
Researcher at the Visual Computing Lab
Istituto di Scienza e Technologie dell'Informazione "A. Faedo" (ISTI)
Consiglio Nazionale delle Ricerche (CNR) - Pisa - Italy
Office Phone: +39 050 315 2921