From pya...@ Thu Mar 1 02:13:56 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 1 Mar 2012 11:13:56 +0100 Subject: [Public WebGL] Depth Texture Extension In-Reply-To: <5136C6F4-FA1A-4A93-B3B9-9302AF264AF4@transgaming.com> References: <9B3BEF16CBC82A45900B3F159DF915960175762318DF@EU-MAIL-1-1.rws.ad.ea.com> <862FEEDB-9BF4-4B1C-8912-43B02C02A2BD@transgaming.com> <6EB4A909-F9EF-4335-ACD9-E5FF03EB4B72@transgaming.com> <5136C6F4-FA1A-4A93-B3B9-9302AF264AF4@transgaming.com> Message-ID: On Thu, Mar 1, 2012 at 5:25 AM, Daniel Koch wrote: > The OES_depth_texture specification (at > http://www.khronos.org/registry/gles/extensions/OES/OES_depth_texture.txt) > has been updated to reflect these changes. > As such, the WEBGL_depth_texture proposal can be changed back to > OES_depth_texture. Patch attached. Exchanged the WEBGL prefix for this extension with the OES prefix, and removed the addendum so it now mirrors without modification. Patch is attached for the old file location (extensions/proposals/WEBGL_depth_texture). Please rename that to extensions/proposals/OES_depth_texture after patch application (svn can't deal with file moves) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oes_depth_texture.patch Type: text/x-patch Size: 2451 bytes Desc: not available URL: From kbr...@ Thu Mar 1 13:58:52 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 1 Mar 2012 13:58:52 -0800 Subject: [Public WebGL] Depth Texture Extension In-Reply-To: References: <9B3BEF16CBC82A45900B3F159DF915960175762318DF@EU-MAIL-1-1.rws.ad.ea.com> <862FEEDB-9BF4-4B1C-8912-43B02C02A2BD@transgaming.com> <6EB4A909-F9EF-4335-ACD9-E5FF03EB4B72@transgaming.com> <5136C6F4-FA1A-4A93-B3B9-9302AF264AF4@transgaming.com> Message-ID: Fantastic. Thanks Daniel for pushing through the OES_depth_texture changes. Florian, I've committed your changes (thanks) and they'll show up shortly. -Ken On Thu, Mar 1, 2012 at 2:13 AM, Florian B?sch wrote: > On Thu, Mar 1, 2012 at 5:25 AM, Daniel Koch wrote: >> >> The OES_depth_texture specification (at >> http://www.khronos.org/registry/gles/extensions/OES/OES_depth_texture.txt) >> has been updated to reflect these changes. >> >> As such, the WEBGL_depth_texture proposal can be changed back to >> OES_depth_texture. > > > Patch attached. Exchanged the WEBGL prefix for this extension with the OES > prefix, and removed the addendum so it now mirrors without modification. > Patch is attached for the old file location > (extensions/proposals/WEBGL_depth_texture). Please rename that to > extensions/proposals/OES_depth_texture after patch application (svn can't > deal with file moves) > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Mar 1 14:37:31 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 1 Mar 2012 14:37:31 -0800 Subject: [Public WebGL] Re: Move OES_element_index_uint and WEBGL_depth_texture proposals to draft In-Reply-To: References: Message-ID: On Mon, Feb 27, 2012 at 6:32 PM, Kenneth Russell wrote: > All, > > Per email on the thread about EXT_texture_filter_anisotropic, I'd like > to propose moving the OES_element_index_uint and WEBGL_depth_texture > extension proposals to draft status. This would allow browsers to > implement them for experimental purposes under a vendor prefix. > > ?http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ > ?http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ > > Note that for each of these extensions, the portability concerns have > been addressed. OES_element_index_uint is supported in iOS 5, and > WEBGL_depth_texture specifies enough restrictions that it is > implementable on both desktop and mobile hardware. > > Are there any objections to moving them? There weren't any objections and there was support on other email threads, so these have been moved. http://www.khronos.org/registry/webgl/extensions/OES_element_index_uint/ http://www.khronos.org/registry/webgl/extensions/OES_depth_texture/ See http://www.khronos.org/registry/webgl/extensions/ . -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Sat Mar 3 15:36:53 2012 From: bja...@ (Benoit Jacob) Date: Sat, 3 Mar 2012 15:36:53 -0800 (PST) Subject: [Public WebGL] Added conformance test: bufferData on null data -> INVALID_VALUE In-Reply-To: <689548510.4457614.1330817626736.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1867176040.4457671.1330817813095.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Hi, This is to let you know about r17021: this adds a new test to conformance/buffers/buffer-data-array-buffer.html, checking that bufferData on null data generates INVALID_VALUE, per the spec section 5.14.5. Thanks to Ms2ger for finding about this. Not adding this to 1.0.1 as that doesn't seem like a big emergency. Benoit PS: I wanted to test this on chromium on my Linux machine but I couldn't figure how to enable WebGL? I have Ubuntu 11.10 x86-64, Mesa 7.11, radeon driver. Anyway, per the discussion in Khronos bug 386, it seems that WebKit has been spec-compliant on this for a very long time. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From zhe...@ Sat Mar 3 16:57:29 2012 From: zhe...@ (Mo, Zhenyao) Date: Sat, 3 Mar 2012 16:57:29 -0800 Subject: [Public WebGL] Added conformance test: bufferData on null data -> INVALID_VALUE In-Reply-To: <1867176040.4457671.1330817813095.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <689548510.4457614.1330817626736.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1867176040.4457671.1330817813095.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: In the about:flags, check ignore software rendering list On Sat, Mar 3, 2012 at 3:36 PM, Benoit Jacob wrote: > > Hi, > > This is to let you know about r17021: this adds a new test to conformance/buffers/buffer-data-array-buffer.html, checking that bufferData on null data generates INVALID_VALUE, per the spec section 5.14.5. > > Thanks to Ms2ger for finding about this. > > Not adding this to 1.0.1 as that doesn't seem like a big emergency. > > Benoit > > PS: I wanted to test this on chromium on my Linux machine but I couldn't figure how to enable WebGL? I have Ubuntu 11.10 x86-64, Mesa 7.11, radeon driver. Anyway, per the discussion in Khronos bug 386, it seems that WebKit has been spec-compliant on this for a very long time. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Mon Mar 5 06:20:52 2012 From: jda...@ (John Davis) Date: Mon, 5 Mar 2012 08:20:52 -0600 Subject: [Public WebGL] Swiftshader/webgl Message-ID: Is there a way to render 3d at something like 320x240 but then smooth stretch the image to something like 800x600? For no gpu systems on winxp we'll need to be able to watch frame rate and rein in the computational intensity accordingly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ase...@ Mon Mar 5 06:27:34 2012 From: ase...@ (Alvaro Segura) Date: Mon, 05 Mar 2012 15:27:34 +0100 Subject: [Public WebGL] Swiftshader/webgl In-Reply-To: References: Message-ID: <4F54CD56.10503@vicomtech.org> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logovicomtech_150.png Type: image/png Size: 10321 bytes Desc: Visual Interaction Communication Technologies URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: barraSinFondo_150.png Type: image/png Size: 2828 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ojo.png Type: image/png Size: 4363 bytes Desc: Visual Interaction Communication Technologies - IK4 Research Alliance URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GraphicsMediaNet-IK4_150.png Type: image/png Size: 14327 bytes Desc: International Network for the Cooperation in Applied Research in Computer Graphics, Multimoda-Multimedia Technologies and Visual Interactive Digital Media Technologies - IK4 Research Alliance URL: From bja...@ Mon Mar 5 06:28:46 2012 From: bja...@ (Benoit Jacob) Date: Mon, 5 Mar 2012 06:28:46 -0800 (PST) Subject: [Public WebGL] Swiftshader/webgl In-Reply-To: Message-ID: <1908894621.4750960.1330957726151.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Of course! You could just create a 320x240 canvas and stretch it with some CSS, I guess (I don't know anything about CSS but I expect that it works like that). If you want a pure-WebGL solution, you could render to a 320x240 texture attached to a framebuffer object and then render that to your real canvas. You won't have to go all the way down to 320x240 to get useful performance from a good software renderer. With simple enough shaders, and a decent CPU, 640x480 @ 60 FPS is doable. Benoit ----- Original Message ----- > Is there a way to render 3d at something like 320x240 but then smooth > stretch the image to something like 800x600? For no gpu systems on > winxp we'll need to be able to watch frame rate and rein in the > computational intensity accordingly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon Mar 5 09:18:15 2012 From: jda...@ (John Davis) Date: Mon, 5 Mar 2012 11:18:15 -0600 Subject: [Public WebGL] Re: Swiftshader/webgl In-Reply-To: <1908894621.4750960.1330957726151.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1908894621.4750960.1330957726151.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Will Swiftshader be in FF too? On Monday, March 5, 2012, Benoit Jacob wrote: > Of course! You could just create a 320x240 canvas and stretch it with some CSS, I guess (I don't know anything about CSS but I expect that it works like that). If you want a pure-WebGL solution, you could render to a 320x240 texture attached to a framebuffer object and then render that to your real canvas. > > You won't have to go all the way down to 320x240 to get useful performance from a good software renderer. With simple enough shaders, and a decent CPU, 640x480 @ 60 FPS is doable. > > Benoit > > ________________________________ > > Is there a way to render 3d at something like 320x240 but then smooth stretch the image to something like 800x600? For no gpu systems on winxp we'll need to be able to watch frame rate and rein in the computational intensity accordingly. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Mar 5 10:39:14 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 5 Mar 2012 10:39:14 -0800 Subject: [Public WebGL] Added conformance test: bufferData on null data -> INVALID_VALUE In-Reply-To: References: <689548510.4457614.1330817626736.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1867176040.4457671.1330817813095.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Thanks for catching this and adding the test. Note that the current version of AMD's fglrx driver should work with Chromium without needing to ignore the GPU blacklist. If you find this to not be the case please let Mo and me know offline. -Ken On Sat, Mar 3, 2012 at 4:57 PM, Mo, Zhenyao wrote: > > In the about:flags, check ignore software rendering list > > > On Sat, Mar 3, 2012 at 3:36 PM, Benoit Jacob wrote: >> >> Hi, >> >> This is to let you know about r17021: this adds a new test to conformance/buffers/buffer-data-array-buffer.html, checking that bufferData on null data generates INVALID_VALUE, per the spec section 5.14.5. >> >> Thanks to Ms2ger for finding about this. >> >> Not adding this to 1.0.1 as that doesn't seem like a big emergency. >> >> Benoit >> >> PS: I wanted to test this on chromium on my Linux machine but I couldn't figure how to enable WebGL? I have Ubuntu 11.10 x86-64, Mesa 7.11, radeon driver. Anyway, per the discussion in Khronos bug 386, it seems that WebKit has been spec-compliant on this for a very long time. >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Mon Mar 5 12:05:11 2012 From: bja...@ (Benoit Jacob) Date: Mon, 5 Mar 2012 12:05:11 -0800 (PST) Subject: [Public WebGL] Re: Swiftshader/webgl In-Reply-To: Message-ID: <729594143.5172157.1330977911561.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Swiftshader is not, as far as I know, open source. Which is totally OK, but just means we can't use it in Firefox. For this reason we're currently looking at Mesa's LLVMpipe renderer. I've filed a mentored bug, as I think it can be a good first bug. It's still waiting for a volunteer: https://bugzilla.mozilla.org/show_bug.cgi?id=731836 The ultimate goal would be to automatically download it when needed, like (IIUC) Chrome does. Cheers, Benoit ----- Original Message ----- > Will Swiftshader be in FF too? > On Monday, March 5, 2012, Benoit Jacob < bjacob...@ > wrote: > > Of course! You could just create a 320x240 canvas and stretch it > > with some CSS, I guess (I don't know anything about CSS but I > > expect that it works like that). If you want a pure-WebGL > > solution, you could render to a 320x240 texture attached to a > > framebuffer object and then render that to your real canvas. > > > > You won't have to go all the way down to 320x240 to get useful > > performance from a good software renderer. With simple enough > > shaders, and a decent CPU, 640x480 @ 60 FPS is doable. > > > > Benoit > > > > ________________________________ > > > > Is there a way to render 3d at something like 320x240 but then > > smooth stretch the image to something like 800x600? For no gpu > > systems on winxp we'll need to be able to watch frame rate and > > rein in the computational intensity accordingly. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon Mar 5 12:45:05 2012 From: jda...@ (John Davis) Date: Mon, 5 Mar 2012 14:45:05 -0600 Subject: [Public WebGL] Re: Swiftshader/webgl In-Reply-To: <729594143.5172157.1330977911561.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <729594143.5172157.1330977911561.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: This sort of difference could put FF at a serious disadvantage. On Monday, March 5, 2012, Benoit Jacob wrote: > Swiftshader is not, as far as I know, open source. Which is totally OK, but just means we can't use it in Firefox. > > For this reason we're currently looking at Mesa's LLVMpipe renderer. I've filed a mentored bug, as I think it can be a good first bug. It's still waiting for a volunteer: > https://bugzilla.mozilla.org/show_bug.cgi?id=731836 > The ultimate goal would be to automatically download it when needed, like (IIUC) Chrome does. > > Cheers, > Benoit > > > ________________________________ > > Will Swiftshader be in FF too? > > On Monday, March 5, 2012, Benoit Jacob wrote: >> Of course! You could just create a 320x240 canvas and stretch it with some CSS, I guess (I don't know anything about CSS but I expect that it works like that). If you want a pure-WebGL solution, you could render to a 320x240 texture attached to a framebuffer object and then render that to your real canvas. >> >> You won't have to go all the way down to 320x240 to get useful performance from a good software renderer. With simple enough shaders, and a decent CPU, 640x480 @ 60 FPS is doable. >> >> Benoit >> >> ________________________________ >> >> Is there a way to render 3d at something like 320x240 but then smooth stretch the image to something like 800x600? For no gpu systems on winxp we'll need to be able to watch frame rate and rein in the computational intensity accordingly. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Mon Mar 5 17:14:45 2012 From: cvi...@ (Cedric Vivier) Date: Tue, 6 Mar 2012 09:14:45 +0800 Subject: [Public WebGL] Re: Swiftshader/webgl In-Reply-To: References: <729594143.5172157.1330977911561.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 6, 2012 at 04:45, John Davis wrote: > This sort of difference could put FF at a serious disadvantage. Do you have any data on how current LLVMpipe performs compared to SwiftShader? Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ash...@ Mon Mar 5 17:50:00 2012 From: ash...@ (Ashley Gullen) Date: Tue, 6 Mar 2012 01:50:00 +0000 Subject: [Public WebGL] Blacklisted driver notification Message-ID: Firefox and Chrome implement driver blacklists for WebGL to prevent buggy drivers crashing the user's computer. I've read this is almost exclusively due to the drivers being out of date, so the user updating their drivers ought to fix the problem. More recently, I've read about Google and Mozilla making moves to add software-rendered WebGL implementations so users who have blacklisted drivers can still see content. For real-time games, software renderers really don't make for a good playing experience on the common mid to low end machine. Poor performance is one of the most common criticisms we've heard with our HTML5 game engine, and it only comes from users who get software rendering. Some combinations of game and machine result in unplayable performance. Often if we get the user to update their driver then the GPU gets used and the game runs excellently. It's frustrating that the player may have a bad experience when they actually have the necessary hardware to run the game really well, but just lack a decent up-to-date driver. While software rendering is one way to solve the problem, it seems to me that it's worth trying to solve it by getting users to update their drivers. This is more complicated for the user, but has a better end result. Browsers could prompt users to upgrade their driver when it's blacklisted, but it may be unnecessary depending on the content. There's no good way for the content itself to detect software rendering (and apparently the term is vague, since some GPUs use part software processing). However, if the fact that the user's graphics driver is on the browser's blacklist is exposed to the content (a simple flag), the content itself can issue some kind of notification if appropriate. This does not involve exposing any hardware details, does not need to determine a definition for software rendering, does not require running performance tests to try to detect software rendering, and could result in a much better end-user experience since they end up using the GPU they paid for. Is this something that might be suitable for the WebGL spec? Ashley Gullen Scirra.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndu...@ Mon Mar 5 18:03:34 2012 From: ndu...@ (Nat Duca) Date: Mon, 5 Mar 2012 18:03:34 -0800 Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: References: Message-ID: It seems to me that thing you desire is not whether they are using software per-se, but whether there is any actionable item the end user can perform to improve the performance. Consider for instance the user having a nice USB-to-DVI converter plugged in and active to get a second monitor. That will cause perf to tank, too. You'll get bad microbenchmarks and we might even fall back to software rendering. - Nat On Mon, Mar 5, 2012 at 5:50 PM, Ashley Gullen wrote: > Firefox and Chrome implement driver blacklists for WebGL to prevent buggy > drivers crashing the user's computer. I've read this is almost exclusively > due to the drivers being out of date, so the user updating their drivers > ought to fix the problem. More recently, I've read about Google and > Mozilla making moves to add software-rendered WebGL implementations so > users who have blacklisted drivers can still see content. > > For real-time games, software renderers really don't make for a good > playing experience on the common mid to low end machine. Poor performance > is one of the most common criticisms we've heard with our HTML5 game > engine, and it only comes from users who get software rendering. Some > combinations of game and machine result in unplayable performance. Often > if we get the user to update their driver then the GPU gets used and the > game runs excellently. It's frustrating that the player may have a bad > experience when they actually have the necessary hardware to run the game > really well, but just lack a decent up-to-date driver. > > While software rendering is one way to solve the problem, it seems to me > that it's worth trying to solve it by getting users to update their > drivers. This is more complicated for the user, but has a better end > result. Browsers could prompt users to upgrade their driver when it's > blacklisted, but it may be unnecessary depending on the content. There's > no good way for the content itself to detect software rendering (and > apparently the term is vague, since some GPUs use part software > processing). However, if the fact that the user's graphics driver is on > the browser's blacklist is exposed to the content (a simple flag), the > content itself can issue some kind of notification if appropriate. This > does not involve exposing any hardware details, does not need to determine > a definition for software rendering, does not require running performance > tests to try to detect software rendering, and could result in a much > better end-user experience since they end up using the GPU they paid for. > > Is this something that might be suitable for the WebGL spec? > > Ashley Gullen > Scirra.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Mon Mar 5 18:12:48 2012 From: ben...@ (Ben Vanik) Date: Mon, 5 Mar 2012 18:12:48 -0800 Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: References: Message-ID: I'd really like to see the browsers take care of prompting the user to update their drivers instead of making pages handle it. That takes care of any entropy bit issues (whether your drivers are out of date or not is potentially one more bit that can be used to identify you), simplifies things for people trying to build robust apps (one less case to handle/write copy for/translate/etc), and a browser can more intelligently direct users based on platform/vendor/etc, which are not reliably accessible to user pages. Steam does this for known bad drivers today, and it'd be a great service if the browsers did it (especially as more start to rely on GPU acceleration for their internals). This prompting for upgrade of drivers is orthogonal to the software renderer, though. The user could of course deny any attempt the browser's make at upgrading, may be running on a pure software device (such as a remote desktop session), or may be unable to upgrade (no administrator access, no new non-blacklisted drivers available, etc) - in cases such as these the potential to run while blacklisted still exists. In some cases, the browser may not even be aware it is running in software - such as if the user is running on a device where the 'GPU' is emulated via mesa or some equivalent. For this, my instinct would be to add a context creation attribute that specifies that no software fallback should be used. One still needs benchmarks/etc to know whether their performance would be acceptable, though, which diminishes the value. It'd make it easier to quickly block out all those who would certainly be too slow to run an app, however there are many old GPUs out there that would perform just as poorly and an end user still doesn't get a great experience. Users really need to be split into two categories: those who can run a piece of software (but be prevented due to driver issues/etc), and those who can't. Unfortunately where the dividing line lies is different for every application. I think one thing we can push for is better support in the former case of blacklisted drivers for users who can run an app but are prevented by correctable issues - with better presentation by the browser to users as to why they are blacklisted and potential courses of action. This is something that could be made better today in all browsers without any changes to the spec - although asynchronous context creation could allow for an experience where users get to opt-in to software mode or unsafe drivers. I don't currently see a bug in Chrome for this - maybe you could file one :) http://crbug.com On Mon, Mar 5, 2012 at 5:50 PM, Ashley Gullen wrote: > Firefox and Chrome implement driver blacklists for WebGL to prevent buggy > drivers crashing the user's computer. I've read this is almost exclusively > due to the drivers being out of date, so the user updating their drivers > ought to fix the problem. More recently, I've read about Google and > Mozilla making moves to add software-rendered WebGL implementations so > users who have blacklisted drivers can still see content. > > For real-time games, software renderers really don't make for a good > playing experience on the common mid to low end machine. Poor performance > is one of the most common criticisms we've heard with our HTML5 game > engine, and it only comes from users who get software rendering. Some > combinations of game and machine result in unplayable performance. Often > if we get the user to update their driver then the GPU gets used and the > game runs excellently. It's frustrating that the player may have a bad > experience when they actually have the necessary hardware to run the game > really well, but just lack a decent up-to-date driver. > > While software rendering is one way to solve the problem, it seems to me > that it's worth trying to solve it by getting users to update their > drivers. This is more complicated for the user, but has a better end > result. Browsers could prompt users to upgrade their driver when it's > blacklisted, but it may be unnecessary depending on the content. There's > no good way for the content itself to detect software rendering (and > apparently the term is vague, since some GPUs use part software > processing). However, if the fact that the user's graphics driver is on > the browser's blacklist is exposed to the content (a simple flag), the > content itself can issue some kind of notification if appropriate. This > does not involve exposing any hardware details, does not need to determine > a definition for software rendering, does not require running performance > tests to try to detect software rendering, and could result in a much > better end-user experience since they end up using the GPU they paid for. > > Is this something that might be suitable for the WebGL spec? > > Ashley Gullen > Scirra.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Mar 5 18:22:54 2012 From: bja...@ (Benoit Jacob) Date: Mon, 5 Mar 2012 18:22:54 -0800 (PST) Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: Message-ID: <783319616.5503917.1331000574188.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> For a long time, there have been ideas floating in the air about exposing some kind of performance metrics to content. I used to regard this as a relatively low priority, but I have to agree that with the advent of software rendering fallbacks, this is becoming a much higher priority: indeed, if you take an app that defaults to WebGL and has a non-WebGL fallback (examples: Angry Birds, Google MapsGL), it is conceivable that the non-WebGL fallback will often be preferrable over doing WebGL with a software renderer. I could live with a one-bit "this is a software renderer" flag, but reluctantly. Indeed, "this is a software renderer" is hard to define in a future-proof way, and masks a reality of hw-accelerated implementations that have slow software fallbacks for certain tasks, which is a problem for real WebGL applications today. So, if possible, I would rather have some rough performance metrics, as has been discussed recently. Something like Windows' Experience Index (as Ken proposed recently), but that we would design ourselves so we could control it and make sure it can be implemented consistently across browsers, OSes, etc. Like WEI, we should try to strike a balance between too few metrics and too many. I think that somewhere between 2 and 4 scalar metrics should be the right compromise. How about 3 metrics, roughly doing the following, rendering to a framebuffer of the resolution of the client device's display: 1. performance with a typical simple vertex shader + simple fragment shader 2. performance with a complex vertex shader with vertex shader texture access + simple fragment shader 3. performance with a simple vertex shader + complex fragment shader The browser could cache benchmark results and invalidate them when something important changes (e.g. a driver update). Regarding your other question about encouraging the user to update drivers: I'd let the application do that if they really want to. The typical Firefox user either doesn't know what a driver is, or doesn't want to be bothered about it, or wouldn't know how to do it, or can't anyway because their OEM locked down driver updates. The application might know more about the user than we do, e.g. a hardcore 3D shooter game might be able to assume that its users care about graphics drivers. What we should do to help, is implement the webglcontextcreationerror event --- I feel bad that we still haven't done it. Cheers, Benoit ----- Original Message ----- > Firefox and Chrome implement driver blacklists for WebGL to prevent > buggy drivers crashing the user's computer. I've read this is almost > exclusively due to the drivers being out of date, so the user > updating their drivers ought to fix the problem. More recently, I've > read about Google and Mozilla making moves to add software-rendered > WebGL implementations so users who have blacklisted drivers can > still see content. > For real-time games, software renderers really don't make for a good > playing experience on the common mid to low end machine. Poor > performance is one of the most common criticisms we've heard with > our HTML5 game engine, and it only comes from users who get software > rendering. Some combinations of game and machine result in > unplayable performance. Often if we get the user to update their > driver then the GPU gets used and the game runs excellently. It's > frustrating that the player may have a bad experience when they > actually have the necessary hardware to run the game really well, > but just lack a decent up-to-date driver. > While software rendering is one way to solve the problem, it seems to > me that it's worth trying to solve it by getting users to update > their drivers. This is more complicated for the user, but has a > better end result. Browsers could prompt users to upgrade their > driver when it's blacklisted, but it may be unnecessary depending on > the content. There's no good way for the content itself to detect > software rendering (and apparently the term is vague, since some > GPUs use part software processing). However, if the fact that the > user's graphics driver is on the browser's blacklist is exposed to > the content (a simple flag), the content itself can issue some kind > of notification if appropriate. This does not involve exposing any > hardware details, does not need to determine a definition for > software rendering, does not require running performance tests to > try to detect software rendering, and could result in a much better > end-user experience since they end up using the GPU they paid for. > Is this something that might be suitable for the WebGL spec? > Ashley Gullen > Scirra.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Mar 5 18:39:03 2012 From: bja...@ (Benoit Jacob) Date: Mon, 5 Mar 2012 18:39:03 -0800 (PST) Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: <6022ec25541c74da64bd7cd228e36836.squirrel@webmail.sjbaker.org> Message-ID: <245326988.5507969.1331001543430.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > If we're going to have flags then at the very least, there should be > two > flags - not one: > > * This machine uses a software fallback for Vertex shaders. > * This machine uses a software fallback for Fragment shaders. > > ...because I care differently about whether vertex performance is > fast or > fragment performance is fast depending on the application - and in > some > cases I can use less geometry and still salvage some kind of > performance > when the vertex shader uses software - or I can use a smaller window > and > eliminate post-effects, per fragment lighting and other fancy glitz > if > there is no fragment shader hardware. I agree, and this is why, in the 'performance metrics' discussion, I've been advocating in favor of separate metrics for vertex-shader-intensive and fragment-shader-intensive draw operations. See my previous email. Benoit > > -- Steve > > > Benoit Jacob wrote: > > For a long time, there have been ideas floating in the air about > > exposing > > some kind of performance metrics to content. I used to regard this > > as a > > relatively low priority, but I have to agree that with the advent > > of > > software rendering fallbacks, this is becoming a much higher > > priority: > > indeed, if you take an app that defaults to WebGL and has a > > non-WebGL > > fallback (examples: Angry Birds, Google MapsGL), it is conceivable > > that > > the non-WebGL fallback will often be preferrable over doing WebGL > > with a > > software renderer. > > > > I could live with a one-bit "this is a software renderer" flag, but > > reluctantly. Indeed, "this is a software renderer" is hard to > > define in a > > future-proof way, and masks a reality of hw-accelerated > > implementations > > that have slow software fallbacks for certain tasks, which is a > > problem > > for real WebGL applications today. > > > > So, if possible, I would rather have some rough performance > > metrics, as > > has been discussed recently. Something like Windows' Experience > > Index (as > > Ken proposed recently), but that we would design ourselves so we > > could > > control it and make sure it can be implemented consistently across > > browsers, OSes, etc. Like WEI, we should try to strike a balance > > between > > too few metrics and too many. I think that somewhere between 2 and > > 4 > > scalar metrics should be the right compromise. How about 3 metrics, > > roughly doing the following, rendering to a framebuffer of the > > resolution > > of the client device's display: > > 1. performance with a typical simple vertex shader + simple > > fragment > > shader > > 2. performance with a complex vertex shader with vertex shader > > texture > > access + simple fragment shader > > 3. performance with a simple vertex shader + complex fragment > > shader > > The browser could cache benchmark results and invalidate them when > > something important changes (e.g. a driver update). > > > > Regarding your other question about encouraging the user to update > > drivers: I'd let the application do that if they really want to. > > The > > typical Firefox user either doesn't know what a driver is, or > > doesn't want > > to be bothered about it, or wouldn't know how to do it, or can't > > anyway > > because their OEM locked down driver updates. The application might > > know > > more about the user than we do, e.g. a hardcore 3D shooter game > > might be > > able to assume that its users care about graphics drivers. What we > > should > > do to help, is implement the webglcontextcreationerror event --- I > > feel > > bad that we still haven't done it. > > > > Cheers, > > Benoit > > > > ----- Original Message ----- > > > >> Firefox and Chrome implement driver blacklists for WebGL to > >> prevent > >> buggy drivers crashing the user's computer. I've read this is > >> almost > >> exclusively due to the drivers being out of date, so the user > >> updating their drivers ought to fix the problem. More recently, > >> I've > >> read about Google and Mozilla making moves to add > >> software-rendered > >> WebGL implementations so users who have blacklisted drivers can > >> still see content. > > > >> For real-time games, software renderers really don't make for a > >> good > >> playing experience on the common mid to low end machine. Poor > >> performance is one of the most common criticisms we've heard with > >> our HTML5 game engine, and it only comes from users who get > >> software > >> rendering. Some combinations of game and machine result in > >> unplayable performance. Often if we get the user to update their > >> driver then the GPU gets used and the game runs excellently. It's > >> frustrating that the player may have a bad experience when they > >> actually have the necessary hardware to run the game really well, > >> but just lack a decent up-to-date driver. > > > >> While software rendering is one way to solve the problem, it seems > >> to > >> me that it's worth trying to solve it by getting users to update > >> their drivers. This is more complicated for the user, but has a > >> better end result. Browsers could prompt users to upgrade their > >> driver when it's blacklisted, but it may be unnecessary depending > >> on > >> the content. There's no good way for the content itself to detect > >> software rendering (and apparently the term is vague, since some > >> GPUs use part software processing). However, if the fact that the > >> user's graphics driver is on the browser's blacklist is exposed to > >> the content (a simple flag), the content itself can issue some > >> kind > >> of notification if appropriate. This does not involve exposing any > >> hardware details, does not need to determine a definition for > >> software rendering, does not require running performance tests to > >> try to detect software rendering, and could result in a much > >> better > >> end-user experience since they end up using the GPU they paid for. > > > >> Is this something that might be suitable for the WebGL spec? > > > >> Ashley Gullen > >> Scirra.com > > > -- Steve > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Mon Mar 5 19:42:31 2012 From: gle...@ (Glenn Maynard) Date: Mon, 5 Mar 2012 21:42:31 -0600 Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: <783319616.5503917.1331000574188.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <783319616.5503917.1331000574188.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Mon, Mar 5, 2012 at 8:22 PM, Benoit Jacob wrote: > Regarding your other question about encouraging the user to update > drivers: I'd let the application do that if they really want to. The > typical Firefox user either doesn't know what a driver is, or doesn't want > to be bothered about it, or wouldn't know how to do it, or can't anyway > because their OEM locked down driver updates. The application might know > more about the user than we do, e.g. a hardcore 3D shooter game might be > able to assume that its users care about graphics drivers. What we should > do to help, is implement the webglcontextcreationerror event --- I feel bad > that we still haven't done it. > It may or may not make sense for browsers to make driver recommendations, but it doesn't make sense at all for individual WebGL apps to do this. It's possible that individual browsers might be kept up to date, as new hardware and drivers are released and tested. If individual apps are doing it, it's guaranteed that most of them will be either out of date or wrong. They also don't have the information needed to implement it, such as GPU hardware IDs and driver versions. I think it also makes sense that the people maintaining the driver blacklists maintain the driver upgrade table, since they're closely tied. The two-state result--"blacklisted" vs. "not blacklisted"--becomes a three-state field: "blacklisted, but there isn't a working driver yet (so don't ask the user to upgrade)", "blacklisted, and a newer working driver is available", and "working". When a new version of a blacklisted driver is removed from the blacklist because it's been fixed, the entries for the old versions are switched from the first to the second state. I doubt the "knows more about the user" is meaningful. If I implement a casual 3d game and the user's drivers are out of date, what do I do? The user is likely not "hardcore" user, but I'd absolutely still want the user to be asked to upgrade his drivers, if the alternative is that my product doesn't work and the user leaves. If you give us app developers the choice of whether to ask the user to upgrade drivers or go away, we're *always* going to ask the user to upgrade. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Mar 5 19:50:10 2012 From: bja...@ (Benoit Jacob) Date: Mon, 5 Mar 2012 19:50:10 -0800 (PST) Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: Message-ID: <275023427.5519062.1331005810852.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Mon, Mar 5, 2012 at 8:22 PM, Benoit Jacob < bjacob...@ > > wrote: > > Regarding your other question about encouraging the user to update > > drivers: I'd let the application do that if they really want to. > > The > > typical Firefox user either doesn't know what a driver is, or > > doesn't want to be bothered about it, or wouldn't know how to do > > it, > > or can't anyway because their OEM locked down driver updates. The > > application might know more about the user than we do, e.g. a > > hardcore 3D shooter game might be able to assume that its users > > care > > about graphics drivers. What we should do to help, is implement the > > webglcontextcreationerror event --- I feel bad that we still > > haven't > > done it. > > It may or may not make sense for browsers to make driver > recommendations, but it doesn't make sense at all for individual > WebGL apps to do this. In fact, the application and the browser know different pieces of information: - the browser knows the system details - the application knows when it's appropriate to make a driver update suggestion [2] [2]: note that another reason why it is very hard for the browser to know when to make a driver update suggestion, is that many apps prefer to silently fall back to a non-WebGL version and would regard a browser dialog about drivers as disrupting their user experience. So maybe (this is a pie-in-the-sky proposal) the browser could offer an API to make the driver update suggestion, but the application would have to manually trigger it. Benoit (PS. is my font size OK this time?) > It's possible that individual browsers might be kept up to date, as > new hardware and drivers are released and tested. If individual apps > are doing it, it's guaranteed that most of them will be either out > of date or wrong. They also don't have the information needed to > implement it, such as GPU hardware IDs and driver versions. > I think it also makes sense that the people maintaining the driver > blacklists maintain the driver upgrade table, since they're closely > tied. The two-state result--"blacklisted" vs. "not > blacklisted"--becomes a three-state field: "blacklisted, but there > isn't a working driver yet (so don't ask the user to upgrade)", > "blacklisted, and a newer working driver is available", and > "working". When a new version of a blacklisted driver is removed > from the blacklist because it's been fixed, the entries for the old > versions are switched from the first to the second state. > I doubt the "knows more about the user" is meaningful. If I implement > a casual 3d game and the user's drivers are out of date, what do I > do? The user is likely not "hardcore" user, but I'd absolutely still > want the user to be asked to upgrade his drivers, if the alternative > is that my product doesn't work and the user leaves. If you give us > app developers the choice of whether to ask the user to upgrade > drivers or go away, we're *always* going to ask the user to upgrade. > -- > Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Mon Mar 5 20:00:20 2012 From: gle...@ (Glenn Maynard) Date: Mon, 5 Mar 2012 22:00:20 -0600 Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: <275023427.5519062.1331005810852.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <275023427.5519062.1331005810852.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Mon, Mar 5, 2012 at 9:50 PM, Benoit Jacob wrote: > In fact, the application and the browser know different pieces of > information: > - the browser knows the system details > - the application knows when it's appropriate to make a driver update > suggestion [2] > > [2]: note that another reason why it is very hard for the browser to know > when to make a driver update suggestion, is that many apps prefer to > silently fall back to a non-WebGL version and would regard a browser dialog > about drivers as disrupting their user experience. > > So maybe (this is a pie-in-the-sky proposal) the browser could offer an > API to make the driver update suggestion, but the application would have to > manually trigger it. > Or, simply a flag during context creation. I'd frame it in terms of "I have my own fallback (or this is an optimization that I can simply turn off), so I don't want the browser popping up and asking the user to upgrade drivers", not as "I think the user is advanced enough that he wants to see driver upgrade notices", though. Prompting would want to be the default, with the flag saying "don't prompt for upgrades", not the other way around. I'm pretty sure that's the right thing most of the time. Most people don't have a Flash reimplementation to use as a fallback, and if you *are* writing a fallback path, then you're probably testing that path (so you'd see the prompt and find the flag to disable it). (PS. is my font size OK this time?) > It's still fairly large. Do you have a "remove all formatting" option (like the "Tx" in Gmail)? -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Mar 5 20:08:32 2012 From: bja...@ (Benoit Jacob) Date: Mon, 5 Mar 2012 20:08:32 -0800 (PST) Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: Message-ID: <1872847945.5520644.1331006912672.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Mon, Mar 5, 2012 at 9:50 PM, Benoit Jacob < bjacob...@ > > wrote: > > So maybe (this is a pie-in-the-sky proposal) the browser could > > offer > > an API to make the driver update suggestion, but the application > > would have to manually trigger it. > > Or, simply a flag during context creation. Totally agree, I was thinking the same. > > (PS. is my font size OK this time?) > > It's still fairly large. Do you have a "remove all formatting" option > (like the "Tx" in Gmail)? I'm using Zimbra and while it's configured to compose in plain text by default, it's bad at converting existing HTML conversation to plain text. In Zimbra, all the text is now "10pt" and mine looks much smaller than yours! Even if I use the same font as you. I'll call it a Zimbra bug and switch back to Thunderbird. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Mar 5 21:18:34 2012 From: cal...@ (Mark Callow) Date: Mon, 05 Mar 2012 21:18:34 -0800 Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: References: <275023427.5519062.1331005810852.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F559E2A.5030708@hicorp.co.jp> On 12/03/05 20:00, Glenn Maynard wrote: > > (PS. is my font size OK this time?) > > > It's still fairly large. Do you have a "remove all formatting" option > (like the "Tx" in Gmail)? It's tiny for me, about 8 point. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 6 01:42:53 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 6 Mar 2012 10:42:53 +0100 Subject: [Public WebGL] Blacklisted driver notification In-Reply-To: <4F559E2A.5030708@hicorp.co.jp> References: <275023427.5519062.1331005810852.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F559E2A.5030708@hicorp.co.jp> Message-ID: I think that the notification about driver updates should stem from the browser (and not the individual application). - It's the browsers business white/black listing drivers - A common user experience that can be optimized to the benefit of everybody - The driver update advise can be made much more specific and helpful then a webapp using a single flag ever could. There are some concerns that need to be addressed: - Not leaking out more identifyable bits for supercookies - Not annoying the user with driver update dialogs all over This leads to a relatively simple mechanism which consists of two parts: Polling for driver update: #1 A web-application can poll the browser to display a driver update dialog to the user, perhaps something like: pollDriverUpdate() #2 The user can decide to say "no", and he can decide to persist that choice (like for saving passwords) or change it in the settings. so pollDriverUpdate() may return false without any dialog being shown. Calling the pollDriverUpdate() function without any driver being outdated, equally no dialog is shown and false is returned. #3 If the poll to a driver update is accepted by the user, an appropriate and well curated help dialog will guide them trough the process as smoothly as possible using the available operating system, vendor and GPU information. Figuring out weather to do polling: - An application may decide by itself that performance is too slow (by any number of internal measurements) and call the pollDriverUpdate() function. - An application may request a performance profile with the conditional that if the driver is outdated and if the performance profile is not fulfilled, the poll dialog mechanism kicks in. This could look like: pollDriverUpdateIfLess({shaderPerformance: 4.0}) which may return false for any of the described reasons a pollDriverUpdate() would. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Tue Mar 6 03:53:57 2012 From: jda...@ (John Davis) Date: Tue, 6 Mar 2012 05:53:57 -0600 Subject: [Public WebGL] Re: Swiftshader/webgl In-Reply-To: References: <729594143.5172157.1330977911561.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: No, I do not. But if implementation hasn't even started yet, FF is way behind chrome in this respect. On Monday, March 5, 2012, Cedric Vivier wrote: > > On Tue, Mar 6, 2012 at 04:45, John Davis wrote: >> This sort of difference could put FF at a serious disadvantage. > > Do you have any data on how current LLVMpipe performs compared to SwiftShader? > > Regards, > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jba...@ Tue Mar 6 13:39:36 2012 From: jba...@ (John Bauman) Date: Tue, 6 Mar 2012 13:39:36 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal Message-ID: I've just added a proposal for adding ANGLE_instanced_arrays to WebGL to allow geometry instancing: http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_instanced_arrays/ This extension is a stripped-down version of ARB_instanced_arrays that can be easily-implemented on top of Direct3D 9. It can be used by setting a divisor, n, on certain vertex attribs. Then when drawing multiple instances of a certain piece of geometry, those vertex attributes will keep the same value for every vertex in an entire instance. After drawing n instances, it will move on to the next value for that attrib. Desktop support: - All Direct3D 9 hardware with Shader Model 3.0 supports it - Supported through ANGLE on windows. - Supported on OS X Lion on all machines, and on Snow Leopard on most machines - Supported on NVIDIA's linux drivers, and probably ATI's Mobile support: This is more difficult, as no mobile device that I know of supports geometry instancing. This could be supported using pseudo-instancing, but that would require either keeping a shadow copy of every vertex buffer in case it's used as instanced data, or performing a complicated and expensive readback to get at that data. Does this seem like a worthwhile extension to people? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Mar 6 13:48:50 2012 From: bja...@ (Benoit Jacob) Date: Tue, 6 Mar 2012 13:48:50 -0800 (PST) Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: Message-ID: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> It does sound like a potentially worthwhile idea, but it would be great to see data about how large the performance increase can be. I checked, Mesa supports it. (Open-source Linux drivers). Benoit ----- Original Message ----- > I've just added a proposal for adding ANGLE_instanced_arrays to WebGL > to allow geometry instancing: > http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_instanced_arrays/ > This extension is a stripped-down version of ARB_instanced_arrays > that can be easily-implemented on top of Direct3D 9. > It can be used by setting a divisor, n, on certain vertex attribs. > Then when drawing multiple instances of a certain piece of geometry, > those vertex attributes will keep the same value for every vertex in > an entire instance. After drawing n instances, it will move on to > the next value for that attrib. > Desktop support: > - All Direct3D 9 hardware with Shader Model 3.0 supports it > - Supported through ANGLE on windows. > - Supported on OS X Lion on all machines, and on Snow Leopard on most > machines > - Supported on NVIDIA's linux drivers, and probably ATI's > Mobile support: > This is more difficult, as no mobile device that I know of supports > geometry instancing. This could be supported using > pseudo-instancing, but that would require either keeping a shadow > copy of every vertex buffer in case it's used as instanced data, or > performing a complicated and expensive readback to get at that data. > Does this seem like a worthwhile extension to people? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Tue Mar 6 13:53:28 2012 From: ben...@ (Ben Vanik) Date: Tue, 6 Mar 2012 13:53:28 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: I would love to see this, even if it is not supported on mobile. I often find instancing good when performing a lot of dynamic buffer uploads, as you can dramatically reduce the size of your buffers (and the data you have to upload) - even if it's a wash (or maybe even slightly slower) on vertex throughput, the ability to /3 or /4 (or more) my data is a big win in a lot of cases. There's less JS code running to generate the data, less memory usage, and in browsers that require copies to background processes/etc it can save on command buffer space. One can't look at just # of vertices/second to see if it's useful. With WebGL it should help with API overhead, too - reducing the number of uniform/draw pairings and transitions to native code. Whether that's worth trying to find fallback solutions in software for is debatable. I'd say that a good test would be needed to see, on platforms that don't support it natively, if it's worth doing the software expansion. Again, if it's within a reasonable amount of performance via the non-instanced case but a little slower, it can still be worth it for the memory/buffer savings client-side. On Tue, Mar 6, 2012 at 1:48 PM, Benoit Jacob wrote: > It does sound like a potentially worthwhile idea, but it would be great to > see data about how large the performance increase can be. > > I checked, Mesa supports it. (Open-source Linux drivers). > > Benoit > > ------------------------------ > > I've just added a proposal for adding ANGLE_instanced_arrays to WebGL to > allow geometry instancing: > > http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_instanced_arrays/ > > This extension is a stripped-down version of ARB_instanced_arrays that can > be easily-implemented on top of Direct3D 9. > > It can be used by setting a divisor, n, on certain vertex attribs. Then > when drawing multiple instances of a certain piece of geometry, those > vertex attributes will keep the same value for every vertex in an entire > instance. After drawing n instances, it will move on to the next value for > that attrib. > > > Desktop support: > - All Direct3D 9 hardware with Shader Model 3.0 supports it > - Supported through ANGLE on windows. > - Supported on OS X Lion on all machines, and on Snow Leopard on most > machines > - Supported on NVIDIA's linux drivers, and probably ATI's > > Mobile support: > This is more difficult, as no mobile device that I know of supports > geometry instancing. This could be supported using pseudo-instancing, but > that would require either keeping a shadow copy of every vertex buffer in > case it's used as instanced data, or performing a complicated and expensive > readback to get at that data. > > Does this seem like a worthwhile extension to people? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 6 14:47:21 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 6 Mar 2012 23:47:21 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: I'd like to see this, and I do think it'd be particularly well suited to mobiles where there is generally less performance. One usecase I frequently miss (as well in any ARB extension) is to be able to draw the same vertex data repeatedly (without having to repeat the buffer). It seems to me the performance benefit would be substantial (but that's just a guess) because repeatedly accessing the same vertex data would make extremely good cache use as opposed to advancing trough a big buffer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cda...@ Tue Mar 6 14:53:14 2012 From: cda...@ (Chris Dalton) Date: Tue, 6 Mar 2012 15:53:14 -0700 Subject: [Public WebGL] A new, complete WebGL game Message-ID: <4F56955A.9030802@nvidia.com> I just ported an old OpenGL ES 1.0 game to WebGL and thought I'd share with the group: http://shatterquest.com/ The sound, graphics, and everything are all HTML5. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Mar 6 14:57:33 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 6 Mar 2012 14:57:33 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 6, 2012 at 2:47 PM, Florian B?sch wrote: > I'd like to see this, and I do think it'd be particularly well suited to > mobiles where there is generally less performance. One usecase I frequently > miss (as well in any ARB extension) is to be able to draw the same vertex > data repeatedly (without having to repeat the buffer). It seems to me the > performance benefit would be substantial (but that's just a guess) because > repeatedly accessing the same vertex data would make extremely good cache > use as opposed to advancing trough a big buffer. As John points out, current mobile hardware does not support this functionality natively. In order to support this extension it would be necessary to either shadow all vertex buffers (impractical due to the high memory cost) or use OES_map_buffer to read back vertex data and generate new vertex buffers on the fly for the instanced vertex attributes. Does that change your thinking at all? I think this extension would be a good idea, but that we should first implement the core functionality planned for the next WebGL release and finish off the current crop of draft extensions. Performance measurements of prototypes of this extension would definitely motivate it. Maybe it would be worth moving it to draft status and planning on leaving it there for a while. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Mar 6 15:05:25 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 6 Mar 2012 15:05:25 -0800 Subject: [Public WebGL] A new, complete WebGL game In-Reply-To: <4F56955A.9030802@nvidia.com> References: <4F56955A.9030802@nvidia.com> Message-ID: On Tue, Mar 6, 2012 at 2:53 PM, Chris Dalton wrote: > I just ported an old OpenGL ES 1.0 game to WebGL and thought I'd share with > the group: > > http://shatterquest.com/ > > The sound, graphics, and everything are all HTML5. Nifty. Consider adding it to http://www.khronos.org/webgl/wiki/User_Contributions and with the WebGL Developers' List. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 6 15:19:44 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 7 Mar 2012 00:19:44 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 6, 2012 at 11:57 PM, Kenneth Russell wrote: > Does that change your thinking at all? > Not at all. Well I agree that mobile support is lacking. But that's besides the point (others will doubtlessly make this a big point without my help). No, draw instanced (like any extension that increases performance) is particularly well suited to weak devices. Sure, high end devices will benefit as well. But relatively, very weak devices will benefit a lot. So sure, at the moment it's not implemented by mobiles. But draw instanced doesn't strike me as particularly hard to support (after all it's simply a few additional bits of logic in how pointers are advanced), most mobile GPUs probably already support this in hardware, the driver just doesn't expose it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From won...@ Tue Mar 6 15:27:46 2012 From: won...@ (Won Chun) Date: Tue, 6 Mar 2012 18:27:46 -0500 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 6, 2012 at 6:19 PM, Florian B?sch wrote: > On Tue, Mar 6, 2012 at 11:57 PM, Kenneth Russell wrote: > >> Does that change your thinking at all? >> > Not at all. Well I agree that mobile support is lacking. But that's > besides the point (others will doubtlessly make this a big point without my > help). No, draw instanced (like any extension that increases performance) > is particularly well suited to weak devices. Sure, high end devices will > benefit as well. But relatively, very weak devices will benefit a lot. So > sure, at the moment it's not implemented by mobiles. But draw instanced > doesn't strike me as particularly hard to support (after all it's simply a > few additional bits of logic in how pointers are advanced), most mobile > GPUs probably already support this in hardware, the driver just doesn't > expose it. > Even if the driver didn't support it, I would guess that you could implement this extension using native pseudo-instancing, which could be substantially faster than JS/WebGL pseudo instancing on slower CPUs. -Won -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 6 15:48:38 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 7 Mar 2012 00:48:38 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 12:27 AM, Won Chun wrote: > Even if the driver didn't support it, I would guess that you could > implement this extension using native pseudo-instancing, which could be > substantially faster than JS/WebGL pseudo instancing on slower CPUs. > I do think this is a worthwhile idea to pursue. If the contents of the buffer that's bound to an attribute unit is known at the time of drawing, then the divisor on that attribute could be used to fill a bigger buffer with that attribute and substitute the binding with that one. One would have to: - intercept buffer binds, just to get a reference for the currently bound buffer - intercept buffer data calls and memcpy a buffer to a "shadow", this avoids having to readback, mark buffer as dirty - intercept attrib pointer calls, just records the specification and location, mark buffer as dirty - intercept divisor setting, just records the specification, mark buffer as dirty - at the time of calling draw if: buffers are clean, nothing to do, call draw else: analyze settings, compute appropriate (replicated attributes) buffers, mark as clean, call draw. I think this could even be shunted to software entirely in JS, and a bit more efficiently with native code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jba...@ Tue Mar 6 15:57:39 2012 From: jba...@ (John Bauman) Date: Tue, 6 Mar 2012 15:57:39 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 6, 2012 at 2:57 PM, Kenneth Russell wrote: > On Tue, Mar 6, 2012 at 2:47 PM, Florian B?sch wrote: > > I'd like to see this, and I do think it'd be particularly well suited to > > mobiles where there is generally less performance. One usecase I > frequently > > miss (as well in any ARB extension) is to be able to draw the same vertex > > data repeatedly (without having to repeat the buffer). It seems to me the > > performance benefit would be substantial (but that's just a guess) > because > > repeatedly accessing the same vertex data would make extremely good cache > > use as opposed to advancing trough a big buffer. > > As John points out, current mobile hardware does not support this > functionality natively. In order to support this extension it would be > necessary to either shadow all vertex buffers (impractical due to the > high memory cost) or use OES_map_buffer to read back vertex data and > generate new vertex buffers on the fly for the instanced vertex > attributes. > Unfortunately OES_mapbuffer doesn't allow reading from a vertex buffer (if you want to be spec-compliant), so you'll have to do crazy things like create a special vertex buffer and set of shaders, and do a draw that dumps out the vertex buffer to an FBO, which you could then do a readback from. If you want you could do that only on the first instanced draw from a buffer, and keep a shadow copy afterwards, but it might be difficult to make that perform well. > > Does that change your thinking at all? I think this extension would be > a good idea, but that we should first implement the core functionality > planned for the next WebGL release and finish off the current crop of > draft extensions. Performance measurements of prototypes of this > extension would definitely motivate it. Maybe it would be worth moving > it to draft status and planning on leaving it there for a while. > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 6 16:01:59 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 7 Mar 2012 01:01:59 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 12:57 AM, John Bauman wrote: > If you want you could do that only on the first instanced draw from a > buffer, and keep a shadow copy afterwards, but it might be difficult to > make that perform well. > No nead for readbacks, if you intercept bufferData calls and create a shadow copy then which you manage, you can do the right thing once before draw. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Mar 6 16:04:01 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 6 Mar 2012 16:04:01 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 6, 2012 at 4:01 PM, Florian B?sch wrote: > On Wed, Mar 7, 2012 at 12:57 AM, John Bauman wrote: >> >> If you want you could do that only on the first instanced draw from a >> buffer, and keep a shadow copy afterwards, but it might be difficult to make >> that perform well. > > No nead for readbacks, if you intercept bufferData calls and create a shadow > copy then which you manage, you can do the right thing once before draw. This implies that the WebGL implementation maintains a copy of all vertex data that's been uploaded. As I mentioned above I think this is impractical on mobile devices. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Tue Mar 6 16:44:06 2012 From: ben...@ (Ben Vanik) Date: Tue, 6 Mar 2012 16:44:06 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Or, just don't expose it unless it's natively supported. If it's there, apps can use it and get the benefit. I'd rather see the extension implemented and supported in one entire segment of the market than nowhere. OES_standard_derivatives & co aren't emulated if they aren't supported, so I'd say it's fine for this as well. On Tue, Mar 6, 2012 at 4:04 PM, Kenneth Russell wrote: > On Tue, Mar 6, 2012 at 4:01 PM, Florian B?sch wrote: > > On Wed, Mar 7, 2012 at 12:57 AM, John Bauman > wrote: > >> > >> If you want you could do that only on the first instanced draw from a > >> buffer, and keep a shadow copy afterwards, but it might be difficult to > make > >> that perform well. > > > > No nead for readbacks, if you intercept bufferData calls and create a > shadow > > copy then which you manage, you can do the right thing once before draw. > > This implies that the WebGL implementation maintains a copy of all > vertex data that's been uploaded. As I mentioned above I think this is > impractical on mobile devices. > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Mar 6 18:49:42 2012 From: bja...@ (Benoit Jacob) Date: Tue, 6 Mar 2012 18:49:42 -0800 (PST) Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: Message-ID: <73173137.6335278.1331088582345.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Tue, Mar 6, 2012 at 4:01 PM, Florian B?sch > wrote: > > On Wed, Mar 7, 2012 at 12:57 AM, John Bauman > > wrote: > >> > >> If you want you could do that only on the first instanced draw > >> from a > >> buffer, and keep a shadow copy afterwards, but it might be > >> difficult to make > >> that perform well. > > > > No nead for readbacks, if you intercept bufferData calls and create > > a shadow > > copy then which you manage, you can do the right thing once before > > draw. > > This implies that the WebGL implementation maintains a copy of all > vertex data that's been uploaded. As I mentioned above I think this > is > impractical on mobile devices. Not just on mobile devices, but on desktop too, given that our desktop users care about memory usage too. In Firefox, you can see how much (video) memory WebGLBuffers use by going to about:memory, and scrolling down to webgl-buffer-memory. It's often large enough that we'd need a very good reason to keep a copy of it on the heap. For example, this simple Quake3 level renderer, http://media.tojicode.com/q3bsp/ uses 1.66 MB of buffer data, and that's just an idle empty level. Opera's Odin demo, http://operasoftware.github.com/Odin/demo.html uses 2.05 MB of buffer data, with just one animated character and some objects around it. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Mar 6 18:59:05 2012 From: bja...@ (Benoit Jacob) Date: Tue, 6 Mar 2012 18:59:05 -0800 (PST) Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: <73173137.6335278.1331088582345.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <812550721.6335674.1331089145586.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > > > > ----- Original Message ----- > > On Tue, Mar 6, 2012 at 4:01 PM, Florian B?sch > > wrote: > > > On Wed, Mar 7, 2012 at 12:57 AM, John Bauman > > > > > > wrote: > > >> > > >> If you want you could do that only on the first instanced draw > > >> from a > > >> buffer, and keep a shadow copy afterwards, but it might be > > >> difficult to make > > >> that perform well. > > > > > > No nead for readbacks, if you intercept bufferData calls and > > > create > > > a shadow > > > copy then which you manage, you can do the right thing once > > > before > > > draw. > > > > This implies that the WebGL implementation maintains a copy of all > > vertex data that's been uploaded. As I mentioned above I think this > > is > > impractical on mobile devices. > > Not just on mobile devices, but on desktop too, given that our > desktop users care about memory usage too. Except that I am stupid: desktop support instanced_arrays already, so we wouldn't need to do this on desktop. Sorry. Benoit > > In Firefox, you can see how much (video) memory WebGLBuffers use by > going to about:memory, and scrolling down to webgl-buffer-memory. > It's often large enough that we'd need a very good reason to keep a > copy of it on the heap. For example, this simple Quake3 level > renderer, > http://media.tojicode.com/q3bsp/ > uses 1.66 MB of buffer data, and that's just an idle empty level. > > Opera's Odin demo, > http://operasoftware.github.com/Odin/demo.html > uses 2.05 MB of buffer data, with just one animated character and > some objects around it. > > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Mar 7 00:58:32 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 7 Mar 2012 09:58:32 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 1:04 AM, Kenneth Russell wrote: > This implies that the WebGL implementation maintains a copy of all > vertex data that's been uploaded. As I mentioned above I think this is > impractical on mobile devices. > Well, two points: - WebGL loose context forces us anyway to keep copies of buffers around in client memory, so it's moot to discuss weather it's impractical on mobile devices. It's not impractical, it's a necessity. - If somebody wants draw instanced, he can emulate it with more buffer updates or more draw calls himself. However that's guaranteed to be markedly slower then munching up a bit more ram and letting native code drive it rather than JS. The crux of the story is that before an attributes divisor is set and a buffer has been assigned to that attribute, it's unknown which buffer is intended to be used in that fashion. However from an application programmers point of view, there is no overlap between divisor advancing attributes and non divisor advancing ones. You're simply never gonna use a buffer intended to supply say bone matrices for each instance, in some kind of non divisor based fashion. It seems to me to be a bit an oversight not to structure the API such that it can be optimized more easily (like say marking buffers with attributes for divisors, rather than attributes). -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Wed Mar 7 06:32:06 2012 From: gle...@ (Glenn Maynard) Date: Wed, 7 Mar 2012 08:32:06 -0600 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 2:58 AM, Florian B?sch wrote: > On Wed, Mar 7, 2012 at 1:04 AM, Kenneth Russell wrote: > >> This implies that the WebGL implementation maintains a copy of all >> vertex data that's been uploaded. As I mentioned above I think this is >> impractical on mobile devices. >> > Well, two points: > - WebGL loose context forces us anyway to keep copies of buffers around in > client memory, so it's moot to discuss weather it's impractical on mobile > devices. It's not impractical, it's a necessity. > No, you can reload them from storage. Keeping two copies of every drawing resource decompressed and in memory all the time in case of context loss would be very inefficient. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 7 06:41:11 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 7 Mar 2012 15:41:11 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 3:32 PM, Glenn Maynard wrote: > No, you can reload them from storage. Keeping two copies of every drawing > resource decompressed and in memory all the time in case of context loss > would be very inefficient > That's a nice theory which falls somewhat flat. LocalStorage, the offline file cache and the client Web SQL database are limited to 5mb of data tops (some platforms obviously assign a lower hard limit). IndexDB doesn't work on any mobile device yet. So the only way to "reload from storage" for any remotely serious usecase would be re-fetching from the server. So a context lost can easily results in a serious amount of "re-boot" time. And then there's obvious issues like that some resources (like images) may be difficult to get array buffers from on mobile devices, so putting them in client storage would be unrealistic anyway. In theory you could keep the Image instance around, but in practise that amounts to pretty much the same thing as just holding the bytes in working memory. So if you have a choice between half a minute "re-boot" from server in case of context lost, or holding in ram and be back in a second or so, I know which is gonna be used by just about everybody after the first time trying the alternatives. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Mar 7 06:48:38 2012 From: bja...@ (Benoit Jacob) Date: Wed, 7 Mar 2012 06:48:38 -0800 (PST) Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: Message-ID: <413616318.6482653.1331131718209.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Wed, Mar 7, 2012 at 2:58 AM, Florian B?sch < pyalot...@ > > wrote: > > On Wed, Mar 7, 2012 at 1:04 AM, Kenneth Russell < kbr...@ > > > wrote: > > > > This implies that the WebGL implementation maintains a copy of > > > all > > > vertex data that's been uploaded. As I mentioned above I think > > > this > > > is > > > > > > impractical on mobile devices. > > > > > Well, two points: > > > - WebGL loose context forces us anyway to keep copies of buffers > > around in client memory, so it's moot to discuss weather it's > > impractical on mobile devices. It's not impractical, it's a > > necessity. > > No, you can reload them from storage. Keeping two copies of every > drawing resource decompressed and in memory all the time in case of > context loss would be very inefficient. Furthermore: the WebGL spec doesn't guarantee whatsoever that recovering from a lost context is easy or even possible. It just gives events telling content that it should recreate its WebGL state from scratch. Typically that is possible by reloading textures from where they were originally loaded from, but if some script was storing in a WebGL texture some data that isn't found anywhere else (e.g. the result of a GPGPU computation), then it's just lost. Benoit > -- > Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 7 06:53:37 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 7 Mar 2012 15:53:37 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: <413616318.6482653.1331131718209.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <413616318.6482653.1331131718209.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: > > Furthermore: the WebGL spec doesn't guarantee whatsoever that recovering > from a lost context is easy or even possible. It just gives events telling > content that it should recreate its WebGL state from scratch. Typically > that is possible by reloading textures from where they were originally > loaded from, but if some script was storing in a WebGL texture some data > that isn't found anywhere else (e.g. the result of a GPGPU computation), > then it's just lost. > I'm curious, if the context is lost for the GPU for an application. And if that application runs OpenCL, wouldn't it mean that all CL resources are lost too? It's obvious that context lost -> "meh tough luck bye" is sort of gonna work for a lot of usecases on WebGL (although not all because it's already possible to do GPGPU stuff with framebuffers). But if you're doing OpenCL, which is entirely and completely about GPGPU, it'd be pretty much disasterous. How's that gonna work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Mar 7 07:03:58 2012 From: bja...@ (Benoit Jacob) Date: Wed, 7 Mar 2012 07:03:58 -0800 (PST) Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: Message-ID: <1263115944.6485748.1331132638935.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > > Furthermore: the WebGL spec doesn't guarantee whatsoever that > > recovering from a lost context is easy or even possible. It just > > gives events telling content that it should recreate its WebGL > > state > > from scratch. Typically that is possible by reloading textures from > > where they were originally loaded from, but if some script was > > storing in a WebGL texture some data that isn't found anywhere else > > (e.g. the result of a GPGPU computation), then it's just lost. > > I'm curious, if the context is lost for the GPU for an application. > And if that application runs OpenCL, wouldn't it mean that all CL > resources are lost too? Yes, all OpenCL resources would be lost too. > It's obvious that context lost -> "meh tough luck bye" is sort of > gonna work for a lot of usecases on WebGL (although not all because > it's already possible to do GPGPU stuff with framebuffers). But if > you're doing OpenCL, which is entirely and completely about GPGPU, > it'd be pretty much disasterous. How's that gonna work? The only solution is to periodically read back and save (to main memory, or disk storage) the contents of the buffers that you don't want to lose. You'll still lose the last N seconds of computation, but that's better than losing everything. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 7 07:12:37 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 7 Mar 2012 16:12:37 +0100 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: <1263115944.6485748.1331132638935.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1263115944.6485748.1331132638935.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 4:03 PM, Benoit Jacob wrote: > The only solution is to periodically read back and save (to main memory, > or disk storage) the contents of the buffers that you don't want to lose. > You'll still lose the last N seconds of computation, but that's better than > losing everything. > Readback will be pretty slow, and I don't think that for a majority of realtime GPGPU applications it would be a feasible choice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Mar 7 07:17:37 2012 From: bja...@ (Benoit Jacob) Date: Wed, 7 Mar 2012 07:17:37 -0800 (PST) Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: Message-ID: <1475351601.6488257.1331133457371.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Wed, Mar 7, 2012 at 4:03 PM, Benoit Jacob < bjacob...@ > > wrote: > > The only solution is to periodically read back and save (to main > > memory, or disk storage) the contents of the buffers that you don't > > want to lose. You'll still lose the last N seconds of computation, > > but that's better than losing everything. > > Readback will be pretty slow, and I don't think that for a majority > of realtime GPGPU applications it would be a feasible choice. I agree that letting the script do periodical readback of important buffers is not a great solution, but I don't see another. Having the WebGL implementation cache all the buffers would be a lot slower, as it would have to read back stuff all the time, and would use too much memory too, so it's definitely a worse solution. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Wed Mar 7 09:37:56 2012 From: ben...@ (Ben Vanik) Date: Wed, 7 Mar 2012 09:37:56 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: <1475351601.6488257.1331133457371.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1475351601.6488257.1331133457371.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: This thread has moved a bit off topic, but I'd just like to point out that native games have been dealing with context lost events for a decade or so in the same way: reload everything from storage (which in the web could be a remote host). A context loss should never happen when the user is interacting with the content (unless the rendering system crashes, which should be rare), and if the user puts the device to sleep/switches out and back a few hours/days later/etc it's acceptable to reload content. Ideally, people are building things that load progressively instead of taking 5 minutes displaying a progress bar to get into the game, in which case it's not really that bad of a situation -- certainly not bad enough to warrant doubling your memory usage keeping buffers around! On Wed, Mar 7, 2012 at 7:17 AM, Benoit Jacob wrote: > > > ------------------------------ > > On Wed, Mar 7, 2012 at 4:03 PM, Benoit Jacob wrote: > >> The only solution is to periodically read back and save (to main memory, >> or disk storage) the contents of the buffers that you don't want to lose. >> You'll still lose the last N seconds of computation, but that's better than >> losing everything. >> > Readback will be pretty slow, and I don't think that for a majority of > realtime GPGPU applications it would be a feasible choice. > > I agree that letting the script do periodical readback of important > buffers is not a great solution, but I don't see another. Having the WebGL > implementation cache all the buffers would be a lot slower, as it would > have to read back stuff all the time, and would use too much memory too, so > it's definitely a worse solution. > > Benoit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Mar 7 09:52:22 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Wed, 7 Mar 2012 09:52:22 -0800 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <1475351601.6488257.1331133457371.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 9:37 AM, Ben Vanik wrote: > This thread has moved a bit off topic, but I'd just like to point out that > native games have been dealing with context lost events for a decade or so > in the same way: reload everything from storage (which in the web could be > a remote host). A context loss should never happen when the user is > interacting with the content (unless the rendering system crashes, which > should be rare), and if the user puts the device to sleep/switches out and > back a few hours/days later/etc it's acceptable to reload content. Ideally, > people are building things that load progressively instead of taking 5 > minutes displaying a progress bar to get into the game, in which case it's > not really that bad of a situation -- certainly not bad enough to warrant > doubling your memory usage keeping buffers around! > > Also remember, files will be cached by the browser and there are various ways for apps to cache resources themsevles so app can effectively reload from disc > > On Wed, Mar 7, 2012 at 7:17 AM, Benoit Jacob wrote: > >> >> >> ------------------------------ >> >> On Wed, Mar 7, 2012 at 4:03 PM, Benoit Jacob wrote: >> >>> The only solution is to periodically read back and save (to main memory, >>> or disk storage) the contents of the buffers that you don't want to lose. >>> You'll still lose the last N seconds of computation, but that's better than >>> losing everything. >>> >> Readback will be pretty slow, and I don't think that for a majority of >> realtime GPGPU applications it would be a feasible choice. >> >> I agree that letting the script do periodical readback of important >> buffers is not a great solution, but I don't see another. Having the WebGL >> implementation cache all the buffers would be a lot slower, as it would >> have to read back stuff all the time, and would use too much memory too, so >> it's definitely a worse solution. >> >> Benoit >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Wed Mar 7 12:09:54 2012 From: gle...@ (Glenn Maynard) Date: Wed, 7 Mar 2012 14:09:54 -0600 Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: References: <631620516.6095413.1331070530927.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 7, 2012 at 8:41 AM, Florian B?sch wrote: > IndexDB doesn't work on any mobile device yet. > Nor does this extension. APIs aren't introduced to the Web because another API "doesn't work yet". That's short-sighted, and the new API you define won't become available in production browsers any more quickly than the one you're waiting for. There may be plenty of reasons this extension is useful, but "because IndexedDB isn't available yet" isn't one of them. The rest is a bit tangential, but I'll respond to one a couple things anyway: > And then there's obvious issues like that some resources (like images) may be difficult to get array buffers from on mobile devices, so putting them in client storage would be unrealistic anyway. You don't store images in JavaScript storage. You keep the original HTMLImageElement around, and reload from that. A mature browser will handle the rest for you: decompressed pixel data for an HTMLImageElement will be discarded when it's not visible for a while (since it can be recreated from the smaller, compressed data), and the compressed data may also be discarded from memory (and reloaded from cache if necessary later). This all happens transparently (and not all browsers do all of these optimizations, of course). -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Mar 7 12:12:38 2012 From: bja...@ (Benoit Jacob) Date: Wed, 7 Mar 2012 12:12:38 -0800 (PST) Subject: [Public WebGL] ANGLE_instanced_arrays extension proposal In-Reply-To: Message-ID: <1936765150.6731711.1331151158842.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > IndexDB doesn't work on any mobile device yet. Just for the record, IndexedDB works in Firefox Mobile since version 6. https://developer.mozilla.org/en/IndexedDB#Browser_compatibility Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From cos...@ Wed Mar 7 15:31:07 2012 From: cos...@ (Liam Wilson) Date: Wed, 7 Mar 2012 23:31:07 +0000 (GMT) Subject: [Public WebGL] Re: Swiftshader/webgl In-Reply-To: References: <729594143.5172157.1330977911561.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1331163067.64566.YahooMailNeo@web29204.mail.ird.yahoo.com> Getting llvmpipe going on Linux is pretty easy on Ubuntu 10.10: * Download and build LLVM 3.0 * Point your PATH to you new llvm binaries (the version of llvm that comes with Ubuntu 10.10 is a bit buggy with llvmpipe) Download Mesa 8.0.1. Configure: ./configure --disable-dri? --disable-egl --enable-xlib-glx --with-gallium-drivers=swrast Don't quite know why I select "swrast". It does actually build llvmpipe. Note it also statically links llvm, so no need to install llvm anywhere. Your newly built llvmpipe driver will be in lib/gallium. Go to that directory and: export LD_LIBRARY_PATH=${PWD} Start Firefox, force enable webgl, and you should now have llvmpipe working (check in about:support). Performance is ok for me (on an E8400). With layers acceleration off in many cases llvmpipe performs about on a par with my GPU (an intel 4500hd). I assume there are some big bottlenecks in terms of actually putting the renderered pixels on the screen. glReadPixels is actually a big bottleneck even on LLVMpipe (glReadPixels in Mesa 8.0.1 does 107MPixels at most on my machine). See, https://bugs.freedesktop.org/show_bug.cgi?id=46631 and benchmark it with perf/readpixels in mesa-demos . That patch does seem to fix the problem for BGRA, but not RGBA (which is a bit odd, looking at the patch you'd expect it to be the other way round). If you apply the patch to mesa 8.0.1 and remove some checks in fast_read_rgba_pixels_memcpy you can get the same performance boost for RGBA (albeit with your colour channels mixed up). Liam ________________________________ From: John Davis To: Cedric Vivier Cc: "jdavis...@" ; Benoit Jacob ; public webgl Sent: Tuesday, 6 March 2012, 11:53 Subject: [Public WebGL] Re: Swiftshader/webgl No, I do not. ?But if implementation hasn't even started yet, FF is way behind chrome in this respect. On Monday, March 5, 2012, Cedric Vivier wrote: > > On Tue, Mar 6, 2012 at 04:45, John Davis wrote: >> This sort of difference could put FF at a serious disadvantage. > > Do you have any data on how current LLVMpipe performs compared to SwiftShader? > > Regards, > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Sat Mar 10 13:42:24 2012 From: bja...@ (Benoit Jacob) Date: Sat, 10 Mar 2012 13:42:24 -0800 (PST) Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Hi, This is another corner case found by Ms2ger. Currently, Firefox generates an exception when the texSubImage2D signature taking ArrayBuffer is passed null for the arraybuffer object. But looking at the spec, it says: "See texImage2D for restrictions on the format and pixels arguments." Which seems to imply that null should be accepted, as it is for texImage2D? And handled in the same way? What do other browsers do? Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Sat Mar 10 20:48:18 2012 From: kbr...@ (Kenneth Russell) Date: Sat, 10 Mar 2012 22:48:18 -0600 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Sat, Mar 10, 2012 at 9:42 PM, Benoit Jacob wrote: > > Hi, > > This is another corner case found by Ms2ger. Currently, Firefox generates an exception when the texSubImage2D signature taking ArrayBuffer is passed null for the arraybuffer object. > > But looking at the spec, it says: "See texImage2D for restrictions on the format and pixels arguments." Which seems to imply that null should be accepted, as it is for texImage2D? And handled in the same way? What do other browsers do? Oh boy. Another good catch. The conformance tests completely miss this case as does WebKit's WebGL implementation. Based on the intent in WebKit's code, I suggest that we amend the spec and conformance tests in the following ways: 1. Update the specs for texImage2D and texSubImage2D taking ArrayBufferView to state that if an ArrayBufferView is passed which does not contain enough data to satisfy the call, an INVALID_OPERATION error is generated. (This is already being enforced at least by conformance test textures/tex-image-with-invalid-data.html if not others.) 2. Update the texSubImage2D spec taking ArrayBufferView to state that if null is passed, an INVALID_VALUE error is generated. The rationale for the second is that it's obvious that no developers are currently relying on passing null to texSubImage2D in order to reset a sub-rectangle of a texture to transparent black. I don't think there's a reason to support this. I vaguely recall a decision some time ago to not enforce the behavior of passing null to the texImage2D and texSubImage2D variants taking HTMLImageElement, etc., because doing so conceptually exercises the overload resolution algorithm in Web IDL rather than the behavior of WebGL. Tim, do you remember this? It looks like an arbitrary method will be called according to the Web IDL spec. Perhaps we could enforce that INVALID_VALUE is passed in these cases since all of the overloads should have the same behavior. WebKit already does this for what it's worth. Thoughts? Would you support clarifying at least points 1 and 2 above in the in-progress 1.0.1 spec and conformance tests too? It seems like a corner case worth fixing up. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Sun Mar 11 08:51:02 2012 From: gle...@ (Glenn Maynard) Date: Sun, 11 Mar 2012 10:51:02 -0500 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Sat, Mar 10, 2012 at 10:48 PM, Kenneth Russell wrote: > Tim, do you remember this? It looks like an arbitrary method > will be called according to the Web IDL spec. Perhaps we could enforce > that INVALID_VALUE is passed in these cases since all of the overloads > should have the same behavior. WebKit already does this for what it's > worth. > An arbitrary method won't be called. Calling eg. texSubImage2D(..., null) will throw TypeError without calling any method, because no overload resolves to it. That's correct behavior; it's the same result as passing any other invalid parameter, such as texSubImage2D(..., window). http://dev.w3.org/2006/webapi/WebIDL/#call This is probably not happening in practice right now, because the spec doesn't use nullable types correctly. Implementors have to guess which arguments are supposed to be nullable. texImage2D(ArrayBufferView) needs to be nullable, and lots of other calls need nullable arguments as well (eg. bindTexture). The other texImage2D overloads, and all texSubImage2D overloads, should not have a nullable argument. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon Mar 12 07:28:34 2012 From: jda...@ (John Davis) Date: Mon, 12 Mar 2012 09:28:34 -0500 Subject: [Public WebGL] Angle Message-ID: If we enabled WARP within ANGLE wouldn't this provide a software rasterizer for XP/Win7 that everyone could benefit from? Covering the gaping hole for XP users with no gpu? -------------- next part -------------- An HTML attachment was scrubbed... URL: From phi...@ Mon Mar 12 07:38:50 2012 From: phi...@ (Philip Stears) Date: Mon, 12 Mar 2012 14:38:50 +0000 Subject: [Public WebGL] Angle In-Reply-To: References: Message-ID: <5D55BC45BC2DC34EBD0AE0CE79FD567A9220256B@sr-dc-core.DriveWorks.local> WARP only applies to Windows Vista and Windows 7: http://msdn.microsoft.com/en-us/library/gg615082.aspx Would be great to see it on those platforms though. Philip From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of John Davis Sent: 12 March 2012 14:29 To: public webgl Subject: [Public WebGL] Angle If we enabled WARP within ANGLE wouldn't this provide a software rasterizer for XP/Win7 that everyone could benefit from? Covering the gaping hole for XP users with no gpu? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rko...@ Mon Mar 12 07:37:25 2012 From: rko...@ (Kornmann, Ralf) Date: Mon, 12 Mar 2012 14:37:25 +0000 Subject: [Public WebGL] Angle In-Reply-To: References: Message-ID: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7EE@EU-MAIL-1-1.rws.ad.ea.com> WARP requires DX11. DX11 requires Vista SP1. -Ralf From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of John Davis Sent: Monday, March 12, 2012 15:29 PM To: public webgl Subject: [Public WebGL] Angle If we enabled WARP within ANGLE wouldn't this provide a software rasterizer for XP/Win7 that everyone could benefit from? ?Covering the gaping hole for XP users with no gpu? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From vla...@ Mon Mar 12 07:46:05 2012 From: vla...@ (Vladimir Vukicevic) Date: Mon, 12 Mar 2012 10:46:05 -0400 Subject: [Public WebGL] Angle In-Reply-To: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7EE@EU-MAIL-1-1.rws.ad.ea.com> References: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7EE@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf wrote: > > WARP requires DX11. > > DX11 requires Vista SP1. > AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, so it would have to be heavily rewritten to be able to take advantage of WARP even when it's available. - Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From rko...@ Mon Mar 12 07:48:30 2012 From: rko...@ (Kornmann, Ralf) Date: Mon, 12 Mar 2012 14:48:30 +0000 Subject: [Public WebGL] Angle In-Reply-To: References: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7EE@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7FA@EU-MAIL-1-1.rws.ad.ea.com> U3VyZSBhIERYMTEgcG9ydCBvZiBBbmdsZSBpcyBuZWVkZWQgZmlyc3QuIEJ1dCBpZiB0aGlzIGlz IGRvbmUgYWRkaW5nIFdBUlAgc3VwcG9ydCBpcyBwcmV0dHkgZWFzeS4gDQoNCkkgYW0gY3VycmVu dGx5IGNoZWNraW5nIGhvdyBtdWNoIHdvcmsgaXQgd2lsbCBiZSB0byBwb3J0IEFuZ2xlIHRvIERY MTEuDQoNCi1SYWxmDQoNCkZyb206IHZsYWRpbWlydkBnbWFpbC5jb20gW21haWx0bzp2bGFkaW1p cnZAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgVmxhZGltaXIgVnVraWNldmljDQpTZW50OiBNb25k YXksIE1hcmNoIDEyLCAyMDEyIDE1OjQ2IFBNDQpUbzogS29ybm1hbm4sIFJhbGYNCkNjOiBqZGF2 aXNAcGNwcm9ncmFtbWluZy5jb207IHB1YmxpYyB3ZWJnbA0KU3ViamVjdDogUmU6IFtQdWJsaWMg V2ViR0xdIEFuZ2xlDQoNCg0KT24gTW9uLCBNYXIgMTIsIDIwMTIgYXQgMTA6MzcgQU0sIEtvcm5t YW5uLCBSYWxmIDxya29ybm1hbm5AZWEuY29tPiB3cm90ZToNCg0KV0FSUCByZXF1aXJlcyBEWDEx Lg0KDQpEWDExIHJlcXVpcmVzIFZpc3RhIFNQMS4NCg0KQUZBSUssIFdBUlAgYWxzbyBvbmx5IGlt cGxlbWVudHMgdGhlIERYMTAvMTEgQVBJOyBBTkdMRSB1c2VzIERYOSwgc28gaXQgd291bGQgaGF2 ZSB0byBiZSBoZWF2aWx5IHJld3JpdHRlbiB0byBiZSBhYmxlIHRvIHRha2UgYWR2YW50YWdlIG9m IFdBUlAgZXZlbiB3aGVuIGl0J3MgYXZhaWxhYmxlLg0KDQrCoMKgIC0gVmxhZA0K ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Mon Mar 12 09:09:51 2012 From: jda...@ (John Davis) Date: Mon, 12 Mar 2012 11:09:51 -0500 Subject: [Public WebGL] Re: Angle In-Reply-To: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7FA@EU-MAIL-1-1.rws.ad.ea.com> References: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7EE@EU-MAIL-1-1.rws.ad.ea.com> <9B3BEF16CBC82A45900B3F159DF91596017576DFE7FA@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: What are the stats for win7 with no gpu, or blacklisted gpu? On Monday, March 12, 2012, Kornmann, Ralf wrote: > Sure a DX11 port of Angle is needed first. But if this is done adding WARP support is pretty easy. > > I am currently checking how much work it will be to port Angle to DX11. > > -Ralf > > From: vladimirv...@ [mailto:vladimirv...@] On Behalf Of Vladimir Vukicevic > Sent: Monday, March 12, 2012 15:46 PM > To: Kornmann, Ralf > Cc: jdavis...@; public webgl > Subject: Re: [Public WebGL] Angle > > > On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf wrote: > > WARP requires DX11. > > DX11 requires Vista SP1. > > AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, so it would have to be heavily rewritten to be able to take advantage of WARP even when it's available. > > - Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rko...@ Mon Mar 12 10:45:16 2012 From: rko...@ (Kornmann, Ralf) Date: Mon, 12 Mar 2012 17:45:16 +0000 Subject: [Public WebGL] RE: Angle In-Reply-To: References: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7EE@EU-MAIL-1-1.rws.ad.ea.com> <9B3BEF16CBC82A45900B3F159DF91596017576DFE7FA@EU-MAIL-1-1.rws.ad.ea.com>, Message-ID: <9B3BEF16CBC82A45900B3F159DF915960175762319A3@EU-MAIL-1-1.rws.ad.ea.com> Was this a question for me? In this case I am not sure what you are asking. ________________________________ Von: unicomp21...@ [unicomp21...@] im Auftrag von John Davis [jdavis...@] Gesendet: Montag, 12. M?rz 2012 17:09 An: Kornmann, Ralf Cc: Vladimir Vukicevic; jdavis...@; public webgl Betreff: Re: Angle What are the stats for win7 with no gpu, or blacklisted gpu? On Monday, March 12, 2012, Kornmann, Ralf > wrote: > Sure a DX11 port of Angle is needed first. But if this is done adding WARP support is pretty easy. > > I am currently checking how much work it will be to port Angle to DX11. > > -Ralf > > From: vladimirv...@ [mailto:vladimirv...@] On Behalf Of Vladimir Vukicevic > Sent: Monday, March 12, 2012 15:46 PM > To: Kornmann, Ralf > Cc: jdavis...@; public webgl > Subject: Re: [Public WebGL] Angle > > > On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf > wrote: > > WARP requires DX11. > > DX11 requires Vista SP1. > > AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, so it would have to be heavily rewritten to be able to take advantage of WARP even when it's available. > > - Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon Mar 12 13:22:07 2012 From: jda...@ (John Davis) Date: Mon, 12 Mar 2012 15:22:07 -0500 Subject: [Public WebGL] Re: Angle In-Reply-To: <9B3BEF16CBC82A45900B3F159DF915960175762319A3@EU-MAIL-1-1.rws.ad.ea.com> References: <9B3BEF16CBC82A45900B3F159DF91596017576DFE7EE@EU-MAIL-1-1.rws.ad.ea.com> <9B3BEF16CBC82A45900B3F159DF91596017576DFE7FA@EU-MAIL-1-1.rws.ad.ea.com> <9B3BEF16CBC82A45900B3F159DF915960175762319A3@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: No, I remember someone from Mozilla having the stats for Firefox users. Hoping they can post them again. Think it was Benoit. On Monday, March 12, 2012, Kornmann, Ralf wrote: > Was this a question for me? > > In this case I am not sure what you are asking. > > ________________________________ > Von: unicomp21...@ [unicomp21...@] im Auftrag von John Davis [ jdavis...@] > Gesendet: Montag, 12. M?rz 2012 17:09 > An: Kornmann, Ralf > Cc: Vladimir Vukicevic; jdavis...@; public webgl > Betreff: Re: Angle > > What are the stats for win7 with no gpu, or blacklisted gpu? > > On Monday, March 12, 2012, Kornmann, Ralf wrote: >> Sure a DX11 port of Angle is needed first. But if this is done adding WARP support is pretty easy. >> >> I am currently checking how much work it will be to port Angle to DX11. >> >> -Ralf >> >> From: vladimirv...@ [mailto:vladimirv...@] On Behalf Of Vladimir Vukicevic >> Sent: Monday, March 12, 2012 15:46 PM >> To: Kornmann, Ralf >> Cc: jdavis...@; public webgl >> Subject: Re: [Public WebGL] Angle >> >> >> On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf wrote: >> >> WARP requires DX11. >> >> DX11 requires Vista SP1. >> >> AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, so it would have to be heavily rewritten to be able to take advantage of WARP even when it's available. >> >> - Vlad >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Mar 12 15:31:16 2012 From: jgi...@ (Jeff Gilbert) Date: Mon, 12 Mar 2012 15:31:16 -0700 (PDT) Subject: [Public WebGL] Re: Angle In-Reply-To: Message-ID: <1866399402.9156568.1331591476405.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> It was Benoit, but he is currently on vacation. I will try to dig up the links, though. -Jeff ----- Original Message ----- From: "John Davis" To: "Ralf Kornmann" Cc: jdavis...@, "Vladimir Vukicevic" , "public webgl" Sent: Monday, March 12, 2012 1:22:07 PM Subject: [Public WebGL] Re: Angle No, I remember someone from Mozilla having the stats for Firefox users. Hoping they can post them again. Think it was Benoit. On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > wrote: > Was this a question for me? > > In this case I am not sure what you are asking. > > ________________________________ > Von: unicomp21...@ [ unicomp21...@ ] im Auftrag von John Davis [ jdavis...@ ] > Gesendet: Montag, 12. M?rz 2012 17:09 > An: Kornmann, Ralf > Cc: Vladimir Vukicevic; jdavis...@ ; public webgl > Betreff: Re: Angle > > What are the stats for win7 with no gpu, or blacklisted gpu? > > On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > wrote: >> Sure a DX11 port of Angle is needed first. But if this is done adding WARP support is pretty easy. >> >> I am currently checking how much work it will be to port Angle to DX11. >> >> -Ralf >> >> From: vladimirv...@ [mailto: vladimirv...@ ] On Behalf Of Vladimir Vukicevic >> Sent: Monday, March 12, 2012 15:46 PM >> To: Kornmann, Ralf >> Cc: jdavis...@ ; public webgl >> Subject: Re: [Public WebGL] Angle >> >> >> On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf < rkornmann...@ > wrote: >> >> WARP requires DX11. >> >> DX11 requires Vista SP1. >> >> AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, so it would have to be heavily rewritten to be able to take advantage of WARP even when it's available. >> >> - Vlad >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Mon Mar 12 16:07:52 2012 From: jda...@ (John Davis) Date: Mon, 12 Mar 2012 18:07:52 -0500 Subject: [Public WebGL] Re: Angle In-Reply-To: <1866399402.9156568.1331591476405.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1866399402.9156568.1331591476405.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: If they're still being tracked, I'd love to see the latest stats. I'm guessing the win7 count has gained considerably on winxp. On Mon, Mar 12, 2012 at 5:31 PM, Jeff Gilbert wrote: > > It was Benoit, but he is currently on vacation. I will try to dig up the > links, though. > > -Jeff > > ----- Original Message ----- > From: "John Davis" > To: "Ralf Kornmann" > Cc: jdavis...@, "Vladimir Vukicevic" , > "public webgl" > Sent: Monday, March 12, 2012 1:22:07 PM > Subject: [Public WebGL] Re: Angle > > No, I remember someone from Mozilla having the stats for Firefox users. > Hoping they can post them again. Think it was Benoit. > > On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > wrote: > > Was this a question for me? > > > > In this case I am not sure what you are asking. > > > > ________________________________ > > Von: unicomp21...@ [ unicomp21...@ ] im Auftrag von John > Davis [ jdavis...@ ] > > Gesendet: Montag, 12. M?rz 2012 17:09 > > An: Kornmann, Ralf > > Cc: Vladimir Vukicevic; jdavis...@ ; public webgl > > Betreff: Re: Angle > > > > What are the stats for win7 with no gpu, or blacklisted gpu? > > > > On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > wrote: > >> Sure a DX11 port of Angle is needed first. But if this is done adding > WARP support is pretty easy. > >> > >> I am currently checking how much work it will be to port Angle to DX11. > >> > >> -Ralf > >> > >> From: vladimirv...@ [mailto: vladimirv...@ ] On Behalf Of > Vladimir Vukicevic > >> Sent: Monday, March 12, 2012 15:46 PM > >> To: Kornmann, Ralf > >> Cc: jdavis...@ ; public webgl > >> Subject: Re: [Public WebGL] Angle > >> > >> > >> On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf < rkornmann...@ > > wrote: > >> > >> WARP requires DX11. > >> > >> DX11 requires Vista SP1. > >> > >> AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, so it > would have to be heavily rewritten to be able to take advantage of WARP > even when it's available. > >> > >> - Vlad > >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Mar 12 16:19:09 2012 From: bja...@ (Benoit Jacob) Date: Mon, 12 Mar 2012 16:19:09 -0700 (PDT) Subject: [Public WebGL] Re: Angle In-Reply-To: <1866399402.9156568.1331591476405.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <302639919.9298238.1331594349753.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Here are the stats (last updated a few weeks ago): http://people.mozilla.org/~bjacob/gfx_features_stats/ Benoit ----- Original Message ----- > > It was Benoit, but he is currently on vacation. I will try to dig up > the links, though. > > -Jeff > > ----- Original Message ----- > From: "John Davis" > To: "Ralf Kornmann" > Cc: jdavis...@, "Vladimir Vukicevic" > , "public webgl" > Sent: Monday, March 12, 2012 1:22:07 PM > Subject: [Public WebGL] Re: Angle > > No, I remember someone from Mozilla having the stats for Firefox > users. Hoping they can post them again. Think it was Benoit. > > On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > wrote: > > Was this a question for me? > > > > In this case I am not sure what you are asking. > > > > ________________________________ > > Von: unicomp21...@ [ unicomp21...@ ] im Auftrag von > > John Davis [ jdavis...@ ] > > Gesendet: Montag, 12. M?rz 2012 17:09 > > An: Kornmann, Ralf > > Cc: Vladimir Vukicevic; jdavis...@ ; public webgl > > Betreff: Re: Angle > > > > What are the stats for win7 with no gpu, or blacklisted gpu? > > > > On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > > > wrote: > >> Sure a DX11 port of Angle is needed first. But if this is done > >> adding WARP support is pretty easy. > >> > >> I am currently checking how much work it will be to port Angle to > >> DX11. > >> > >> -Ralf > >> > >> From: vladimirv...@ [mailto: vladimirv...@ ] On Behalf > >> Of Vladimir Vukicevic > >> Sent: Monday, March 12, 2012 15:46 PM > >> To: Kornmann, Ralf > >> Cc: jdavis...@ ; public webgl > >> Subject: Re: [Public WebGL] Angle > >> > >> > >> On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf < > >> rkornmann...@ > wrote: > >> > >> WARP requires DX11. > >> > >> DX11 requires Vista SP1. > >> > >> AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, > >> so it would have to be heavily rewritten to be able to take > >> advantage of WARP even when it's available. > >> > >> - Vlad > >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From tom...@ Tue Mar 13 00:29:19 2012 From: tom...@ (Tom Sparks) Date: Tue, 13 Mar 2012 00:29:19 -0700 (PDT) Subject: [Public WebGL] terrain LOD Implementations Message-ID: <1331623759.19983.YahooMailClassic@web120405.mail.ne1.yahoo.com> I am wondering if there are any webgl Implementations of terrain LODing for heightfields? --- tom_a_sparks "It's a nerdy thing I like to do" Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html Ubuntu wiki page https://wiki.ubuntu.com/tomsparks 3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 Premium Edition, AF 2012 Plus Edition, Sam440 AOS 4.1.2, Roland DXY-1300 pen plotter, Cutok DC330 cutter/pen plotter Wanted: RiscOS system, GEOS system (C64/C128), Atari ST, Apple Macintosh (6502/68k/PPC only) ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From tgl...@ Tue Mar 13 00:47:11 2012 From: tgl...@ (Tassilo Glander) Date: Tue, 13 Mar 2012 08:47:11 +0100 Subject: [Public WebGL] terrain LOD Implementations In-Reply-To: <1331623759.19983.YahooMailClassic@web120405.mail.ne1.yahoo.com> References: <1331623759.19983.YahooMailClassic@web120405.mail.ne1.yahoo.com> Message-ID: Yes, there are some, open and closed licences. This are what come to my mind: SpiderGL: http://spidergl.org/example.php?id=8 . WebGL Earth: http://www.webglearth.org/ ReadyMap: http://demo.pelicanmapping.com/rmweb/webgl/tests/index.html Nokia http://maps3d.svc.nokia.com/webgl/ Best, Tassilo 2012/3/13 Tom Sparks > > I am wondering if there are any webgl Implementations of terrain LODing > for heightfields? > > > --- > tom_a_sparks "It's a nerdy thing I like to do" > Please use ISO approved file formats excluding Office Open XML - > http://www.gnu.org/philosophy/no-word-attachments.html > Ubuntu wiki page https://wiki.ubuntu.com/tomsparks > 3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 Premium Edition, AF > 2012 Plus Edition, Sam440 AOS 4.1.2, Roland DXY-1300 pen plotter, Cutok > DC330 cutter/pen plotter > Wanted: RiscOS system, GEOS system (C64/C128), Atari ST, Apple Macintosh > (6502/68k/PPC only) > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -- Tassilo Glander Investigador / Researcher Sistemas de transporte inteligentes e Ingenier?a / Intelligent Transport Systems and Engineering Vicomtech-IK4 - Visual Interaction Communication Technologies Mikeletegi Pasealekua, 57 - Parque Tecnol?gico 20009 Donostia - San Sebasti?n - Spain Tel: +[34] 943 30 92 30 Fax: +[34] 943 30 93 93 e-mail: tglander...@ *** member of IK4 Research Alliance ****www.ik4.es *** member of GraphicsMedia.net ****www.graphicsmedia.net ----------------------------------------------------- Vicomtech-IK4 is an ISO 9001:2000 certified institute ----------------------------------------------------- Aviso Legal - Pol?tica de privacidad (http://www.vicomtech.es/castellano/html/informacion_legal/index.html) Lege Oharra - Pribatutasun politika (http://www.vicomtech.es/euskera/html/informacion_legal/index.html) Legal Notice - Privacy policy (http://www.vicomtech.es/ingles/html/informacion_legal/index.html) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Tue Mar 13 03:33:59 2012 From: tim...@ (Tim Johansson) Date: Tue, 13 Mar 2012 11:33:59 +0100 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F5F2297.3070302@opera.com> On 2012-03-11 05:48, Kenneth Russell wrote: > On Sat, Mar 10, 2012 at 9:42 PM, Benoit Jacob wrote: >> Hi, >> >> This is another corner case found by Ms2ger. Currently, Firefox generates an exception when the texSubImage2D signature taking ArrayBuffer is passed null for the arraybuffer object. >> >> But looking at the spec, it says: "See texImage2D for restrictions on the format and pixels arguments." Which seems to imply that null should be accepted, as it is for texImage2D? And handled in the same way? What do other browsers do? > Oh boy. Another good catch. The conformance tests completely miss this > case as does WebKit's WebGL implementation. Based on the intent in > WebKit's code, I suggest that we amend the spec and conformance tests > in the following ways: > > 1. Update the specs for texImage2D and texSubImage2D taking > ArrayBufferView to state that if an ArrayBufferView is passed which > does not contain enough data to satisfy the call, an INVALID_OPERATION > error is generated. (This is already being enforced at least by > conformance test textures/tex-image-with-invalid-data.html if not > others.) > > 2. Update the texSubImage2D spec taking ArrayBufferView to state that > if null is passed, an INVALID_VALUE error is generated. > > The rationale for the second is that it's obvious that no developers > are currently relying on passing null to texSubImage2D in order to > reset a sub-rectangle of a texture to transparent black. I don't think > there's a reason to support this. > > I vaguely recall a decision some time ago to not enforce the behavior > of passing null to the texImage2D and texSubImage2D variants taking > HTMLImageElement, etc., because doing so conceptually exercises the > overload resolution algorithm in Web IDL rather than the behavior of > WebGL. Tim, do you remember this? It looks like an arbitrary method > will be called according to the Web IDL spec. Perhaps we could enforce > that INVALID_VALUE is passed in these cases since all of the overloads > should have the same behavior. WebKit already does this for what it's > worth. Yeah, if you leave the 6th parameter out it is tricky to tell if you tried to call the version taking 5 numbers and an object (HTMLImageElement) or the version taking 8 numbers and an object (TypedArray). In our implementation we would assume 0/null for the missing parameters and the call would match both versions. In that case we are highly likely to choose the one which does not cause an error. I think there has been quite a bit of work on this in WebIDL since we last looked at it, so it might actually be better specified now, but even if it is it would IMO mostly be a conformance test of WebIDL and not of WebGL. (I am also not sure if I like INVALID_VALUE or an TypeError exception better in this case) > Thoughts? Would you support clarifying at least points 1 and 2 above > in the in-progress 1.0.1 spec and conformance tests too? It seems like > a corner case worth fixing up. I agree, it is something we should clarify. I'm pretty sure we currently throw a TypeError for passing null to the TypedArray version of texSubImage2D right now (so we handle 2. in a different way). Changing it to raising a gl error should be easy, but I am not sure that is better. In case 1. (not enough data) we already generate INVALID_OPERATION, I actually thought the spec already said that but I can't find it so I guess not :). //Tim ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Tue Mar 13 03:42:56 2012 From: jda...@ (John Davis) Date: Tue, 13 Mar 2012 05:42:56 -0500 Subject: [Public WebGL] Re: Angle In-Reply-To: <302639919.9298238.1331594349753.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1866399402.9156568.1331591476405.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <302639919.9298238.1331594349753.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: wow, I wouldn't have expected win7 success rates to be so low. looks like adding warp to angle might be worth the effort. On Monday, March 12, 2012, Benoit Jacob wrote: > Here are the stats (last updated a few weeks ago): > > http://people.mozilla.org/~bjacob/gfx_features_stats/ > > Benoit > > > ----- Original Message ----- >> >> It was Benoit, but he is currently on vacation. I will try to dig up >> the links, though. >> >> -Jeff >> >> ----- Original Message ----- >> From: "John Davis" >> To: "Ralf Kornmann" >> Cc: jdavis...@, "Vladimir Vukicevic" >> , "public webgl" >> Sent: Monday, March 12, 2012 1:22:07 PM >> Subject: [Public WebGL] Re: Angle >> >> No, I remember someone from Mozilla having the stats for Firefox >> users. Hoping they can post them again. Think it was Benoit. >> >> On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > wrote: >> > Was this a question for me? >> > >> > In this case I am not sure what you are asking. >> > >> > ________________________________ >> > Von: unicomp21...@ [ unicomp21...@ ] im Auftrag von >> > John Davis [ jdavis...@ ] >> > Gesendet: Montag, 12. M?rz 2012 17:09 >> > An: Kornmann, Ralf >> > Cc: Vladimir Vukicevic; jdavis...@ ; public webgl >> > Betreff: Re: Angle >> > >> > What are the stats for win7 with no gpu, or blacklisted gpu? >> > >> > On Monday, March 12, 2012, Kornmann, Ralf < rkornmann...@ > >> > wrote: >> >> Sure a DX11 port of Angle is needed first. But if this is done >> >> adding WARP support is pretty easy. >> >> >> >> I am currently checking how much work it will be to port Angle to >> >> DX11. >> >> >> >> -Ralf >> >> >> >> From: vladimirv...@ [mailto: vladimirv...@ ] On Behalf >> >> Of Vladimir Vukicevic >> >> Sent: Monday, March 12, 2012 15:46 PM >> >> To: Kornmann, Ralf >> >> Cc: jdavis...@ ; public webgl >> >> Subject: Re: [Public WebGL] Angle >> >> >> >> >> >> On Mon, Mar 12, 2012 at 10:37 AM, Kornmann, Ralf < >> >> rkornmann...@ > wrote: >> >> >> >> WARP requires DX11. >> >> >> >> DX11 requires Vista SP1. >> >> >> >> AFAIK, WARP also only implements the DX10/11 API; ANGLE uses DX9, >> >> so it would have to be heavily rewritten to be able to take >> >> advantage of WARP even when it's available. >> >> >> >> - Vlad >> >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Tue Mar 13 03:53:19 2012 From: cvi...@ (Cedric Vivier) Date: Tue, 13 Mar 2012 18:53:19 +0800 Subject: [Public WebGL] Re: Angle In-Reply-To: References: <1866399402.9156568.1331591476405.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <302639919.9298238.1331594349753.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 13, 2012 at 18:42, John Davis wrote: > wow, I wouldn't have expected win7 success rates to be so low. ?looks like > adding warp to angle might be worth the effort. I'm also a bit surprised. Benoit, do you think we could add a Telemetry probe to our WebGL initialization in order to avoid any crash-stats bias? It seems we currently have a probe measuring attempted usage of WebGL (Telemetry::CANVAS_WEBGL_USED) but no info on the success/failure of the attempted usage. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Tue Mar 13 07:37:46 2012 From: gle...@ (Glenn Maynard) Date: Tue, 13 Mar 2012 09:37:46 -0500 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: <4F5F2297.3070302@opera.com> References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> Message-ID: On Tue, Mar 13, 2012 at 5:33 AM, Tim Johansson wrote: > Yeah, if you leave the 6th parameter out it is tricky to tell if you tried > to call the version taking 5 numbers and an object (HTMLImageElement) or > the version taking 8 numbers and an object (TypedArray). In our > implementation we would assume 0/null for the missing parameters and the > call would match both versions. In that case we are highly likely to choose > the one which does not cause an error. > > I think there has been quite a bit of work on this in WebIDL since we last > looked at it, so it might actually be better specified now, but even if it > is it would IMO mostly be a conformance test of WebIDL and not of WebGL. I'm not an expert on WebIDL, but this all looks tightly specified now. It's worth having a test for this in WebGL, since WebGL is exercising this part of WebIDL more than a lot of other current APIs. (I am also not sure if I like INVALID_VALUE or an TypeError exception > better in this case) If you call deleteTexture(window), or linkProgram(document.createEvent("event")), or texImage2D(2D, 0, ifmt, fmt, type, document) WebIDL throws TypeError. The same should happen if null is passed; it's just another invalid parameter type. INVALID_VALUE should only be used if the method is actually called by WebIDL, but the value of the parameters is invalid. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Tue Mar 13 08:58:35 2012 From: tim...@ (Tim Johansson) Date: Tue, 13 Mar 2012 16:58:35 +0100 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> Message-ID: <4F5F6EAB.8080707@opera.com> On 2012-03-13 15:37, Glenn Maynard wrote: > On Tue, Mar 13, 2012 at 5:33 AM, Tim Johansson > wrote: > > Yeah, if you leave the 6th parameter out it is tricky to tell if > you tried to call the version taking 5 numbers and an object > (HTMLImageElement) or the version taking 8 numbers and an object > (TypedArray). In our implementation we would assume 0/null for the > missing parameters and the call would match both versions. In that > case we are highly likely to choose the one which does not cause > an error. > > I think there has been quite a bit of work on this in WebIDL since > we last looked at it, so it might actually be better specified > now, but even if it is it would IMO mostly be a conformance test > of WebIDL and not of WebGL. > > > I'm not an expert on WebIDL, but this all looks tightly specified now. > > It's worth having a test for this in WebGL, since WebGL is exercising > this part of WebIDL more than a lot of other current APIs. > Yeah, looks like it is well specified now. I don't have any strong objections in this specific case right now (haven't checked if it is implementable yet though) since IDL is a bit of a special case, but I think we should be careful about testing other specs in the WebGL conformance testsuite. > (I am also not sure if I like INVALID_VALUE or an TypeError > exception better in this case) > > > If you call deleteTexture(window), or > linkProgram(document.createEvent("event")), or texImage2D(2D, 0, ifmt, > fmt, type, document) WebIDL throws TypeError. The same should happen > if null is passed; it's just another invalid parameter type. > > INVALID_VALUE should only be used if the method is actually called by > WebIDL, but the value of the parameters is invalid. > Yeah, I agree with that, but that is not what most of the other webgl functions does, which is why I am not sure what to do. For example validateProgram and useProgram both take WebGLProgram but have to accept null to pass the conformance tests IIRC. In the case of validateProgram it should give you INVALID_VALUE and in the case of useProgram it should actually do something (unbind the current program). Which functions accepts null and how it is dealt with is generally underspecified, which is something we should fix, first step is to agree on how null should be dealt with and mark the ones which does not throw TyperError as nullable. //Tim ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Tue Mar 13 09:07:26 2012 From: jda...@ (John Davis) Date: Tue, 13 Mar 2012 11:07:26 -0500 Subject: [Public WebGL] Re: Angle In-Reply-To: References: <1866399402.9156568.1331591476405.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <302639919.9298238.1331594349753.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: So, can we get google to fund transgaming to add directx warp to angle? ;) On Tuesday, March 13, 2012, Cedric Vivier wrote: > On Tue, Mar 13, 2012 at 18:42, John Davis wrote: >> wow, I wouldn't have expected win7 success rates to be so low. looks like >> adding warp to angle might be worth the effort. > > I'm also a bit surprised. > Benoit, do you think we could add a Telemetry probe to our WebGL > initialization in order to avoid any crash-stats bias? > > It seems we currently have a probe measuring attempted usage of WebGL > (Telemetry::CANVAS_WEBGL_USED) but no info on the success/failure of > the attempted usage. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Tue Mar 13 09:33:11 2012 From: gle...@ (Glenn Maynard) Date: Tue, 13 Mar 2012 11:33:11 -0500 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: <4F5F6EAB.8080707@opera.com> References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> <4F5F6EAB.8080707@opera.com> Message-ID: On Tue, Mar 13, 2012 at 10:58 AM, Tim Johansson wrote: > For example validateProgram and useProgram both take WebGLProgram but have > to accept null to pass the conformance tests IIRC. In the case of > validateProgram it should give you INVALID_VALUE and in the case of > useProgram it should actually do something (unbind the current program). > The conformance test is incorrect; validateProgram(null) should throw TypeError. (Since the WebGL spec doesn't correctly use nullable parameters, it's not too surprising if the tests get them wrong, too.) useProgram's parameter should be nullable, of course. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Mar 13 10:47:57 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Tue, 13 Mar 2012 10:47:57 -0700 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> <4F5F6EAB.8080707@opera.com> Message-ID: On Tue, Mar 13, 2012 at 9:33 AM, Glenn Maynard wrote: > On Tue, Mar 13, 2012 at 10:58 AM, Tim Johansson wrote: > >> For example validateProgram and useProgram both take WebGLProgram but >> have to accept null to pass the conformance tests IIRC. In the case of >> validateProgram it should give you INVALID_VALUE and in the case of >> useProgram it should actually do something (unbind the current program). >> > > The conformance test is incorrect; validateProgram(null) should throw > TypeError. (Since the WebGL spec doesn't correctly use nullable > parameters, it's not too surprising if the tests get them wrong, too.) > I think it comes down to emulating OpenGL or not. glValidateProgram excepts 0 will generate INVALID_VALUE therefore it's not unreasonable for WebGL to do the same. I don't expect any programs use validateProgram but the idea is that OpenGL programs should be portable to WebGL with as few changes as possible. glTexSubImage2D if passed null will crash if all other parameters are valid. Therefore throwing an exception if passed null OpenGL seems more acceptable. On the the other hand, calling GLint width = 0; GLint height = 0; glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE, NULL); will likely not crash since no data will be referenced. > > useProgram's parameter should be nullable, of course. > > -- > Glenn Maynard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Mar 13 14:24:29 2012 From: bja...@ (Benoit Jacob) Date: Tue, 13 Mar 2012 14:24:29 -0700 (PDT) Subject: [Public WebGL] Re: Angle In-Reply-To: Message-ID: <1893504191.10099583.1331673868961.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Tue, Mar 13, 2012 at 18:42, John Davis > wrote: > > wow, I wouldn't have expected win7 success rates to be so low. > > ?looks like > > adding warp to angle might be worth the effort. > > I'm also a bit surprised. > Benoit, do you think we could add a Telemetry probe to our WebGL > initialization in order to avoid any crash-stats bias? > > It seems we currently have a probe measuring attempted usage of WebGL > (Telemetry::CANVAS_WEBGL_USED) but no info on the success/failure of > the attempted usage. > Sure we can do that. check in content/canvas/src/WebGLContext.cpp, there is already a Telemetry probe to see how many people are using WebGL at all. You can add a probe for the success rate by adding a Telemetry call at the same place as the existing SetSuccessful() call in this file. That said: I'm not sure that this is any less biased. People who enable Telemetry are biased towards technical users. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Mar 13 16:13:48 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 13 Mar 2012 18:13:48 -0500 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> <4F5F6EAB.8080707@opera.com> Message-ID: On Tue, Mar 13, 2012 at 12:47 PM, Gregg Tavares (?) wrote: > > > On Tue, Mar 13, 2012 at 9:33 AM, Glenn Maynard wrote: >> >> On Tue, Mar 13, 2012 at 10:58 AM, Tim Johansson wrote: >>> >>> For example validateProgram and useProgram both take WebGLProgram but >>> have to accept null to pass the conformance tests IIRC. In the case of >>> validateProgram it should give you INVALID_VALUE and in the case of >>> useProgram it should actually do something (unbind the current program). >> >> >> The conformance test is incorrect; validateProgram(null) should throw >> TypeError.? (Since the WebGL spec doesn't correctly use nullable parameters, >> it's not too surprising if the tests get them wrong, too.) > > > I think it comes down to emulating OpenGL or not. glValidateProgram excepts > 0 will generate INVALID_VALUE therefore it's not unreasonable for WebGL to > do the same. I don't expect any programs use validateProgram but the idea is > that OpenGL programs should be portable to WebGL with as few changes as > possible. > > glTexSubImage2D if passed null will crash if all other parameters are valid. > Therefore throwing an exception if passed null OpenGL seems more acceptable. > On the the other hand, calling > > ? ?GLint width = 0; > ? ?GLint height = 0; > ? ?glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, GL_RGBA, > GL_UNSIGNED_BYTE, NULL); > > will likely not crash since no data will be referenced. In general we should fix the issues with nullable arguments in the WebGL spec. This will be a large change. I suggest that we do this in the current editor's draft and conformance tests, and leave the currently ill-specified behavior untested in the 1.0.1 conformance tests. For the particular case of texSubImage2D taking ArrayBufferView, I'm more in favor of forcing the argument to be non-nullable so that the type system catches the error. -Ken >> >> >> useProgram's parameter should be nullable, of course. >> >> -- >> Glenn Maynard >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Tue Mar 13 16:19:52 2012 From: gle...@ (Glenn Maynard) Date: Tue, 13 Mar 2012 18:19:52 -0500 Subject: [Public WebGL] String support in DataView In-Reply-To: References: Message-ID: For those interested, there's currently further discussion of this over on whatwg. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Tue Mar 13 16:20:32 2012 From: ben...@ (Ben Vanik) Date: Tue, 13 Mar 2012 16:20:32 -0700 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> <4F5F6EAB.8080707@opera.com> Message-ID: May I suggest that while modifying the signatures of these methods in future versions that they be widened to support taking ArrayBuffer as well? For those of us using XHR/File APIs that return ArrayBuffers or pass around ArrayBuffers in our code it's often a waste to have to wrap everything in a Uint8Array/etc before calling these methods - especially when the implementations don't need the type from the view. On Tue, Mar 13, 2012 at 4:13 PM, Kenneth Russell wrote: > > On Tue, Mar 13, 2012 at 12:47 PM, Gregg Tavares (?) > wrote: > > > > > > On Tue, Mar 13, 2012 at 9:33 AM, Glenn Maynard wrote: > >> > >> On Tue, Mar 13, 2012 at 10:58 AM, Tim Johansson wrote: > >>> > >>> For example validateProgram and useProgram both take WebGLProgram but > >>> have to accept null to pass the conformance tests IIRC. In the case of > >>> validateProgram it should give you INVALID_VALUE and in the case of > >>> useProgram it should actually do something (unbind the current > program). > >> > >> > >> The conformance test is incorrect; validateProgram(null) should throw > >> TypeError. (Since the WebGL spec doesn't correctly use nullable > parameters, > >> it's not too surprising if the tests get them wrong, too.) > > > > > > I think it comes down to emulating OpenGL or not. glValidateProgram > excepts > > 0 will generate INVALID_VALUE therefore it's not unreasonable for WebGL > to > > do the same. I don't expect any programs use validateProgram but the > idea is > > that OpenGL programs should be portable to WebGL with as few changes as > > possible. > > > > glTexSubImage2D if passed null will crash if all other parameters are > valid. > > Therefore throwing an exception if passed null OpenGL seems more > acceptable. > > On the the other hand, calling > > > > GLint width = 0; > > GLint height = 0; > > glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, GL_RGBA, > > GL_UNSIGNED_BYTE, NULL); > > > > will likely not crash since no data will be referenced. > > In general we should fix the issues with nullable arguments in the WebGL > spec. > > This will be a large change. I suggest that we do this in the current > editor's draft and conformance tests, and leave the currently > ill-specified behavior untested in the 1.0.1 conformance tests. > > For the particular case of texSubImage2D taking ArrayBufferView, I'm > more in favor of forcing the argument to be non-nullable so that the > type system catches the error. > > -Ken > > > >> > >> > >> useProgram's parameter should be nullable, of course. > >> > >> -- > >> Glenn Maynard > >> > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Tue Mar 13 16:28:15 2012 From: gle...@ (Glenn Maynard) Date: Tue, 13 Mar 2012 18:28:15 -0500 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> <4F5F6EAB.8080707@opera.com> Message-ID: On Tue, Mar 13, 2012 at 12:47 PM, Gregg Tavares (?) wrote: > I think it comes down to emulating OpenGL or not. glValidateProgram > excepts 0 will generate INVALID_VALUE therefore it's not unreasonable for > WebGL to do the same. I don't expect any programs use validateProgram but > the idea is that OpenGL programs should be portable to WebGL with as few > changes as possible. > The API is already different from OpenGL here. An ArrayBuffer is nothing like a raw pointer to memory that you'd use in OpenGL. The language bindings are also just fundamentally different, and "emulating" OpenGL here gives an API which is inconsistent both with itself and the rest of the platform. (There are other good reasons to try to keep WebGL from deviating unnecessarily from OpenGL, but the language binding level is just inherently different; C and JS are at opposite ends of the language spectrum.) On Tue, Mar 13, 2012 at 6:20 PM, Ben Vanik wrote: > May I suggest that while modifying the signatures of these methods in > future versions that they be widened to support taking ArrayBuffer as well? > For those of us using XHR/File APIs that return ArrayBuffers or pass around > ArrayBuffers in our code it's often a waste to have to wrap everything in a > Uint8Array/etc before calling these methods - especially when the > implementations don't need the type from the view. > This should be discussed in a separate thread to not derail this discussion, but there's no waste in creating a Uint8Array from an ArrayBuffer; it's just a thin view and doesn't create a deep copy. (I believe this was discussed on the list recently.) -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Wed Mar 14 01:49:59 2012 From: tim...@ (Tim Johansson) Date: Wed, 14 Mar 2012 09:49:59 +0100 Subject: [Public WebGL] Should texSubImage2D accept null like texImage2D does? In-Reply-To: References: <1227138342.8279574.1331415408219.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1241945585.8279812.1331415744771.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F5F2297.3070302@opera.com> <4F5F6EAB.8080707@opera.com> Message-ID: <4F605BB7.8090704@opera.com> On 2012-03-13 17:33, Glenn Maynard wrote: > On Tue, Mar 13, 2012 at 10:58 AM, Tim Johansson > wrote: > > For example validateProgram and useProgram both take WebGLProgram > but have to accept null to pass the conformance tests IIRC. In the > case of validateProgram it should give you INVALID_VALUE and in > the case of useProgram it should actually do something (unbind the > current program). > > > The conformance test is incorrect; validateProgram(null) should throw > TypeError. (Since the WebGL spec doesn't correctly use nullable > parameters, it's not too surprising if the tests get them wrong, too.) > > useProgram's parameter should be nullable, of course. > Yes, I agree on both of them, IMO everything that does not do anything useful with null values should not be nullable. I actually implemented it that way first, but I changed many of them to nullable temporarily to pass more conformance tests and forgot to change them back :( For reference, the functions which required nullable values in the conformance test a few months ago were (the ones I think are wrong and should be changed are marked with a *): attachShader (param *1,*2) bindAttribLocation (param *1) bindBuffer (param 2) bindFramebuffer (param 2) bindRenderbuffer (param 2) bindTexture (param 2) bufferSubData (param *3) compileShader (param *1) deleteBuffer (param *1) deleteFramebuffer (param *1) deleteProgram (param *1) deleteRenderbuffer (param *1) deleteShader (param *1) deleteTexture (param *1) detachShader (param *1,*2) framebufferRenderbuffer (param 4) framebufferTexture2D (param 4) getActiveAttrib (param *1) getActiveUniform (param *1) getAttachedShaders (param *1) getAttribLocation (param *1) getProgramParameter (param *1) getProgramInfoLog (param *1) getShaderParameter (param *1) getShaderInfoLog (param *1) getShaderSource (param *1) getUniform (param *1,2 - 2 should be nullable) getUniformLocation (param *1) linkProgram (param *1) readPixels (param *7) shaderSource (param *1) texImage2D (Array buffer, param 9) uniform[1-4]f (param 1) uniform[1-4]fv (param 1 but not 2) uniform[1-4]i (param 1) uniform[1-4]iv (param 1 but not 2) uniformMatrix[2-4]fv (param 1 but not 3) useProgram (param 1) validateProgram (param *1) And functions which did not have to be nullable were: isBuffer (param 1) isFramebuffer (param 1) isProgram (param 1) isRenderbuffer (param 1) isShader (param 1) isTexture (param 1) texSubImage2D (Array buffer, param 7) uniform[1-4]fv (param 2 but not 1) uniform[1-4]iv (param 2 but not 1) uniformMatrix[2-4]fv (param 3 but not 1) vertexAttrib[1-4]fv (param 2) bufferData (we convert param 2 to number if not object) //Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Fri Mar 16 08:17:02 2012 From: tim...@ (Tim Johansson) Date: Fri, 16 Mar 2012 16:17:02 +0100 Subject: [Public WebGL] Nullable changes in the spec Message-ID: <4F63596E.3000403@opera.com> I have gone through the spec and marked the parameters and return values which must be nullable to pass the conformance test as nullable. Please verify the change in the spec. In many places making them nullable is clearly the right thing to do as the corresponding gl functions either needs a null value or silently ignores it. In other cases it is less clear because all null will do is raise a gl error and potentially result in an unexpected return value. The following cases currently accepts null and will only raise a gl error when passed null, I placed the most problematic or confusing ones first: * bufferSubData - Does not specify how it deals with data==null, would probably crash in gl * readPixels - INVALID_VALUE on pixels==null, clearly stated in the spec. Would probably crash in gl. If texSubImage, bufferSubData, uniform*v and vertexAttrib*fv are not nullable I think this should match them for consistency * getAttachedShaders - INVALID_VALUE for program==null, returns null instead of empty list in this case, so it is highly likely to cause exceptions when using the returned object * getActiveAttrib - INVALID_VALUE for program==null, will return null instead of the expected WEBGLActiveInfo object (so does out of range index) * getActiveUniform - INVALID_VALUE for program==null, will return null instead of the expected WEBGLActiveInfo object (so does out of range index) * getAttribLocation - INVALID_VALUE for program==null, should probably return 0 on error according to the spec, we return -1 which IMO makes much more sense. If we want this nullable we should probably specify that return value (-1 is used for too long identifiers) * getUniform - INVALID_VALUE for program==null, INVALID_OPERATION if location==null. This will return null on error, so it will require extra checks regardless of if it is nullable or not * attachShader - INVALID_VALUE for program==null or shader==null * bindAttribLocation - INVALID_VALUE for program==null * compileShader - INVALID_VALUE for shader==null * detachShader - INVALID_VALUE for program==null or shader==null * getProgramParameter - INVALID_VALUE for program==null * getProgramInfoLog - INVALID_VALUE for program==null * getShaderParameter - INVALID_VALUE for shader==null * getShaderInfoLog - INVALID_VALUE for shader==null * getShaderSource - INVALID_VALUE for shader==null * getUniformLocation - INVALID_VALUE for program==null * linkProgram - INVALID_VALUE for program==null * shaderSource - INVALID_VALUE for shader==null * validateProgram - INVALID_VALUE for program==null In addition to that the following are not very clear how to deal with: * isBuffer * isFramebuffer * isProgram * isRenderbuffer * isShader * isTexture They are very different from how they work in regular gl. In regular gl you pass in an integer and it will tell you if that name is a texture/buffer/... or not, it never generates an error. In WebGL you pass in an object of the correct type and the only thing it will tell you is essentially if the object has been explicitly deleted or not. In our implementation they are not nullable, so passing null will throw an exception. The conformance test does not require them to be nullable. //Tim ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Fri Mar 16 10:58:04 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Fri, 16 Mar 2012 10:58:04 -0700 Subject: [Public WebGL] Nullable changes in the spec In-Reply-To: <4F63596E.3000403@opera.com> References: <4F63596E.3000403@opera.com> Message-ID: On Fri, Mar 16, 2012 at 8:17 AM, Tim Johansson wrote: > > I have gone through the spec and marked the parameters and return values > which must be nullable to pass the conformance test as nullable. Please > verify the change in the spec. > > In many places making them nullable is clearly the right thing to do as > the corresponding gl functions either needs a null value or silently > ignores it. In other cases it is less clear because all null will do is > raise a gl error and potentially result in an unexpected return value. > > The following cases currently accepts null and will only raise a gl error > when passed null, I placed the most problematic or confusing ones first: > > * bufferSubData - Does not specify how it deals with data==null, would > probably crash in gl > * readPixels - INVALID_VALUE on pixels==null, clearly stated in the spec. > Would probably crash in gl. If texSubImage, bufferSubData, uniform*v and > vertexAttrib*fv are not nullable I think this should match them for > consistency > All the ones below here NEED to continue to allow NULL otherwise they will start throwing exceptions on context lost when all the createXXX functions start returning NULL. > * getAttachedShaders - INVALID_VALUE for program==null, returns null > instead of empty list in this case, so it is highly likely to cause > exceptions when using the returned object > * getActiveAttrib - INVALID_VALUE for program==null, will return null > instead of the expected WEBGLActiveInfo object (so does out of range index) > * getActiveUniform - INVALID_VALUE for program==null, will return null > instead of the expected WEBGLActiveInfo object (so does out of range index) > * getAttribLocation - INVALID_VALUE for program==null, should probably > return 0 on error according to the spec, we return -1 which IMO makes much > more sense. If we want this nullable we should probably specify that return > value (-1 is used for too long identifiers) > * getUniform - INVALID_VALUE for program==null, INVALID_OPERATION if > location==null. This will return null on error, so it will require extra > checks regardless of if it is nullable or not > > * attachShader - INVALID_VALUE for program==null or shader==null > * bindAttribLocation - INVALID_VALUE for program==null > * compileShader - INVALID_VALUE for shader==null > * detachShader - INVALID_VALUE for program==null or shader==null > * getProgramParameter - INVALID_VALUE for program==null > * getProgramInfoLog - INVALID_VALUE for program==null > * getShaderParameter - INVALID_VALUE for shader==null > * getShaderInfoLog - INVALID_VALUE for shader==null > * getShaderSource - INVALID_VALUE for shader==null > * getUniformLocation - INVALID_VALUE for program==null > * linkProgram - INVALID_VALUE for program==null > * shaderSource - INVALID_VALUE for shader==null > * validateProgram - INVALID_VALUE for program==null > > In addition to that the following are not very clear how to deal with: > * isBuffer > * isFramebuffer > * isProgram > * isRenderbuffer > * isShader > * isTexture > > They are very different from how they work in regular gl. In regular gl > you pass in an integer and it will tell you if that name is a > texture/buffer/... or not, it never generates an error. In WebGL you pass > in an object of the correct type and the only thing it will tell you is > essentially if the object has been explicitly deleted or not. In our > implementation they are not nullable, so passing null will throw an > exception. The conformance test does not require them to be nullable. > > //Tim > > ------------------------------**----------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ------------------------------**----------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Fri Mar 16 13:34:22 2012 From: gle...@ (Glenn Maynard) Date: Fri, 16 Mar 2012 15:34:22 -0500 Subject: [Public WebGL] Null return values from create* Message-ID: On Fri, Mar 16, 2012 at 12:58 PM, Gregg Tavares (?) wrote: > All the ones below here NEED to continue to allow NULL otherwise they will > start throwing exceptions on context lost when all the createXXX functions > start returning NULL. > I think that's a bit of a design error. If you call eg. createTexture while the context is lost, it should probably return a WebGLTexture with the invalidated flag already set, instead of returning null. This has a few benefits. First, it eliminates the above problem; functions don't need to be nullable when it's not the natural thing to do. Second, it reduces the number of failure cases. Currently, if you do the following, two different things might happen on context loss: tex = ctx.createTexture(); ctx.bindTexture(ctx.TEXTURE_2D, tex); If the context was lost before createTexture is called, tex is null. However, the context might be lost *between* the createTexture and bindTexture calls. If that happens, bindTexture receives a non-null texture whose invalidated flag is set. These cases would be merged, so there's only one error path to worry about. Third, that things like this don't break in subtle, racy ways, because tex is never null: tex = ctx.createTexture(); tex.sourceImageUrl = url; // remember where this came from That reduces the number of ways asynchronous context loss can cause bugs. That's a big win, since the asynchronous nature of context loss is very alien to the platform. This would also be an almost entirely backwards-compatible change, since the null return value case is simply merged into the lost-immediately-after-return case that already exists. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bag...@ Fri Mar 16 13:39:01 2012 From: bag...@ (Patrick Baggett) Date: Fri, 16 Mar 2012 15:39:01 -0500 Subject: [Public WebGL] Null return values from create* In-Reply-To: References: Message-ID: On Fri, Mar 16, 2012 at 3:34 PM, Glenn Maynard wrote: > On Fri, Mar 16, 2012 at 12:58 PM, Gregg Tavares (?) wrote: > >> All the ones below here NEED to continue to allow NULL otherwise they >> will start throwing exceptions on context lost when all the createXXX >> functions start returning NULL. >> > > I think that's a bit of a design error. If you call eg. createTexture > while the context is lost, it should probably return a WebGLTexture with > the invalidated flag already set, instead of returning null. > > This has a few benefits. First, it eliminates the above problem; > functions don't need to be nullable when it's not the natural thing to do. > > Second, it reduces the number of failure cases. Currently, if you do the > following, two different things might happen on context loss: > > tex = ctx.createTexture(); > ctx.bindTexture(ctx.TEXTURE_2D, tex); > > If the context was lost before createTexture is called, tex is null. > However, the context might be lost *between* the createTexture and > bindTexture calls. If that happens, bindTexture receives a non-null > texture whose invalidated flag is set. These cases would be merged, so > there's only one error path to worry about. > > Third, that things like this don't break in subtle, racy ways, because tex > is never null: > > Actually, I think that is a very valid point and definitely eliminates a lot of the strange, racy behavior that would otherwise be horrid to consider in a confident manner. Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Mon Mar 19 05:44:30 2012 From: tim...@ (Tim Johansson) Date: Mon, 19 Mar 2012 13:44:30 +0100 Subject: [Public WebGL] Nullable changes in the spec In-Reply-To: References: <4F63596E.3000403@opera.com> Message-ID: <4F672A2E.1090608@opera.com> On 2012-03-16 18:58, Gregg Tavares (?) wrote: > > > On Fri, Mar 16, 2012 at 8:17 AM, Tim Johansson > wrote: > > > I have gone through the spec and marked the parameters and return > values which must be nullable to pass the conformance test as > nullable. Please verify the change in the spec. > > In many places making them nullable is clearly the right thing to > do as the corresponding gl functions either needs a null value or > silently ignores it. In other cases it is less clear because all > null will do is raise a gl error and potentially result in an > unexpected return value. > > The following cases currently accepts null and will only raise a > gl error when passed null, I placed the most problematic or > confusing ones first: > > * bufferSubData - Does not specify how it deals with data==null, > would probably crash in gl > * readPixels - INVALID_VALUE on pixels==null, clearly stated in > the spec. Would probably crash in gl. If texSubImage, > bufferSubData, uniform*v and vertexAttrib*fv are not nullable I > think this should match them for consistency > > > All the ones below here NEED to continue to allow NULL otherwise they > will start throwing exceptions on context lost when all the createXXX > functions start returning NULL. If the createXXX functions can return null they need to have their return type marked as nullable too. Are there any more functions I missed when adding nullable? Also, even if the following functions allows nullable arguments we need to have a look at the values some of them return when they are passed null. //Tim > * getAttachedShaders - INVALID_VALUE for program==null, returns > null instead of empty list in this case, so it is highly likely to > cause exceptions when using the returned object > * getActiveAttrib - INVALID_VALUE for program==null, will return > null instead of the expected WEBGLActiveInfo object (so does out > of range index) > * getActiveUniform - INVALID_VALUE for program==null, will return > null instead of the expected WEBGLActiveInfo object (so does out > of range index) > * getAttribLocation - INVALID_VALUE for program==null, should > probably return 0 on error according to the spec, we return -1 > which IMO makes much more sense. If we want this nullable we > should probably specify that return value (-1 is used for too long > identifiers) > * getUniform - INVALID_VALUE for program==null, INVALID_OPERATION > if location==null. This will return null on error, so it will > require extra checks regardless of if it is nullable or not > > > * attachShader - INVALID_VALUE for program==null or shader==null > * bindAttribLocation - INVALID_VALUE for program==null > * compileShader - INVALID_VALUE for shader==null > * detachShader - INVALID_VALUE for program==null or shader==null > * getProgramParameter - INVALID_VALUE for program==null > * getProgramInfoLog - INVALID_VALUE for program==null > * getShaderParameter - INVALID_VALUE for shader==null > * getShaderInfoLog - INVALID_VALUE for shader==null > * getShaderSource - INVALID_VALUE for shader==null > * getUniformLocation - INVALID_VALUE for program==null > * linkProgram - INVALID_VALUE for program==null > * shaderSource - INVALID_VALUE for shader==null > * validateProgram - INVALID_VALUE for program==null > > In addition to that the following are not very clear how to deal with: > * isBuffer > * isFramebuffer > * isProgram > * isRenderbuffer > * isShader > * isTexture > > They are very different from how they work in regular gl. In > regular gl you pass in an integer and it will tell you if that > name is a texture/buffer/... or not, it never generates an error. > In WebGL you pass in an object of the correct type and the only > thing it will tell you is essentially if the object has been > explicitly deleted or not. In our implementation they are not > nullable, so passing null will throw an exception. The conformance > test does not require them to be nullable. > > //Tim > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > . > To unsubscribe, send an email to majordomo...@ > with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pau...@ Tue Mar 20 07:32:01 2012 From: pau...@ (Paul Lewis) Date: Tue, 20 Mar 2012 14:32:01 +0000 Subject: [Public WebGL] The state of MRTs Message-ID: Hey, So I was wondering what the state of play is regarding multiple render targets. I understand that they're in the 1.0 specification, but due to lack of ubiquitous hardware support (as in the case of mobile) it's not implemented anywhere. Is my understanding correct? And if it is, are there any plans to either drop it from the spec (which would be a shame since I think it would be extremely helpful) or to encourage implementation on platforms which can support it? Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Tue Mar 20 08:00:08 2012 From: cvi...@ (Cedric Vivier) Date: Tue, 20 Mar 2012 15:00:08 +0000 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 14:32, Paul Lewis wrote: > So I was wondering what the state of play is regarding multiple render > targets. I understand that they're in the 1.0 specification, but due to lack > of ubiquitous hardware support (as in the case of mobile) it's not > implemented anywhere. Are they? We do only expose COLOR_ATTACHMENT0 (as in ES 2.0), or are you thinking about another technique? Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pau...@ Tue Mar 20 08:26:32 2012 From: pau...@ (Paul Lewis) Date: Tue, 20 Mar 2012 15:26:32 +0000 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: I was certainly unclear on if MRTs are explicitly mentioned in the spec, and I haven't been able to validate that claim so that's definitely part of my question. In terms of what I understand the functionality to be, it would be to allow for calling a function analogous to OpenGL's glDrawBuffers with an array of color attachment points, and then GLSL calls with gl_FragColor[i] such that the multiple colour attachments can be written from one shader program. But for sure I don't know if this functionality is actually in the spec, and that's part of what I was hoping to clarify. And if it is not, whether there are any plans to include it or something similar to it. Hoping that makes sense! On Tue, Mar 20, 2012 at 3:00 PM, Cedric Vivier wrote: > On Tue, Mar 20, 2012 at 14:32, Paul Lewis wrote: > > So I was wondering what the state of play is regarding multiple render > > targets. I understand that they're in the 1.0 specification, but due to > lack > > of ubiquitous hardware support (as in the case of mobile) it's not > > implemented anywhere. > > Are they? > We do only expose COLOR_ATTACHMENT0 (as in ES 2.0), or are you > thinking about another technique? > > Regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 20 08:33:03 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 20 Mar 2012 16:33:03 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 3:32 PM, Paul Lewis wrote: > So I was wondering what the state of play is regarding multiple render > targets. I understand that they're in the 1.0 specification, but due to > lack of ubiquitous hardware support (as in the case of mobile) it's not > implemented anywhere. Is my understanding correct? > MRTs are not in the WebGL 1.x specifications. The basics first, MRTs are defined across three desktop OpenGL extensions: - http://www.opengl.org/registry/specs/ARB/draw_buffers.txt This specifies that one can attach multiple color output buffers to a framebuffer and that GLSL may use gl_FragData[N] - http://www.opengl.org/registry/specs/EXT/draw_buffers2.txt Depends on DRAW_BUFFERS, Allows to specify separate blending (enable/disable) and write masks for each color output buffer - http://www.opengl.org/registry/specs/ARB/draw_buffers_blend.txt Depends on DRAW_BUFFER2, Allows to specify separate blend func and blend equation for each color output buffer OpenGL ES defines some MRT extensions: - http://www.khronos.org/registry/gles/extensions/NV/GL_NV_draw_buffers.txt Vendor specific (NV), the equivalent of DRAW_BUFFER for desktops - http://www.khronos.org/registry/gles/extensions/NV/GL_NV_fbo_color_attachments.txt increases the amount of available attachment points (for whatever reason I can't fathom). No OES variant of the DRAW_BUFFERS extension has yet been added, although I proposed it there: http://www.khronos.org/message_boards/viewtopic.php?f=9&t=4699 The (WebGL) powers that be decided that WebGL cannot obtain desktop only graphics features. And since mobiles only support MRTs for Nvidia (and not for Apple as well), WebGL cannot have MRTs. I don't know if the PowerVR chipset family that Apple uses are MRT capable at all (but I suspect they are). I also don't know why an OES_DRAW_BUFFERS hasn't been added to the OpenGL ES extension registry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Tue Mar 20 08:39:47 2012 From: cvi...@ (Cedric Vivier) Date: Tue, 20 Mar 2012 15:39:47 +0000 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 15:26, Paul Lewis wrote: > In terms of what I understand the functionality to be, it?would be to allow > for calling a function?analogous to?OpenGL's glDrawBuffers with an array of > color attachment points, and then GLSL calls with gl_FragColor[i] such that > the multiple colour attachments can be written from one shader program. > But for sure I don't know if this functionality is actually in the spec, and > that's part of what I was hoping to clarify. This functionality is not in the spec. gl_FragColor is not an array in GLSL ES, and we only expose one color attachment point. > And if it is not, whether there are any plans to include it or something similar to it. There is no plan that I know of currently. It could possibly be exposed as an extension though. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 20 08:49:36 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 20 Mar 2012 16:49:36 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 4:39 PM, Cedric Vivier wrote: > It could possibly be exposed as an extension though. > It's my interpretation that this would not be possible, because there exists no OES_DRAW_BUFFERS extension for OpenGL ES. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Tue Mar 20 08:59:31 2012 From: cvi...@ (Cedric Vivier) Date: Tue, 20 Mar 2012 15:59:31 +0000 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 15:49, Florian B?sch wrote: > On Tue, Mar 20, 2012 at 4:39 PM, Cedric Vivier wrote: >> It could possibly be?exposed as an extension though. > > It's my interpretation that this would not be possible, because there exists > no OES_DRAW_BUFFERS extension for OpenGL ES. GL_ARB_draw_buffers is implementable on ES (this is probably the reason it does not have a ES-specific version). In fact, Tegra (2 or 3?) does support this extension. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 20 09:15:10 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 20 Mar 2012 17:15:10 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 4:59 PM, Cedric Vivier wrote: > GL_ARB_draw_buffers is implementable on ES > The specification process for the OpenGL ES registry seems to follow the following scheme: - "ARB_" -> "OES_" - "EXT_" -> "EXT_" - "_" -> "_" It has not been the practise of the OES registry to introduce ARB extensions. http://www.khronos.org/registry/gles/ If you mean by "implementable" that they could define a GL_OES_draw_buffers extension then yes. But that has not happened yet. (this is probably the > reason it does not have a ES-specific version). > OpenGL ES has copied many ARB OpenGL extensions verbatim. The presence of ARB_draw_buffers would not preclude OES_draw_buffers (see http://www.khronos.org/registry/gles/extensions/OES/OES_blend_equation_separate.txt / http://www.opengl.org/registry/specs/ARB/blend_func_extended.txt etc.) In fact, Tegra (2 or 3?) does support this extension. > No mobile device claims support for OES_draw_buffers (because it doesn't exist). Some mobiles claim support for ARB_draw_buffers, which should be bogus, because it doesn't exist (and never will) in the OpenGL ES registry. - GL_NV_draw_buffers: claimed by 6 devices, mostly Acer, Lenovo and Asus tablets, no Apple. - GL_NV_fbo_color_attachments: claimed by 56 devices (some handsets from motorolla, Samsung and a lot of tablets from Lenovo, Acer, Toshiba etc., no Apple) - GL_ARB_draw_buffers: bogusly claimed by 51 devices (probably just alias to either GL_NV_draw_buffers or GL_NV_fbo_color_attachments) draw_buffers being "implementable" is not the sole criteria for inclusion into WebGL, it's my impression that in order to get an extension to WebGL these criteria have to be fullfilled: - Be present in the OpenGL ES extension registry - Be well supported by mobile devices - Not be vendor specific (NV) GL_ARB_draw_buffers is not in the OpenGL ES extension registry. GL_NV_* is vendor specific. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Mar 20 10:52:59 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Tue, 20 Mar 2012 10:52:59 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 8:39 AM, Cedric Vivier wrote: > > On Tue, Mar 20, 2012 at 15:26, Paul Lewis wrote: > > In terms of what I understand the functionality to be, it would be to > allow > > for calling a function analogous to OpenGL's glDrawBuffers with an array > of > > color attachment points, and then GLSL calls with gl_FragColor[i] such > that > > the multiple colour attachments can be written from one shader program. > > But for sure I don't know if this functionality is actually in the spec, > and > > that's part of what I was hoping to clarify. > > This functionality is not in the spec. > gl_FragColor is not an array in GLSL ES, and we only expose one color > attachment point. gl_FragData is an array and IS part of GLSL ES gl_FragData[0] is the same as gl_FragColor > > > > And if it is not, whether there are any plans to include it or something > similar to it. > > There is no plan that I know of currently. It could possibly be > exposed as an extension though. > > > Regards, > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pau...@ Tue Mar 20 10:59:02 2012 From: pau...@ (Paul Lewis) Date: Tue, 20 Mar 2012 17:59:02 +0000 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: > > gl_FragData is an array and IS part of GLSL ES > > gl_FragData[0] is the same as gl_FragColor > > Interesting. So the question then is whether that could or will be extended? I'd personally appreciate the ability to write to multiple draw buffers but I appreciate the reasons to date that have precluded its inclusion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 20 11:08:53 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 20 Mar 2012 19:08:53 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 6:52 PM, Gregg Tavares (?) wrote: > gl_FragData[0] is the same as gl_FragColor > However without the draw_buffers extension it is illegal to write to gl_FragData[N] where N > 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bco...@ Tue Mar 20 11:15:35 2012 From: bco...@ (Brian Cornell) Date: Tue, 20 Mar 2012 11:15:35 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: Indeed, the spec is all setup to support multiple render targets, but explicitly doesn't (just like ES 2). gl_FragData is an array, and framebufferTexture2D and framebufferRenderbuffer allow you to specify multiple targets in an extensible way. The only thing in the spec that prevents it is the explicit mention that COLOR_ATTACHMENT0 is the only allowed color attachment. I have a feeling this was designed intentionally so that an extension could easily simply define COLOR_ATTACHMENT1 and the spec would be all ready for MRT. Whether anybody will ever implement such an extension for WebGL, or whether it would become standard, I have no idea. I would work on designing whatever it is you are doing not to need MRT unless you don't care about supporting the lowest common denominator (or in this case potentially the majority). -Brian On Tue, Mar 20, 2012 at 10:59 AM, Paul Lewis wrote: > gl_FragData is an array and IS part of GLSL ES >> >> gl_FragData[0] is the same as gl_FragColor >> >> > Interesting. So the question then is whether that could or will be > extended? I'd personally appreciate the ability to write to multiple draw > buffers but I appreciate the reasons to date that have precluded its > inclusion. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Mar 20 11:56:00 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Tue, 20 Mar 2012 11:56:00 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: So I've been meaning to propose this. Here's a first stab https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html Whether there's any chance to get it approved by the group I don't know. Arguments for: *) Multiple render targets are super awesome! Lots, in fact most modern graphics applications use this feature extensively. Supporting it will go a long way to helping adoption of WebGL with more impressive apps. *) It's not really a new feature. No new APIs are added. It's similar to texture fetch in vertex shaders where the max allowed is allowed to be 1. *) It's relatively easy to implement *) It doesn't raise any extra security or validation issues that I know of. Arguments against: *) Some mobile hardware only supports 1 target. I don't really see that as much a valid argument in that some day this feature will be supported one way or another (WebGL 2.0?), at that point the same issue will exist, some hardware will support 0, some 4, some 8, some 16, etc.. Apps that use multiple render targets will have to have fallbacks for hardware that doesn't support the number they ideally need. So, why not just expose it now? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pau...@ Tue Mar 20 12:13:02 2012 From: pau...@ (Paul Lewis) Date: Tue, 20 Mar 2012 19:13:02 +0000 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: <8081868280921685869@unknownmsgid> Well for what it's worth I totally agree on these. Like most of this stuff we have to plan adequate fallbacks for any extension that isn't implemented, so to my mind there aren't many reasons not to implement it for those that can support it. I particularly agree that it should lead to more impressive work that could well help WebGL adoption. On 20 Mar 2012, at 18:56, "Gregg Tavares (?)" wrote: So I've been meaning to propose this. Here's a first stab https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html Whether there's any chance to get it approved by the group I don't know. Arguments for: *) Multiple render targets are super awesome! Lots, in fact most modern graphics applications use this feature extensively. Supporting it will go a long way to helping adoption of WebGL with more impressive apps. *) It's not really a new feature. No new APIs are added. It's similar to texture fetch in vertex shaders where the max allowed is allowed to be 1. *) It's relatively easy to implement *) It doesn't raise any extra security or validation issues that I know of. Arguments against: *) Some mobile hardware only supports 1 target. I don't really see that as much a valid argument in that some day this feature will be supported one way or another (WebGL 2.0?), at that point the same issue will exist, some hardware will support 0, some 4, some 8, some 16, etc.. Apps that use multiple render targets will have to have fallbacks for hardware that doesn't support the number they ideally need. So, why not just expose it now? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 20 14:03:41 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 20 Mar 2012 22:03:41 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 7:56 PM, Gregg Tavares (?) wrote: > So I've been meaning to propose this. Here's a first stab > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html > I think the fbo_color_attachments name is wrong. I used that one back when I wrote my message board entry because NV_draw_buffers wasn't on the extension list (but I saw it show up on device statistics). The correct one would probably be WEBGL_draw_buffers, and it would be permissible to emulate it with ARB_draw_buffers, NV_draw_buffers or NV_fbo_color_attachments. *) It's not really a new feature. No new APIs are added. It's similar to > texture fetch in vertex shaders where the max allowed is allowed to be 1. > Some new API will be required to specify the FBO attachment point. > *) It's relatively easy to implement > I think there might be trouble in getting the HLSL cross compiler to accept N > 0 (at least it's an angleproject update) > I don't really see that as much a valid argument in that some day this > feature will be supported one way or another (WebGL 2.0?), at that point > the same issue will exist, some hardware will support 0, some 4, some 8, > some 16, etc.. Apps that use multiple render targets will have to have > fallbacks for hardware that doesn't support the number they ideally > need. So, why not just expose it now? > I'm all for exposing. On the topic of fallbacks. It would probably be possible to intercept shader source calls and dissect shaders so that the identical API could seamlessly work but instead of using MRT it just draws multiple times invisibly behind. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Mar 20 14:59:31 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Tue, 20 Mar 2012 14:59:31 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 2:03 PM, Florian B?sch wrote: > On Tue, Mar 20, 2012 at 7:56 PM, Gregg Tavares (?) wrote: > >> So I've been meaning to propose this. Here's a first stab >> >> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html >> > I think the fbo_color_attachments name is wrong. I used that one back when > I wrote my message board entry because NV_draw_buffers wasn't on the > extension list (but I saw it show up on device statistics). The correct one > would probably be WEBGL_draw_buffers, and it would be permissible to > emulate it with ARB_draw_buffers, NV_draw_buffers or > NV_fbo_color_attachments. > How it's emulated is relevant as long as it works no? > > > *) It's not really a new feature. No new APIs are added. It's similar to >> texture fetch in vertex shaders where the max allowed is allowed to be 1. >> > Some new API will be required to specify the FBO attachment point. > Why? gl.framebufferRenderbuffer(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT7, gl.RENDERBUFFER, somerenderbuffer); gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT6, gl.TEXTURE_2D, sometexture, 0); What new API is needed? > > >> *) It's relatively easy to implement >> > I think there might be trouble in getting the HLSL cross compiler to > accept N > 0 (at least it's an angleproject update) > > >> I don't really see that as much a valid argument in that some day this >> feature will be supported one way or another (WebGL 2.0?), at that point >> the same issue will exist, some hardware will support 0, some 4, some 8, >> some 16, etc.. Apps that use multiple render targets will have to have >> fallbacks for hardware that doesn't support the number they ideally >> need. So, why not just expose it now? >> > I'm all for exposing. On the topic of fallbacks. It would probably be > possible to intercept shader source calls and dissect shaders so that the > identical API could seamlessly work but instead of using MRT it just draws > multiple times invisibly behind. > I don't think that's possible. Each draw call may effect depth and stencil buffers and so the next call would not do the same thing as the previous. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 20 16:20:46 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 21 Mar 2012 00:20:46 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 10:59 PM, Gregg Tavares (?) wrote: > How it's emulated is relevant as long as it works no? > It's not. You missed the gist of the message. the name draw_buffers is the right name. I think fbo_color_attachment_foo is something nvidia made up. They've since introduced NV_draw_buffers, which at least indicates that OES intends to follow the ARB naming scheme for the functionality. I would think it best not to follow one vendors lone example in naming. > gl.framebufferRenderbuffer(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT7, >>> gl.RENDERBUFFER, somerenderbuffer); >>> >> gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT6, > gl.TEXTURE_2D, sometexture, 0); > What new API is needed? > You're right, got confused there. Nevertheless it has been the practise that enumerants are introduced by extensions on the extension object and do not extend the webgl context. gl.COLOR_ATTACHMENT1 and so forth does not exist in the webgl context. You're either gonna break that principle or derive the enumerants from the extension object. > I don't think that's possible. Each draw call may effect depth and stencil > buffers and so the next call would not do the same thing as the previous. Right, bummer. Still a way to gracefully fall back without too much hassle would be nice. You surely must realize that it's kinda tedious to keep a shader around that uses gl_FragData[N] and then keep N other shaders around one intended to be used for each pass, and have them be maintained/changed in sync. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Mar 20 16:57:53 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Tue, 20 Mar 2012 16:57:53 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 4:20 PM, Florian B?sch wrote: > On Tue, Mar 20, 2012 at 10:59 PM, Gregg Tavares (?) wrote: > >> How it's emulated is relevant as long as it works no? >> > It's not. You missed the gist of the message. the name draw_buffers is the > right name. I think fbo_color_attachment_foo is something nvidia made up. > They've since introduced NV_draw_buffers, which at least indicates that OES > intends to follow the ARB naming scheme for the functionality. I would > think it best not to follow one vendors lone example in naming. > I'm not following. Sorry. draw_buffers deals with backbuffers, not with framebuffers. I'm not proposing adding more drawbuffers. drawbuffers are a very different topic which a much larger API and therefore much more complicated to spec out. > > >> gl.framebufferRenderbuffer(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT7, >>>> gl.RENDERBUFFER, somerenderbuffer); >>>> >>> gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT6, >> gl.TEXTURE_2D, sometexture, 0); >> > What new API is needed? >> > You're right, got confused there. > > Nevertheless it has been the practise that enumerants are introduced by > extensions on the extension object and do not extend the webgl context. > gl.COLOR_ATTACHMENT1 and so forth does not exist in the webgl context. > You're either gonna break that principle or derive the enumerants from the > extension object. > I don't know where that idea came from. OES_texture_float, WEBGL_comressed_texture_s3tc both add enumerants only. This proposal is no different. > > >> I don't think that's possible. Each draw call may effect depth and >> stencil buffers and so the next call would not do the same thing as the >> previous. > > Right, bummer. Still a way to gracefully fall back without too much hassle > would be nice. You surely must realize that it's kinda tedious to keep a > shader around that uses gl_FragData[N] and then keep N other shaders around > one intended to be used for each pass, and have them be maintained/changed > in sync. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 20 17:11:03 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 21 Mar 2012 01:11:03 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Wed, Mar 21, 2012 at 12:57 AM, Gregg Tavares (?) wrote: > I'm not following. Sorry. draw_buffers deals with backbuffers, not with > framebuffers. I'm not proposing adding more drawbuffers. drawbuffers are a > very different topic which a much larger API and therefore much more > complicated to spec out. > Yeah the specifications are much more complicated because of the legacy drawing buffers. But they also introduced the gl_FragData[N] mechanism to OpenGL. So what is the canonical direction that OES is taking with the naming and scope? Is there going to be some nice and tidy specification just for MRT? > I don't know where that idea came from. OES_texture_float, > WEBGL_comressed_texture_s3tc both add enumerants only. This proposal is no > different. OES_texture_float adds no symbol whatsoever (empty IDL) because it uses the enumerants already present. WEBGL_compressed_texture_s3tc does not add enumerants to the context, but to the extension object. The naming is also postfixed with _EXT. So the correct example would be: gl.framebufferTexture2D(gl.FRAMEBUFFER, mrt_extension_object.COLOR_ATTACHMENT6_EXT, gl.TEXTURE_2D, sometexture, 0); -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Mar 21 01:21:34 2012 From: bja...@ (Benoit Jacob) Date: Wed, 21 Mar 2012 01:21:34 -0700 (PDT) Subject: [Public WebGL] The state of MRTs In-Reply-To: Message-ID: <89606926.15009354.1332318094095.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > So I've been meaning to propose this. Here's a first stab > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html > Whether there's any chance to get it approved by the group I don't > know. > Arguments for: > *) Multiple render targets are super awesome! Lots, in fact most > modern graphics applications use this feature extensively. > Supporting it will go a long way to helping adoption of WebGL with > more impressive apps. > *) It's not really a new feature. No new APIs are added. It's similar > to texture fetch in vertex shaders where the max allowed is allowed > to be 1. > *) It's relatively easy to implement > *) It doesn't raise any extra security or validation issues that I > know of. > Arguments against: > *) Some mobile hardware only supports 1 target. > I don't really see that as much a valid argument in that some day > this feature will be supported one way or another (WebGL 2.0?), at > that point the same issue will exist, some hardware will support 0, > some 4, some 8, some 16, etc.. Apps that use multiple render targets > will have to have fallbacks for hardware that doesn't support the > number they ideally need. So, why not just expose it now? Like for the other extensions that we recently agreed on, what would probably help the most to get multiple render targets accepted would be detailed analysis of what current mobile hardware can't support them, and what is the prospect for the near future. Then we'll be able to see if a compromise with portability makes sense. Sorry if that analysis was already done in this thread, I admit I didn't read all of it. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 21 08:20:01 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 21 Mar 2012 16:20:01 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: <89606926.15009354.1332318094095.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <89606926.15009354.1332318094095.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 21, 2012 at 9:21 AM, Benoit Jacob wrote: > Like for the other extensions that we recently agreed on, what would > probably help the most to get multiple render targets accepted would be > detailed analysis of what current mobile hardware can't support them, and > what is the prospect for the near future. Then we'll be able to see if a > compromise with portability makes sense. Sorry if that analysis was already > done in this thread, I admit I didn't read all of it. > On desktops the core functionality is provided by the ARB_framebuffer_object that defines gl_FragData[N] to be valid and introduces the enumerants for GL_MAX_COLOR_ATTACHMENTS_EXT as well as COLOR_ATTACHMENT0 trough 15 On OpenGL ES the OES_framebuffer_object specifically excludes MRT (gl_FragData[N] and enumerants) from the extension. They are introduced by NV_draw_buffers and NV_fbo_color_attachments (independently) On Direct3D the the number of render targets is found in D3DCAPS9.NumSumultaneousRTs. *Desktop support* - ARB_framebuffer_object: 80% (users, source [1]) - GL_MAX_COLOR_ATTACHMENTS_EXT: greater or equal 4 = 99.2%, greater 4 = 95.1% (users, source [2]) - NumSimultaneousRTs via amsnet: 1 = 53%, 4 = 45% (devices, source [3]) - NumSimultaneousRTs via CardCaps.xls in the DxSDK 2010: 1 = 12%, 4=87% (devices, source [4] *Mobile support* (505 devices, source [5]): - NV_draw_buffers 2.3% (12 devices) - NV_fbo_color_attachment 13.6% (69 devices) - Both: 13.6% (69 devices) *Sources*: [1] http://feedback.wildfiregames.com/report/opengl/ [2] http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_COLOR_ATTACHMENTS_EXT [3] http://zp.amsnet.pl/cdragan/query.php?dxversion=9&feature=capabilities&featuregroup=selected&adaptergroup=all&featureselected%5B%5D=294&orientation=horizontal [4] http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6812 [5] http://www.glbenchmark.com/ *Attachments*: - popular-march-21-2012.txt: A listing of all extensions found on [5] sorted by number of devices and showing the count since the last snapshot as well as differences in counts. - support_nv_draw_buffers.txt: A list of devices supporting NV_draw_buffers. - support_nv_fbo_color_attachments.txt: A list of devices supporting NV_fbo_color_attachments -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 505 Devices, 132 new since Jan. 27 March 21 | Jan. 27 | abs delta | new | updated | dropped | name -------------------------------------------------------------------------------------- 494 | 377 | 117 | 129 | 0 | 12 | GL_OES_compressed_ETC1_RGB8_texture 493 | 377 | 116 | 128 | 0 | 12 | GL_OES_EGL_image 470 | 358 | 112 | 123 | 1 | 12 | GL_EXT_texture_format_BGRA8888 460 | 352 | 108 | 116 | 2 | 10 | GL_OES_rgb8_rgba8 446 | 345 | 101 | 111 | 0 | 10 | GL_OES_vertex_half_float 434 | 328 | 106 | 118 | 0 | 12 | GL_OES_depth24 429 | 326 | 103 | 115 | 0 | 12 | GL_OES_packed_depth_stencil 429 | 326 | 103 | 115 | 0 | 12 | GL_OES_depth_texture 417 | 321 | 96 | 106 | 0 | 10 | GL_OES_texture_half_float 417 | 321 | 96 | 106 | 0 | 10 | GL_OES_texture_float 407 | 301 | 106 | 113 | 5 | 12 | GL_OES_standard_derivatives 377 | 288 | 89 | 99 | 0 | 10 | GL_OES_fragment_precision_high 353 | 268 | 85 | 95 | 0 | 10 | GL_OES_element_index_uint 345 | 262 | 83 | 93 | 0 | 10 | GL_OES_get_program_binary 297 | 226 | 71 | 77 | 1 | 7 | GL_OES_fbo_render_mipmap 295 | 224 | 71 | 77 | 1 | 7 | GL_EXT_texture_filter_anisotropic 288 | 213 | 75 | 84 | 0 | 9 | GL_OES_texture_npot 240 | 156 | 84 | 80 | 9 | 5 | GL_OES_EGL_image_external 222 | 166 | 56 | 64 | 0 | 8 | GL_OES_texture_half_float_linear 220 | 163 | 57 | 64 | 0 | 7 | GL_OES_texture_3D 219 | 163 | 56 | 63 | 0 | 7 | GL_AMD_program_binary_Z400 219 | 163 | 56 | 63 | 0 | 7 | GL_NV_fence 219 | 163 | 56 | 63 | 0 | 7 | GL_AMD_compressed_3DC_texture 219 | 163 | 56 | 63 | 0 | 7 | GL_OES_vertex_type_10_10_10_2 219 | 163 | 56 | 63 | 0 | 7 | GL_EXT_texture_type_2_10_10_10_REV 219 | 163 | 56 | 63 | 0 | 7 | GL_AMD_performance_monitor 219 | 163 | 56 | 63 | 0 | 7 | GL_AMD_compressed_ATC_texture 215 | 160 | 55 | 62 | 0 | 7 | GL_QCOM_perfmon_global_mode 215 | 160 | 55 | 62 | 0 | 7 | GL_QCOM_tiled_rendering 215 | 160 | 55 | 62 | 0 | 7 | GL_QCOM_writeonly_rendering 215 | 160 | 55 | 62 | 0 | 7 | GL_QCOM_driver_control 215 | 160 | 55 | 62 | 0 | 7 | GL_QCOM_extended_get2 215 | 160 | 55 | 62 | 0 | 7 | GL_QCOM_extended_get 207 | 164 | 43 | 46 | 1 | 4 | GL_OES_mapbuffer 199 | 156 | 43 | 50 | 0 | 7 | GL_QCOM_memory_monitor 175 | 124 | 51 | 56 | 3 | 8 | GL_QCOM_binning_control 148 | 129 | 19 | 22 | 0 | 3 | GL_OES_compressed_paletted_texture 146 | 98 | 48 | 43 | 8 | 3 | GL_OES_vertex_array_object 135 | 105 | 30 | 31 | 2 | 3 | GL_EXT_discard_framebuffer 134 | 107 | 27 | 30 | 1 | 4 | GL_IMG_texture_format_BGRA8888 132 | 105 | 27 | 30 | 0 | 3 | GL_IMG_texture_compression_pvrtc 132 | 105 | 27 | 30 | 0 | 3 | GL_IMG_read_format 126 | 99 | 27 | 30 | 0 | 3 | GL_EXT_multi_draw_arrays 123 | 97 | 26 | 29 | 0 | 3 | GL_IMG_program_binary 123 | 97 | 26 | 29 | 0 | 3 | GL_IMG_shader_binary 123 | 97 | 26 | 29 | 0 | 3 | GL_IMG_texture_npot 123 | 97 | 26 | 29 | 0 | 3 | GL_OES_required_internalformat 114 | 89 | 25 | 29 | 0 | 4 | GL_EXT_shader_texture_lod 111 | 93 | 18 | 20 | 0 | 2 | GL_IMG_texture_stream2 110 | 99 | 11 | 14 | 0 | 3 | GL_OES_matrix_palette 110 | 99 | 11 | 14 | 0 | 3 | GL_OES_draw_texture 109 | 99 | 10 | 13 | 0 | 3 | GL_OES_framebuffer_object 108 | 97 | 11 | 14 | 0 | 3 | GL_OES_point_size_array 108 | 83 | 25 | 28 | 0 | 3 | GL_OES_egl_sync 108 | 97 | 11 | 14 | 0 | 3 | GL_OES_read_format 108 | 97 | 11 | 14 | 0 | 3 | GL_OES_point_sprite 107 | 83 | 24 | 28 | 0 | 4 | GL_IMG_multisampled_render_to_texture 100 | 91 | 9 | 12 | 0 | 3 | GL_OES_texture_cube_map 94 | 76 | 18 | 17 | 1 | 0 | GL_EXT_texture_compression_s3tc 92 | 74 | 18 | 17 | 1 | 0 | GL_EXT_texture_compression_dxt1 90 | 80 | 10 | 13 | 0 | 3 | GL_OES_blend_func_separate 89 | 80 | 9 | 12 | 0 | 3 | GL_OES_blend_subtract 89 | 80 | 9 | 12 | 0 | 3 | GL_OES_blend_equation_separate 89 | 80 | 9 | 12 | 0 | 3 | GL_OES_texture_mirrored_repeat 89 | 80 | 9 | 12 | 0 | 3 | GL_OES_stencil_wrap 86 | 77 | 9 | 9 | 0 | 0 | GL_OES_extended_matrix_palette 83 | 45 | 38 | 35 | 4 | 1 | GL_QCOM_alpha_test 83 | 75 | 8 | 11 | 0 | 3 | GL_OES_texture_env_crossbar 77 | 56 | 21 | 21 | 2 | 2 | GL_OES_EGL_sync 73 | 58 | 15 | 14 | 1 | 0 | GL_EXT_bgra 71 | 54 | 17 | 17 | 2 | 2 | GL_EXT_blend_minmax 69 | 55 | 14 | 13 | 1 | 0 | GL_EXT_Cg_shader 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_coverage_sample 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_fbo_color_attachments 69 | 55 | 14 | 13 | 1 | 0 | GL_EXT_texture_compression_latc 69 | 55 | 14 | 13 | 1 | 0 | GL_EXT_packed_float 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_shader_framebuffer_fetch 69 | 55 | 14 | 13 | 1 | 0 | GL_EXT_unpack_subimage 69 | 55 | 14 | 13 | 1 | 0 | GL_EXT_texture_array 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_draw_path 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_depth_nonlinear 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_get_tex_image 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_read_buffer 69 | 55 | 14 | 13 | 1 | 0 | GL_NV_platform_binary 62 | 51 | 11 | 10 | 1 | 0 | GL_ARB_draw_buffers 62 | 51 | 11 | 10 | 1 | 0 | GL_NV_framebuffer_vertex_attrib_array 56 | 51 | 5 | 5 | 0 | 0 | GL_OES_stencil8 53 | 48 | 5 | 5 | 0 | 0 | GL_OES_query_matrix 53 | 48 | 5 | 5 | 0 | 0 | GL_OES_matrix_get 51 | 46 | 5 | 5 | 0 | 0 | GL_OES_byte_coordinates 50 | 46 | 4 | 4 | 0 | 0 | GL_OES_single_precision 50 | 46 | 4 | 4 | 0 | 0 | GL_OES_fixed_point 49 | 40 | 9 | 9 | 0 | 0 | GL_NV_texture_npot_2D_mipmap 48 | 35 | 13 | 16 | 0 | 3 | GL_ARM_rgba8 46 | 33 | 13 | 16 | 0 | 3 | GL_ARM_mali_shader_binary 43 | 34 | 9 | 8 | 1 | 0 | GL_NV_texture_compression_s3tc_update 37 | 32 | 5 | 5 | 0 | 0 | GL_ARB_vertex_buffer_object 36 | 31 | 5 | 5 | 0 | 0 | GL_ATI_texture_compression_atitc 36 | 30 | 6 | 6 | 0 | 0 | GL_EXT_blend_func_separate 36 | 31 | 5 | 5 | 0 | 0 | GL_ATI_compressed_texture_atitc 35 | 30 | 5 | 5 | 0 | 0 | GL_EXT_blend_subtract 35 | 30 | 5 | 5 | 0 | 0 | GL_EXT_stencil_wrap 35 | 30 | 5 | 5 | 0 | 0 | GL_EXT_blend_equation_separate 35 | 30 | 5 | 5 | 0 | 0 | GL_ARB_texture_env_dot3 35 | 30 | 5 | 5 | 0 | 0 | GL_ARB_texture_env_combine 35 | 30 | 5 | 5 | 0 | 0 | GL_ARB_texture_mirrored_repeat 34 | 28 | 6 | 6 | 0 | 0 | GL_VIV_shader_binary 34 | 28 | 6 | 6 | 0 | 0 | GL_OES_stencil4 34 | 28 | 6 | 6 | 0 | 0 | GL_OES_stencil1 31 | 29 | 2 | 2 | 0 | 0 | GL_IMG_texture_stream 23 | 20 | 3 | 6 | 0 | 3 | GL_APPLE_texture_2D_limited_npot 21 | 21 | 0 | 0 | 0 | 0 | GL_IMG_vertex_array_object 20 | 18 | 2 | 2 | 0 | 0 | GL_IMG_vertex_program 12 | 5 | 7 | 4 | 3 | 0 | GL_NV_draw_buffers 12 | 5 | 7 | 4 | 3 | 0 | GL_NV_multiview_draw_buffers 12 | 5 | 7 | 4 | 3 | 0 | GL_NV_read_stencil 12 | 5 | 7 | 4 | 3 | 0 | GL_NV_read_depth 10 | 1 | 9 | 4 | 5 | 0 | GL_EXT_robustness 10 | 1 | 9 | 4 | 5 | 0 | GL_NV_texture_compression_latc 10 | 1 | 9 | 4 | 5 | 0 | GL_NV_texture_compression_s3tc 10 | 1 | 9 | 4 | 5 | 0 | GL_NV_EGL_stream_consumer_external 10 | 1 | 9 | 4 | 5 | 0 | GL_NV_pack_subimage 9 | 8 | 1 | 1 | 0 | 0 | GL_EXT_read_format_bgra 9 | 8 | 1 | 1 | 0 | 0 | GL_APPLE_texture_max_level 9 | 8 | 1 | 1 | 0 | 0 | GL_ARB_texture_non_power_of_two 9 | 8 | 1 | 1 | 0 | 0 | GL_APPLE_rgb_422 9 | 8 | 1 | 1 | 0 | 0 | GL_APPLE_texture_format_BGRA8888 8 | 0 | 8 | 7 | 1 | 0 | GL_EXT_sRGB 7 | 6 | 1 | 1 | 0 | 0 | GL_EXT_debug_marker 7 | 6 | 1 | 1 | 0 | 0 | GL_APPLE_framebuffer_multisample 7 | 3 | 4 | 3 | 2 | 1 | GL_EXT_occlusion_query_boolean 7 | 6 | 1 | 1 | 0 | 0 | GL_EXT_separate_shader_objects 7 | 6 | 1 | 1 | 0 | 0 | GL_EXT_debug_label 6 | 5 | 1 | 1 | 0 | 0 | GL_EXT_texture_lod_bias 4 | 1 | 3 | 0 | 3 | 0 | GL_EXT_multisampled_render_to_texture 4 | 0 | 4 | 2 | 2 | 0 | GL_NV_timer_query 4 | 3 | 1 | 1 | 0 | 0 | GL_AMD_tiled_rendering 3 | 3 | 0 | 1 | 0 | 1 | GL_EXT_color_buffer_half_float 3 | 2 | 1 | 1 | 0 | 0 | GL_OES_depth32 3 | 3 | 0 | 1 | 0 | 1 | GL_EXT_shadow_samplers 3 | 4 | -1 | 0 | 0 | 1 | GL_NV_robustness 3 | 3 | 0 | 1 | 0 | 1 | GL_EXT_texture_rg 2 | 2 | 0 | 0 | 0 | 0 | GL_APPLE_debug_label 2 | 2 | 0 | 0 | 0 | 0 | GL_VIV_timestamp 2 | 2 | 0 | 0 | 0 | 0 | GL_ANDROID_direct_texture 2 | 2 | 0 | 0 | 0 | 0 | GL_MRVL_blur 2 | 0 | 2 | 2 | 0 | 0 | GL_NV_copy_image 2 | 2 | 0 | 0 | 0 | 0 | GL_MRVL_external_texture 2 | 2 | 0 | 0 | 0 | 0 | GL_VIV_direct_texture 2 | 2 | 0 | 0 | 0 | 0 | GL_EXT_frag_depth 2 | 2 | 0 | 0 | 0 | 0 | GL_APPLE_debug_marker 2 | 0 | 2 | 2 | 0 | 0 | GL_NV_3dvision_settings 1 | 0 | 1 | 1 | 0 | 0 | GL_ZIILABS_get_cbuffer_pointer 1 | 0 | 1 | 1 | 0 | 0 | GL_EXT_texture_compression_dxt 1 | 0 | 1 | 0 | 1 | 0 | GL_GREMEDY_frame_terminator 1 | 1 | 0 | 0 | 0 | 0 | GL_NV_unpack_subimage 1 | 0 | 1 | 0 | 1 | 0 | GL_GREMEDY_string_marker 1 | 1 | 0 | 0 | 0 | 0 | GL_EXT_texture_2D_limited_npot 1 | 0 | 1 | 1 | 0 | 0 | GL_ZIILABS_fog_mask -------------- next part -------------- Acer A700 (picasso 2) Acer Iconia Tab A200 Acer Iconia Tab A500 Acer Iconia Tab A510 Advent Vega Asus Eee Pad Transformer Prime TF201 Asus Eee Pad Transformer TF101 HTC Endeavoru One X HTC One X Lenovo LePad K2 Malata SMB-A1002 Samsung GT-P7510 Galaxy Tab -------------- next part -------------- Acer A700 (picasso 2) Acer G100W Acer Iconia Tab A100 Acer Iconia Tab A101 Acer Iconia Tab A200 Acer Iconia Tab A500 Acer Iconia Tab A501 Acer Iconia Tab A510 Acer Picasso Advent Vega Asus Eee Pad Slider SL101 Asus Eee Pad Transformer Prime TF201 Asus Eee Pad Transformer TF101 Dell Streak 10 Pro Dell Streak 7 Hisense M1101AS Hisense M170AT HTC Endeavoru One X HTC One X iRU Pad Master 10.1 K-Touch Micromax A85 harmony K-Touch W700 Lenovo IdeaPad Tablet K1 Lenovo LePad K2 Lenovo ThinkPad Tablet LG LU6500 LG Optimus Pad LG P990 Optimus 2X LG P999 LG SU660 Star Dop LG SU880 LG V901 LG V909 Malata SMB-A1002 Malata Zpad Medion LifeTab P9514 Motorola Droid X2 Motorola Electrify Motorola MB855 Photon Motorola MB860 ATRIX 4G Motorola MB865 Motorola MT870 Motorola MZ505 Motorola MZ601 Motorola MZ604 Motorola Xoom Motorola XT882 Notion Ink Adam Quanta LIFETAB_P9514_de Samsung GT-I9103 Samsung GT-I9500 Samsung GT-P7300 Samsung GT-P7310 Samsung GT-P7500 Samsung GT-P7501 Galaxy Tab 10.1N Samsung GT-P7510 Galaxy Tab Samsung SCH-I905 Samsung SGH-927R Galaxy S Glide Samsung SGH-I927 Samsung SHW-M305W Galaxy Tab 8.9 WiFi Samsung SHW-M380S Galaxy Tab 10.1 3G Sony NW-Z1000 Sony Tablet P Sony Tablet S Toshiba AC100 Dynabook AZ Toshiba AT100 Toshiba Folio 100 Toshiba Thrive 7 (AT1S0) ViewSonic G Tablet From bja...@ Wed Mar 21 08:29:56 2012 From: bja...@ (Benoit Jacob) Date: Wed, 21 Mar 2012 08:29:56 -0700 (PDT) Subject: [Public WebGL] The state of MRTs In-Reply-To: Message-ID: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Wed, Mar 21, 2012 at 9:21 AM, Benoit Jacob < bjacob...@ > > wrote: > > Like for the other extensions that we recently agreed on, what > > would > > probably help the most to get multiple render targets accepted > > would > > be detailed analysis of what current mobile hardware can't support > > them, and what is the prospect for the near future. Then we'll be > > able to see if a compromise with portability makes sense. Sorry if > > that analysis was already done in this thread, I admit I didn't > > read > > all of it. > > On desktops the core functionality is provided by the > ARB_framebuffer_object ARB_framebuffer_object is, in my understanding, a hard requirement to be able to implement WebGL, as framebuffer objects are part of the WebGL API. So, this implies that support for multiple render targets is ubiquitous on desktop GL, except of course that GL_MAX_COLOR_ATTACHMENTS_EXT might be 1. > On Direct3D the the number of render targets is found in > D3DCAPS9.NumSumultaneousRTs. Nice, so the situation seems entirely clear on the desktop. > Mobile support (505 devices, source [5]): > - NV_draw_buffers 2.3% (12 devices) > - NV_fbo_color_attachment 13.6% (69 devices) > - Both: 13.6% (69 devices) Ouch. 13.6% is very little. Is the percentage much higher if we include only GPUs that still ship in new devices today? Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From adu...@ Mon Mar 26 18:51:18 2012 From: adu...@ (Alan DuBoff) Date: Mon, 26 Mar 2012 18:51:18 -0700 (PDT) Subject: [Public WebGL] Extensions Message-ID: Hi, new to this list and was looking for an archive, but don't seem to see one. I was trying to understand how the WebGL extensions work. On my android refernece I have the Android Browser, Firefox, and Opera. I'm using a modified version of the Sony WebGL code which was released a couple months ago, and I have it working on my omap device. I see different extensions available in each browser when testing each of them against the following URL: http://analyticalgraphicsinc.github.com/webglreport What is not clear to me is if I can add extensions to the Android Browser myself, and if so, how would I go about that? As an example, this is what I see on my browsers: Android: WEBKIT_lose_context Opera: OES_standard_derivatives Firefox: NONE In comparison, I see this following on the Chrome browser: Chrome on Linux: OES_texture_float, OES_standard_derivatives, WEBKIT_lose_context, WEBKIT_WEBGL_compressed_textures How would one go about adding those extensions to the Android browser? It seems that the implementation is done in the OpenGL or OpenGL ES code, so that they must be in the libraries before one adds in more IDLs...but that part is not clear. Any tips would be appreciated, I'm a bit new to working with the browser extensions.:-( -- Alan DuBoff - Android Development Fujitsu Labs America ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 27 01:49:12 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 27 Mar 2012 10:49:12 +0200 Subject: [Public WebGL] Extensions In-Reply-To: References: Message-ID: On Tue, Mar 27, 2012 at 3:51 AM, Alan DuBoff wrote: > I was trying to understand how the WebGL extensions work. What is not clear to me is if I can add extensions to the Android Browser > myself, and if so, how would I go about that? > OpenGL ES exposes a number of extensions: http://www.khronos.org/registry/gles/ A small subset of those (roughly) is defined for WebGL: http://www.khronos.org/registry/webgl/extensions/ If you want to introduce an extension to a browser you're distributing, you've got to modify that browsers webgl context implementation (gl = canvas.getContext('experimental-webgl')) and provide: - extension = gl.getExtension(name) -> returns the extension object - gl.getSupportedExtensions() -> a list of strings of supported extension names - extension -> an object containing whatever enumerants and symbols required by the extension In some cases an extension changes the behavior of existing functions, which mostly affects error validation on passed arguments (for instance texImage2D for float textures). As an example of how an extension was introduced (to Firefox) see this bug thread: https://bugzilla.mozilla.org/show_bug.cgi?id=728354 In case you're planing on adding a new extension of your own, please consult the ML-archives and grep for my email (pyalot...@) and anisotropic filtering, in short the process is: - propose an extension as IDL - post it to the ML - see if we can reach a consensus over the standardization of it, and it can move to draft - at that point vendors should be free to implement it -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Mar 27 11:31:14 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 27 Mar 2012 11:31:14 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Sorry for coming to this discussion late -- was traveling. It appears that only a tiny fraction of mobile devices support multiple render targets today, and it looks like there's no cross-vendor extension that could improve that situation in the short term. For this reason, I think the WebGL WG should defer adding this functionality to the extension registry and implementations. If application developers make their content work with the current spec they'll achieve maximum portability on current devices. In the short term, I think the WG should focus on items for the next version of the spec and implementation improvements: specifically, resource sharing between contexts, access to WebGL from workers, optional asynchronous context creation, performance improvements, and better robustness to DoS issues. -Ken On Wed, Mar 21, 2012 at 8:29 AM, Benoit Jacob wrote: > > > ________________________________ > > On Wed, Mar 21, 2012 at 9:21 AM, Benoit Jacob wrote: >> >> Like for the other extensions that we recently agreed on, what would >> probably help the most to get multiple render targets accepted would be >> detailed analysis of what current mobile hardware can't support them, and >> what is the prospect for the near future. Then we'll be able to see if a >> compromise with portability makes sense. Sorry if that analysis was already >> done in this thread, I admit I didn't read all of it. > > > On desktops the core functionality is provided by the ARB_framebuffer_object > > ARB_framebuffer_object is, in my understanding, a hard requirement to be > able to implement WebGL, as framebuffer objects are part of the WebGL API. > So, this implies that support for multiple render targets is ubiquitous on > desktop GL, except of course that GL_MAX_COLOR_ATTACHMENTS_EXT might be 1. > > On Direct3D the the number of render targets is found in > D3DCAPS9.NumSumultaneousRTs. > > Nice, so the situation seems entirely clear on the desktop. > > > Mobile support (505 devices, source [5]): > - NV_draw_buffers ?2.3% (12 devices) > - NV_fbo_color_attachment 13.6% (69 devices) > - Both: 13.6% (69 devices) > > Ouch. 13.6% is very little. Is the percentage much higher if we include only > GPUs that still ship in new devices today? > > Benoit > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 27 12:10:24 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 27 Mar 2012 21:10:24 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 27, 2012 at 8:31 PM, Kenneth Russell wrote: > It appears that only a tiny fraction of mobile devices support > multiple render targets today, and it looks like there's no > cross-vendor extension that could improve that situation in the short > term. The core issue it would seem is that the OpenGL ES registry is not defining a cross-vendor MRT extension of any sort. I strongly suspected that in principle more devices than those supporting NV_draw_buffers and NV_fbo_color_attachment can do MRT (for instance the PowerVR chipset family claims in its latest incarnation to be DX10/OpenGL 3 compatible). -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Mar 27 12:38:57 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Tue, 27 Mar 2012 12:38:57 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 27, 2012 at 11:31 AM, Kenneth Russell wrote: > Sorry for coming to this discussion late -- was traveling. > > It appears that only a tiny fraction of mobile devices support > multiple render targets today, and it looks like there's no > cross-vendor extension that could improve that situation in the short > term. For this reason, I think the WebGL WG should defer adding this > functionality to the extension registry and implementations. If > application developers make their content work with the current spec > they'll achieve maximum portability on current devices. > 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. All devices currently support MRT. Low end devices support N render targets where N = 1. 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. > > In the short term, I think the WG should focus on items for the next > version of the spec and implementation improvements: specifically, > resource sharing between contexts, access to WebGL from workers, > optional asynchronous context creation, performance improvements, MRT is a perf improvement. A huge one. > and > better robustness to DoS issues. > -Ken > > > On Wed, Mar 21, 2012 at 8:29 AM, Benoit Jacob wrote: > > > > > > ________________________________ > > > > On Wed, Mar 21, 2012 at 9:21 AM, Benoit Jacob > wrote: > >> > >> Like for the other extensions that we recently agreed on, what would > >> probably help the most to get multiple render targets accepted would be > >> detailed analysis of what current mobile hardware can't support them, > and > >> what is the prospect for the near future. Then we'll be able to see if a > >> compromise with portability makes sense. Sorry if that analysis was > already > >> done in this thread, I admit I didn't read all of it. > > > > > > On desktops the core functionality is provided by the > ARB_framebuffer_object > > > > ARB_framebuffer_object is, in my understanding, a hard requirement to be > > able to implement WebGL, as framebuffer objects are part of the WebGL > API. > > So, this implies that support for multiple render targets is ubiquitous > on > > desktop GL, except of course that GL_MAX_COLOR_ATTACHMENTS_EXT might be > 1. > > > > On Direct3D the the number of render targets is found in > > D3DCAPS9.NumSumultaneousRTs. > > > > Nice, so the situation seems entirely clear on the desktop. > > > > > > Mobile support (505 devices, source [5]): > > - NV_draw_buffers 2.3% (12 devices) > > - NV_fbo_color_attachment 13.6% (69 devices) > > - Both: 13.6% (69 devices) > > > > Ouch. 13.6% is very little. Is the percentage much higher if we include > only > > GPUs that still ship in new devices today? > > > > Benoit > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 27 12:52:03 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 27 Mar 2012 21:52:03 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 27, 2012 at 9:38 PM, Gregg Tavares (?) wrote: > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ara...@ Tue Mar 27 13:34:02 2012 From: ara...@ (Alan DuBoff) Date: Tue, 27 Mar 2012 13:34:02 -0700 (PDT) Subject: [Public WebGL] Extensions Message-ID: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> On Tue, 27 Mar 2012, Florian B?sch wrote: > In case you're planing on adding a new extension of your own, please consult > the ML-archives and grep for my email (pyalot...@) and anisotropic > filtering, in short the process is: > - propose an extension as IDL > - post it to the ML > - see if we can reach a consensus over the standardization of it, and it can > move to draft > - at that point vendors should be free to implement it Ok, so let's use one of the existing extensions as an example. http://www.khronos.org/registry/webgl/extensions/WEBGL_lose_context/ Per the WebGL Registration Page, this extension is in draft, so is being implemented per your comment above. Or does that happen after the draft is complete? At least since the above is a draft, it looks as though Glenn Maynard is responsible for implementing the code. I'm guessing the code is not available until the extension becomes official, is that correct ??? In the case of the "Official WebGL Extensions", are the following extensions completed already? If so, where would I find the actual implementation? Would they be in the OpenGL or OpenGL ES libraries ??? ????1. OES_texture_float ????2. OES_texture_half_float ????3. OES_standard_derivatives ????4. WEBGL_debug_renderer_info ????5. WEBGL_debug_shaders As an example, where is getTranslatedShaderSource() for WEBGL_debug_shaders ??? I'm not finding that in any of the opengl code. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 27 13:52:08 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 27 Mar 2012 22:52:08 +0200 Subject: [Public WebGL] Extensions In-Reply-To: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> References: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> Message-ID: On Tue, Mar 27, 2012 at 10:34 PM, Alan DuBoff wrote: > Per the WebGL Registration Page, this extension is in draft, so is being > implemented per your comment above. Or does that happen after the draft is > complete? > When an extension specification is in draft, the vendors may implement it if they prefix the extension name with a vendor prefix. Vendor in this case means: - Apple (Safari Browser, iOS Browser), prefix WEBKIT_ - Google (Chrome Browser, Android Browser), prefix WEBKIT_ - Mozilla (Firefox Browser, Firefox Mobile Browser), prefix MOZ_ - Opera (Opera Browser, Opera Mobile Browser), prefix OPERA_ > At least since the above is a draft, it looks as though Glenn Maynard is > responsible for implementing the code. I'm guessing the code is not > available until the extension becomes official, is that correct ??? > Glenn Maynard Proposed the specification. Implementation is up to the individual vendors (Google, Apple, Mozilla and Opera). In the case of the "Official WebGL Extensions", are the following > extensions completed already? The extensions you mention are all in status ratified (they're neither drafts nor proposals), so yes. > If so, where would I find the actual implementation? You find the implementations in the code repositories of Google Chrome/Webkit, Firefox and Opera etc. > Would they be in the OpenGL or OpenGL ES libraries ??? > The extensions prefixed with OES_ are ported from the OpenGL ES extension registry. the ones prefixed with WEBGL_ are specific to webgl. As an example, where is getTranslatedShaderSource() for WEBGL_debug_shaders > ??? I'm not finding that in any of the opengl code. This is specific to webgl because there is a translator that translates the GLSL source to HLSL or Desktop GLSL. If you're writing against a native ES backend, the translated source would be the same. ??? > Quotation marks are usually not grouped to triplets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Tue Mar 27 14:01:37 2012 From: gle...@ (Glenn Maynard) Date: Tue, 27 Mar 2012 16:01:37 -0500 Subject: [Public WebGL] Extensions In-Reply-To: References: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> Message-ID: On Tue, Mar 27, 2012 at 3:52 PM, Florian B?sch wrote: > Glenn Maynard Proposed the specification. Implementation is up to the >> individual vendors (Google, Apple, Mozilla and Opera). > > I just offered input; the editor is enne...@ (By the way, that should probably have a name attached.) -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Mar 27 14:17:00 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 27 Mar 2012 23:17:00 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 27, 2012 at 11:01 PM, Marco Di Benedetto wrote: > MRT is NOT ONLY a matter of defining GL_COLOR_ATTACHMENTi, i > 0. > As I wrote in a couple of mails (that seem to have been ignored...) in > this thread, there are functionalities exposed glDrawBuffers() that are > extremely handy, that allow to decouple shaders from algorithms, and that > are at the core of MRT. > Simply defining other enums without glDrawBuffers() doesn't "give justice" > to MRT idea. > Nonetheless, to strictly define MRT including glDrawBuffers() is not > complex, even if not as easy as just increasing N. > The original FBO extension (ARB_framebuffer_object, http://www.opengl.org/registry/specs/ARB/framebuffer_object.txt) defines the behavior of gl_FragData[N], COLOR_ATTACHMENT0 trough 15 for texture attachment points as well as the get parameter MAX_COLOR_ATTACHMENTS. This elegantly sidestepped the issue of having to define another extension to specifically allow for MRT by "future proofing" it already with FBOs. This example was not followed by the ES WG which specifically excluded MRT features from the FBO specification. I see no good reason for this decision and evidently it now leads to more discussion and more work all around. I do not have insight into the ES WGs reasoning for this, so that's where illumination would be helpful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adu...@ Tue Mar 27 14:38:05 2012 From: adu...@ (Alan DuBoff) Date: Tue, 27 Mar 2012 14:38:05 -0700 (PDT) Subject: [Public WebGL] unsubscribe public_webgl In-Reply-To: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> References: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> Message-ID: unsubscribe public_webgl ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Mar 27 14:43:36 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 27 Mar 2012 14:43:36 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 27, 2012 at 2:01 PM, Marco Di Benedetto wrote: > ?On Tue, Mar 27, 2012 at 9:52 PM, Florian B?sch??wrote: > >> 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 is NOT ONLY a matter of defining GL_COLOR_ATTACHMENTi, i > 0. > As I wrote in a couple of mails (that seem to have been ignored...)?in this > thread, there are functionalities exposed glDrawBuffers() that are extremely > handy, that allow to decouple shaders from algorithms, and that are at the > core of MRT. > Simply defining other enums without glDrawBuffers() doesn't "give justice" > to MRT idea. > Nonetheless, to strictly define MRT including glDrawBuffers() is not > complex, even if not as easy as just increasing N. > > On Tue, Mar 27, 2012 at 9:52 PM, Florian B?sch??wrote: >>> >>> 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. > > > 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 individual in the WebGL WG has, or should have, the authority to definitively say "no" to any of these proposals. We should collectively come to agreement. The capabilities of mobile GPUs are advancing, and I would not be surprised if MRT support began to appear in that arena. If or when it does, I think that that would be the right time to advance the WebGL specification to add MRT support. In the interim, I personally think it is not the right time to add it. Doing so would fragment the WebGL ecosystem between desktop and mobile devices before it has had a chance to crystallize between them, and I think there are more basic improvements in current implementations that should be made first. -Ken > On Tue, Mar 27, 2012 at 9:52 PM, Florian B?sch wrote: >> >> On Tue, Mar 27, 2012 at 9:38 PM, Gregg Tavares (?) >> wrote: >>> >>> 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 > E-Mail: marco.dibenedetto...@ - spattija...@ > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Mar 27 14:49:25 2012 From: bja...@ (Benoit Jacob) Date: Tue, 27 Mar 2012 14:49:25 -0700 (PDT) Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <978811174.19231241.1332884495722.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <994655469.19265064.1332884965036.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Hello, Here are some WebGL performance regression tests: http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html Like the WebGL conformance tests, they work as standalone Web pages, or can be run by the above test runner all at once. We plan to add many more in the very near future: - more advanced compositing tests - texture conversion tests (these would not even do webgl.finish()) - and most importantly: I think that this is a good basis to developer the "Windows Experience Index" kind of benchmarks that we were recently discussing. Does this look like it's going in the right direction? Is there interest in moving this to a different location that would be easier for non-Mozilla people to write to? Cheers, Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 27 14:51:59 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 27 Mar 2012 23:51:59 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 27, 2012 at 11:43 PM, Kenneth Russell wrote: > The capabilities of mobile GPUs are advancing, and I would not be > surprised if MRT support began to appear in that arena. If or when it > does, I think that that would be the right time to advance the WebGL > specification to add MRT support. > It would be extremely helpful if we knew what the ES plans for MRTs are. The picture looks quite different if say, next month an OES_fbo_color_attachment extension is introduced as opposed to having no plan for any standardized MRT support in ES. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ara...@ Tue Mar 27 14:53:05 2012 From: ara...@ (Alan DuBoff) Date: Tue, 27 Mar 2012 14:53:05 -0700 (PDT) Subject: [Public WebGL] Extensions In-Reply-To: References: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> Message-ID: <1332885185.45050.YahooMailNeo@web125206.mail.ne1.yahoo.com> >> Per the WebGL Registration Page, this extension is in draft, so is being implemented per your comment above. Or does that happen >> after the draft is complete? > When an extension specification is in draft, the vendors may implement it if they prefix the extension name with a vendor prefix. > Vendor in this case means: > - Apple (Safari Browser, iOS Browser), prefix WEBKIT_ > - Google (Chrome Browser, Android Browser), prefix WEBKIT_ > - Mozilla (Firefox Browser, Firefox Mobile Browser), prefix MOZ_ > - Opera (Opera Browser, Opera Mobile Browser), prefix OPERA_ Florian, This makes sense now, thanks for pointing this out. So, in the case when I see WEBKIT_ prefix, it tells me that it is in the Apple webkit sources. Of course this applies to Google also as they use Apple's webkit. >> At least since the above is a draft, it looks as though Glenn Maynard is responsible for implementing the code. I'm guessing the >> code is not available until the extension becomes official, is that correct ??? >?Glenn Maynard Proposed the specification. Implementation is up to the individual vendors (Google, Apple, Mozilla and Opera). So, this means that even though an extension is proposed and accepted, it is still up to the vendor to implement it if they wish? This seems possible for a vendor to not want to implement it and places the decision on them if they do or don't...hmmm, won't that create fragmentation in the future ??? > The extensions prefixed with OES_ are ported from the OpenGL ES extension registry. the ones prefixed with > WEBGL_ are specific to webgl. Where do the WEBGL specific extensions go then? Are they still up to each vendor to implement how they see fit ? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Mar 27 15:01:56 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 28 Mar 2012 00:01:56 +0200 Subject: [Public WebGL] Extensions In-Reply-To: <1332885185.45050.YahooMailNeo@web125206.mail.ne1.yahoo.com> References: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> <1332885185.45050.YahooMailNeo@web125206.mail.ne1.yahoo.com> Message-ID: On Tue, Mar 27, 2012 at 11:53 PM, Alan DuBoff wrote: > So, this means that even though an extension is proposed and accepted, it > is still up to the vendor to implement it if they wish? > Correct. > This seems possible for a vendor to not want to implement it and places > the decision on them if they do or don't...hmmm, won't that create > fragmentation in the future ??? That's a matter of much philosophical debate. The two proffered points of view are: - Direct3D: "we should have one guaranteed baseline" - OpenGL: "there is one guaranteed baseline, and extensions expose hardware functionality that cannot be offered by all" I might point out that Direct3Ds "hiding" of hardware differences is not entirely watertight. It has also been a strength (on and off) for OpenGL to have an extension mechanism. Whatever the merits of the arguments, WebGL is a Khronos 3D standard modelled after OpenGL ES, which has made the decision to support extensions (itself modelled after OpenGL). There is some lively back and forth around what extensions are introduced to WebGL how with advocates of both camps, so I don't particularly worry. > Where do the WEBGL specific extensions go then? Are they still up to each > vendor to implement how they see fit ? > Yes they too are up to the vendor to implement as they see fit. So far I think the extensions are more or less parity between Firefox and Chrome, there's always a bit of competition to reach or surpass the featureset of the other vendor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Mar 27 15:12:51 2012 From: bja...@ (Benoit Jacob) Date: Tue, 27 Mar 2012 15:12:51 -0700 (PDT) Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <994655469.19265064.1332884965036.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1895775066.19320577.1332886371734.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Maybe I should emphasize that these are performance *regression* tests, intended to catch regressions in a given browser, not intended to compare performance of different browsers or GPUs. Benoit ----- Original Message ----- > > Hello, > > Here are some WebGL performance regression tests: > > http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html > > Like the WebGL conformance tests, they work as standalone Web pages, > or can be run by the above test runner all at once. > > We plan to add many more in the very near future: > - more advanced compositing tests > - texture conversion tests (these would not even do webgl.finish()) > > - and most importantly: I think that this is a good basis to > developer the "Windows Experience Index" kind of benchmarks that we > were recently discussing. > > Does this look like it's going in the right direction? > > Is there interest in moving this to a different location that would > be easier for non-Mozilla people to write to? > > Cheers, > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kos...@ Tue Mar 27 15:21:49 2012 From: kos...@ (David Sheets) Date: Tue, 27 Mar 2012 15:21:49 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, Mar 27, 2012 at 2:51 PM, Florian B?sch wrote: > On Tue, Mar 27, 2012 at 11:43 PM, Kenneth Russell wrote: >> >> The capabilities of mobile GPUs are advancing, and I would not be >> surprised if MRT support began to appear in that arena. If or when it >> does, I think that that would be the right time to advance the WebGL >> specification to add MRT support. > > It would be extremely helpful if we knew what the ES plans for MRTs are. The > picture looks quite different if say, next month an OES_fbo_color_attachment > extension is introduced as opposed to having no plan for any standardized > MRT support in ES. It would be extremely helpful if the ES WG (or at least ES SL WG) came out of hiding and behaved like a proper Open Web Standards body. Who are the members inside Khronos fighting against making ES and ES SL open with a public mailing list, public bug tracker, public test suite, public meeting minutes, public IRC channel, etc? Doing this would: 1. Decrease animosity and fear from the Web community about the benevolence of Khronos and WebGL 2. Increase developer understanding of the underlying issues in delivering the most capable WebGL experience 3. Strengthen the documentation and test suites surrounding WebGL by inviting high quality community contributions (and not rejecting them a priori with a bunch of legal nonsense) 4. Demonstrate Khronos' understanding of web standards 5. Make WebGL's capabilities universal resulting in: A. More chips sold B. More WebGL browsers installed Being secretive, hiding behind paywalls, and insisting on playing telephone between the WebGL WG and the ES/ES SL WG benefits no one in the long term. If Khronos does not accept the Way of the Web but still insists on making "Open Web Standards" and arbitrating conformance to those "Open Web Standards", it is, in fact, an enemy of the Web masquerading as steward. Google and Mozilla surely understand this but cannot speak against the official standards body in public fora. I welcome any and all insights into this situation or my misapprehension of it. Warm World Wide Web Wishes, David Sheets ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ara...@ Tue Mar 27 15:49:30 2012 From: ara...@ (Alan DuBoff) Date: Tue, 27 Mar 2012 15:49:30 -0700 (PDT) Subject: [Public WebGL] Extensions In-Reply-To: References: <1332880442.67890.YahooMailNeo@web125201.mail.ne1.yahoo.com> Message-ID: <1332888570.86493.YahooMailNeo@web125204.mail.ne1.yahoo.com> >?- Apple (Safari Browser, iOS Browser), prefix WEBKIT_ Florian, Thanks for your help with this, and I do see the WebKitLoseContext.h/WebKitLoseContext.cpp in webkit sources under webkit/Source/WebCore/html/canvas/, and they do have the proper functions implemented as per the IDL (loseContext() and restoreContext()). This is all starting to make sense, thanks for helping get it through my thick head...;-) Regards, Alan DuBoff -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Mar 27 17:18:14 2012 From: bja...@ (Benoit Jacob) Date: Tue, 27 Mar 2012 17:18:14 -0700 (PDT) Subject: [Public WebGL] The state of MRTs In-Reply-To: Message-ID: <977828419.19440856.1332893894502.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> > 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" . Benoit > m. > On Tue, Mar 27, 2012 at 9:52 PM, Florian B?sch < pyalot...@ > > wrote: > > On Tue, Mar 27, 2012 at 9:38 PM, Gregg Tavares (?) < > > gman...@ > > > wrote: > > > > 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 > E-Mail: marco.dibenedetto...@ - spattija...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Mar 27 17:22:14 2012 From: bja...@ (Benoit Jacob) Date: Tue, 27 Mar 2012 17:22:14 -0700 (PDT) Subject: [Public WebGL] The state of MRTs In-Reply-To: <977828419.19440856.1332893894502.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <2142789576.19441551.1332894134565.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > > 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. Benoit > Benoit > > m. > > > On Tue, Mar 27, 2012 at 9:52 PM, Florian B?sch < pyalot...@ > > > wrote: > > > > On Tue, Mar 27, 2012 at 9:38 PM, Gregg Tavares (?) < > > > gman...@ > > > > wrote: > > > > > > > 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 > > > E-Mail: marco.dibenedetto...@ - spattija...@ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Mar 27 18:05:24 2012 From: bja...@ (Benoit Jacob) Date: Tue, 27 Mar 2012 18:05:24 -0700 (PDT) Subject: [Public WebGL] The state of MRTs In-Reply-To: <2142789576.19441551.1332894134565.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <299882307.19451361.1332896724955.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> The attached picture illustrates our WebGL extension approval process. ----- Original Message ----- > ----- Original Message ----- > > > 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. > Benoit > > Benoit > > > > m. > > > > > > On Tue, Mar 27, 2012 at 9:52 PM, Florian B?sch < pyalot...@ > > > > > > > wrote: > > > > > > > On Tue, Mar 27, 2012 at 9:38 PM, Gregg Tavares (?) < > > > > gman...@ > > > > > wrote: > > > > > > > > > > > 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 > > > > > > E-Mail: marco.dibenedetto...@ - spattija...@ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: webgl-extension.jpeg Type: image/jpeg Size: 25507 bytes Desc: not available URL: From kbr...@ Tue Mar 27 18:16:19 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 27 Mar 2012 18:16:19 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: <299882307.19451361.1332896724955.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <2142789576.19441551.1332894134565.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <299882307.19451361.1332896724955.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: LOL More seriously, the extension development process is described at http://www.khronos.org/registry/webgl/extensions/ . -Ken On Tue, Mar 27, 2012 at 6:05 PM, Benoit Jacob wrote: > > 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. > Benoit > > > Benoit > > m. > > > > On Tue, Mar 27, 2012 at 9:52 PM, Florian B?sch wrote: > >> On Tue, Mar 27, 2012 at 9:38 PM, Gregg Tavares (?) wrote: >> >>> 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 > E-Mail: marco.dibenedetto...@ - spattija...@ > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: webgl-extension.jpeg Type: image/jpeg Size: 25507 bytes Desc: not available URL: From cal...@ Tue Mar 27 19:39:50 2012 From: cal...@ (Mark Callow) Date: Wed, 28 Mar 2012 11:39:50 +0900 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F7279F6.4020108@hicorp.co.jp> On 28/03/2012 04:10, Florian B?sch wrote: > I strongly suspected that in principle more devices than those > supporting NV_draw_buffers and NV_fbo_color_attachment can do MRT (for > instance the PowerVR chipset family claims in its latest incarnation > to be DX10/OpenGL 3 compatible). The Series 6 design, to which you are referring, has only just been publicly announced and no silicon exists yet, let alone devices with this GPU in retail stores. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Mar 27 19:44:16 2012 From: cal...@ (Mark Callow) Date: Wed, 28 Mar 2012 11:44:16 +0900 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4F727B00.1000001@hicorp.co.jp> On 28/03/2012 04:52, Florian B?sch wrote: > > 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. I do not understand your point. What is the pain you are referring to? Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 28 02:18:42 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 28 Mar 2012 11:18:42 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: <4F727B00.1000001@hicorp.co.jp> References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Wed, Mar 28, 2012 at 4:44 AM, Mark Callow wrote: > I do not understand your point. What is the pain you are referring to? > Pain, conflict, clashing desires. You want two mutually exclusive things, MRTs and cross desktop/mobile compatibility. The discrepancy between desktops and mobiles is the measure of pain. It's 13% vs. 80%. So looking at it purely from a number point of view, your pain is 67%. Desktops will grow the remaining 80% in the next 2 years or so to nearly 100%. How much will mobiles grow? 5%? 10%? So in two years we'll be talking a pain of 77% perhaps. If you're committed to waiting out the pain, you're in for a long wait. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Mar 28 05:20:19 2012 From: bja...@ (Benoit Jacob) Date: Wed, 28 Mar 2012 05:20:19 -0700 (PDT) Subject: [Public WebGL] About the spec date In-Reply-To: <872696959.19604825.1332937050563.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <855730628.19605000.1332937218966.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Hi, The editor's draft currently says Jan 27, but has received one nontrivial commit since: ------------------------------------------------------------------------ r17129 | timj...@ | 2012-03-16 11:11:59 -0400 (Fri, 16 Mar 2012) | 1 line Marked the parameters and return values which must be nullable to pass the confo rmance test as nullable in the specification. Can I also ask for a confirmation: is this what will become 1.0.1 or is there a 1.0.1 branch somewhere like there is for conformance tests? Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From rem...@ Wed Mar 28 07:41:32 2012 From: rem...@ (=?utf-8?B?UsOpbWkgQXJuYXVk?=) Date: Wed, 28 Mar 2012 14:41:32 +0000 Subject: [Public WebGL] Adobe to tax 3D flash games Message-ID: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> slashgear.com/adobe-reveals-flash-tax-for-popular-developers-28220332/ - Remi -- Remi ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Mar 28 08:17:03 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 28 Mar 2012 17:17:03 +0200 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> Message-ID: On Wed, Mar 28, 2012 at 4:41 PM, R?mi Arnaud wrote: > slashgear.com/adobe-reveals-flash-tax-for-popular-developers-28220332/ iOS: custom built device ecosystem + iOS only runtime environment + app-store + dev tool = 30% of your revenue Adobe: desktop operating system only runtime environment + dev tool = 9% of your revenue WebGL: self publishing | a variety of app stores + cross operating system (mobiles+desktops) runtime environment + "dev tool" = 0% of your revenue Thank you Adobe :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rko...@ Wed Mar 28 08:31:11 2012 From: rko...@ (Kornmann, Ralf) Date: Wed, 28 Mar 2012 16:31:11 +0100 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> Message-ID: <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> But still no WebGL in mobile Safari and only very limited support on Android. So I am still at 30% on iOS. Beside of this the 9% for Flash are only in the case you have used some kind of cross compiler. From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Florian B?sch Sent: Wednesday, March 28, 2012 17:17 PM To: remi...@ Cc: Public Webgl Subject: Re: [Public WebGL] Adobe to tax 3D flash games On Wed, Mar 28, 2012 at 4:41 PM, R?mi Arnaud > wrote: slashgear.com/adobe-reveals-flash-tax-for-popular-developers-28220332/ iOS: custom built device ecosystem + iOS only runtime environment + app-store + dev tool = 30% of your revenue Adobe: desktop operating system only runtime environment + dev tool = 9% of your revenue WebGL: self publishing | a variety of app stores + cross operating system (mobiles+desktops) runtime environment + "dev tool" = 0% of your revenue Thank you Adobe :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 28 08:52:10 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 28 Mar 2012 17:52:10 +0200 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: On Wed, Mar 28, 2012 at 5:31 PM, Kornmann, Ralf wrote: > But still no WebGL in mobile Safari and only very limited support on > Android. So I am still at 30% on iOS. > There's GoWebgl http://atnan.com/blog/2011/11/07/amazing-response-to-my-ios-webgl-hack/ any chance to get that in the app-store? :) > Beside of this the 9% for Flash are only in the case you have used some > kind of cross compiler. > http://www.adobe.com/devnet/flashplayer/articles/premium-features.html Revenue is defined as net revenue (not profit) after taxes and subtracted payment processing fees and social networking charges. Revenue is everything (app purchase, in-app transactions etc.). 9% revenue charge is due if: - using ApplicationDomain.domainMemory - and using Stage3D.request3DContext - and release date > August 1, 2012 - and net revenue > $50'000 - and *not* cross compiling/packaging as app for iOS, OSX, Android and Windows Adobe would like to purchase an equity in your company of around 9% of your companies net worth. However they're not gonna pay you for it, instead they propose that providing Flash is adequate compensation for that equity stake. Adobe wants you to know it values every company it purchases a stake in at no cost whatsoever, thanksbye. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Wed Mar 28 08:52:36 2012 From: tpa...@ (Tony Parisi) Date: Wed, 28 Mar 2012 11:52:36 -0400 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> Message-ID: <4D8FD3A3-E7E7-4840-860E-A29F12E1F4E6@gmail.com> That is IMO a strategic error that will only benefit WebGL in the long run. Tony Parisi CTO at Large 415.902.8002 On Mar 28, 2012, at 10:41 AM, "R?mi Arnaud" wrote: > > slashgear.com/adobe-reveals-flash-tax-for-popular-developers-28220332/ > - Remi > -- Remi > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From rko...@ Wed Mar 28 09:04:01 2012 From: rko...@ (Kornmann, Ralf) Date: Wed, 28 Mar 2012 17:04:01 +0100 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: <9B3BEF16CBC82A45900B3F159DF91596017576F59888@EU-MAIL-1-1.rws.ad.ea.com> It's private API. No Chance. Beside of this you can only use it in your own App that make use of UIWebView (30% again). The main point for the 9% here is the domainMemory. That can be only used by CrossCompiler at the moment. So someone who writes a normal Flash app with 3D don't need to pay. Maybe Adobe will change this again in the future in include more apps. Overall don't get me wrong. I prefer doing our games in HTML5/WebGL. I was even one of the engineers in our company who said more than 3 yeasr ago that we should use HTML instead of Flash to do our games. From: Florian B?sch [mailto:pyalot...@] Sent: Wednesday, March 28, 2012 17:52 PM To: Kornmann, Ralf Cc: remi...@; Public Webgl Subject: Re: [Public WebGL] Adobe to tax 3D flash games On Wed, Mar 28, 2012 at 5:31 PM, Kornmann, Ralf > wrote: But still no WebGL in mobile Safari and only very limited support on Android. So I am still at 30% on iOS. There's GoWebgl http://atnan.com/blog/2011/11/07/amazing-response-to-my-ios-webgl-hack/ any chance to get that in the app-store? :) Beside of this the 9% for Flash are only in the case you have used some kind of cross compiler. http://www.adobe.com/devnet/flashplayer/articles/premium-features.html Revenue is defined as net revenue (not profit) after taxes and subtracted payment processing fees and social networking charges. Revenue is everything (app purchase, in-app transactions etc.). 9% revenue charge is due if: - using ApplicationDomain.domainMemory - and using Stage3D.request3DContext - and release date > August 1, 2012 - and net revenue > $50'000 - and not cross compiling/packaging as app for iOS, OSX, Android and Windows Adobe would like to purchase an equity in your company of around 9% of your companies net worth. However they're not gonna pay you for it, instead they propose that providing Flash is adequate compensation for that equity stake. Adobe wants you to know it values every company it purchases a stake in at no cost whatsoever, thanksbye. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 28 09:10:04 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 28 Mar 2012 18:10:04 +0200 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: <9B3BEF16CBC82A45900B3F159DF91596017576F59888@EU-MAIL-1-1.rws.ad.ea.com> References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> <9B3BEF16CBC82A45900B3F159DF91596017576F59888@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: On Wed, Mar 28, 2012 at 6:04 PM, Kornmann, Ralf wrote: > It?s private API. No Chance. Beside of this you can only use it in your > own App that make use of UIWebView (30% again). > That clause in apples license agreement covers in-app revenue otherwise known as the "Amazon clause". Afaik it contents that if you provide an app (even a free app) and you generate revenue from it, you're liable for 30% of your revenue to Apple no matter how you make it. Obviously apple cannot demand 30% from everybody who receives money in the process of using their browser, because those third parties have no revenue sharing agreement with apple. There are other Browsers in the app-store, and no page you visit trough them and spend money at, will have to give Apple money. The same would apply to a "WebGL Enabled Browser" obviously. Of course you might not get it into the app-store for using that hack, but that's another story. -------------- next part -------------- An HTML attachment was scrubbed... URL: From toj...@ Wed Mar 28 09:14:37 2012 From: toj...@ (Brandon Jones) Date: Wed, 28 Mar 2012 09:14:37 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: I've been following this thread for a while and I have to admit that the continued insistence on "protecting" WebGL from things that might not work on mobile is very confusing to me. For one, there aren't a lot of mobile devices right now that can actually support WebGL in any meaningful sense. Opera on Android seems to be the best so far but even there the performance is pretty bad when you compare it to what the device is actually capable of. In fact, the only mobile device I've seen run WebGL respectably is the iPhone/iPad, and that's currently not something you can see without having a developer account. Point being that if we were to restrict ourselves to writing WebGL apps that work nicely between mobile/desktop it would all look like Starfoxfor the time being. I do expect that situation to improve in leaps and bounds in the near future, as I can see this easily becoming a selling point for mobile devices and browsers, but in the meantime I see nothing wrong with wanting to flex the muscles of WebGL on the desktop. Besides, isn't that why this is being proposed as an extension and not a part of the base spec? It's common sense to check to see if your extension query returned an object, at which point it's on the developer to either take a different render path or notify the user that their device doesn't meet the requirements for that app. Although I would like to see as few apps as possible lock out mobile, I also don't want to sacrifice the possibility of WebGL having it's own version of the Samaritan demo at some point simply because not every WebGL capable device can run it. That said, I do think it's sensible to try and inform users as much as possible when their WebGL application is doing something that will not be mobile-friendly, since the last thing we want is for people to inadvertently exclude mobile and not understand why. I've seen several charts tossed around on the mailing list giving compatibility of feature X on chipset Y. If those are available in a sensible format somewhere publicly (or can be made so) I think it would be a great idea to put together some browser extensions that monitor the extensions that a WebGL app loads and provide the user with a "Mobile health report" for their app, detailing what features they're using that may affect mobile compatibility. Alternately the same extension could be used to "simulate" the feature set of a device class by restricting the extensions that can be used. I'd be happy to help with the development of such a tool if it gets us to stop bickering about what features we can and can't support due to mobile. --Brandon On Wed, Mar 28, 2012 at 2:18 AM, Florian B?sch wrote: > On Wed, Mar 28, 2012 at 4:44 AM, Mark Callow wrote: > >> I do not understand your point. What is the pain you are referring to? >> > Pain, conflict, clashing desires. You want two mutually exclusive things, > MRTs and cross desktop/mobile compatibility. The discrepancy between > desktops and mobiles is the measure of pain. It's 13% vs. 80%. So looking > at it purely from a number point of view, your pain is 67%. Desktops will > grow the remaining 80% in the next 2 years or so to nearly 100%. How much > will mobiles grow? 5%? 10%? So in two years we'll be talking a pain of 77% > perhaps. If you're committed to waiting out the pain, you're in for a long > wait. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Mar 28 09:34:19 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 28 Mar 2012 18:34:19 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Wed, Mar 28, 2012 at 6:14 PM, Brandon Jones wrote: > That said, I do think it's sensible to try and inform users as much as > possible when their WebGL application is doing something that will not be > mobile-friendly, since the last thing we want is for people > to inadvertently exclude mobile and not understand why. I've seen several > charts tossed around on the mailing list giving compatibility of feature X > on chipset Y. If those are available in a sensible format somewhere > publicly (or can be made so) I think it would be a great idea to put > together some browser extensions that monitor the extensions that a WebGL > app loads and provide the user with a "Mobile health report" for their app, > detailing what features they're using that may affect mobile compatibility. > Alternately the same extension could be used to "simulate" the feature > set of a device class by restricting the extensions that can be used. I'd > be happy to help with the development of such a tool if it gets us to stop > bickering about what features we can and can't support due to mobile. > I'd like a "can I use this in WebGL" for extensions (and other things like texture units, VS texture lookup etc.). The data I thrawled which I provide for discussions about extensions comes from glbenchmark.com, which does not reflect the WebGL ecosystem. Browser vendors could provide statistics about device capabilities which would be much appreciated to pour into a "can I use this" site. Any volunteers for the data? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rko...@ Wed Mar 28 11:01:00 2012 From: rko...@ (Kornmann, Ralf) Date: Wed, 28 Mar 2012 19:01:00 +0100 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> <9B3BEF16CBC82A45900B3F159DF91596017576F59888@EU-MAIL-1-1.rws.ad.ea.com>, Message-ID: <9B3BEF16CBC82A45900B3F159DF915960175762319DA@EU-MAIL-1-1.rws.ad.ea.com> I see where we misunderstand each other. I was talking about using your WebGL apps with something like phoneGap and a WebGL enabled UIWebView to get it running on iOS. You were talking about just an alternative browser with WebGL enabled. Unfortunately both will require the use of the private API call and therefore are not qualified for the App store. The call will most likely lost the private status (if ever) when mobile safari allows the use of WebGL. So even with this hack the situation of WebGL on iOS is practical the same.as before. Von: Florian B?sch [pyalot...@] Gesendet: Mittwoch, 28. M?rz 2012 18:10 An: Kornmann, Ralf Cc: remi...@; Public Webgl Betreff: Re: [Public WebGL] Adobe to tax 3D flash games On Wed, Mar 28, 2012 at 6:04 PM, Kornmann, Ralf wrote: It?s private API. No Chance. Beside of this you can only use it in your own App that make use of UIWebView (30% again). That clause in apples license agreement covers in-app revenue otherwise known as the "Amazon clause". Afaik it contents that if you provide an app (even a free app) and you generate revenue from it, you're liable for 30% of your revenue to Apple no matter how you make it. Obviously apple cannot demand 30% from everybody who receives money in the process of using their browser, because those third parties have no revenue sharing agreement with apple. There are other Browsers in the app-store, and no page you visit trough them and spend money at, will have to give Apple money. The same would apply to a "WebGL Enabled Browser" obviously. Of course you might not get it into the app-store for using that hack, but that's another story. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pau...@ Wed Mar 28 11:27:51 2012 From: pau...@ (Paul Lewis) Date: Wed, 28 Mar 2012 19:27:51 +0100 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: <-5513049632572584339@unknownmsgid> I'm with Brandon on this. I don't see any clear promise by Apple or many other manufacturers to start supporting WebGL on mobile. To then base what is available to everyone, desktop or otherwise, on that subset makes little sense to me. Also given that the issue of platform variance will present itself whenever MRTs are added seems to me to be reason enough to start that ball rolling now before there are implementations in place. Of course there will be unreleased implementations, I'm sure, and of course as Brandon mentioned Opera and Firefox have implementations out already. I would, as a developer trying to use WebGL, welcome it as an addition. I would get real and tangible benefits from its addition today, if it were available. I can't say much more than that, really! :) On 28 Mar 2012, at 17:37, "Florian B?sch" wrote: On Wed, Mar 28, 2012 at 6:14 PM, Brandon Jones wrote: > That said, I do think it's sensible to try and inform users as much as > possible when their WebGL application is doing something that will not be > mobile-friendly, since the last thing we want is for people > to inadvertently exclude mobile and not understand why. I've seen several > charts tossed around on the mailing list giving compatibility of feature X > on chipset Y. If those are available in a sensible format somewhere > publicly (or can be made so) I think it would be a great idea to put > together some browser extensions that monitor the extensions that a WebGL > app loads and provide the user with a "Mobile health report" for their app, > detailing what features they're using that may affect mobile compatibility. > Alternately the same extension could be used to "simulate" the feature > set of a device class by restricting the extensions that can be used. I'd > be happy to help with the development of such a tool if it gets us to stop > bickering about what features we can and can't support due to mobile. > I'd like a "can I use this in WebGL" for extensions (and other things like texture units, VS texture lookup etc.). The data I thrawled which I provide for discussions about extensions comes from glbenchmark.com, which does not reflect the WebGL ecosystem. Browser vendors could provide statistics about device capabilities which would be much appreciated to pour into a "can I use this" site. Any volunteers for the data? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Mar 28 14:17:49 2012 From: kbr...@ (Kenneth Russell) Date: Wed, 28 Mar 2012 14:17:49 -0700 Subject: [Public WebGL] About the spec date In-Reply-To: <855730628.19605000.1332937218966.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <872696959.19604825.1332937050563.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <855730628.19605000.1332937218966.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Mar 28, 2012 at 5:20 AM, Benoit Jacob wrote: > > Hi, > > The editor's draft currently says Jan 27, but has received one nontrivial commit since: > > ------------------------------------------------------------------------ > r17129 | timj...@ | 2012-03-16 11:11:59 -0400 (Fri, 16 Mar 2012) | 1 line > > Marked the parameters and return values which must be nullable to pass the confo > rmance test as nullable in the specification. I've adjusted the date on the editor's draft to match the date of that commit. > Can I also ask for a confirmation: is this what will become 1.0.1 or is there a 1.0.1 branch somewhere like there is for conformance tests? There is a snapshot of the proposed spec for 1.0.1, under specs/r16849 in the repository, which is either identical to what was sent to the Khronos board for approval, or very close to it. -Ken > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Thu Mar 29 14:21:35 2012 From: bja...@ (Benoit Jacob) Date: Thu, 29 Mar 2012 14:21:35 -0700 (PDT) Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <1895775066.19320577.1332886371734.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1286866639.412895.1333056095693.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> For what it's worth, the performance regression tests are now much expanded, covering in particular the dreaded texture format conversions. Still same URL: http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html Benoit ----- Original Message ----- > > Maybe I should emphasize that these are performance *regression* > tests, intended to catch regressions in a given browser, not > intended to compare performance of different browsers or GPUs. > > Benoit > > ----- Original Message ----- > > > > Hello, > > > > Here are some WebGL performance regression tests: > > > > http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html > > > > Like the WebGL conformance tests, they work as standalone Web > > pages, > > or can be run by the above test runner all at once. > > > > We plan to add many more in the very near future: > > - more advanced compositing tests > > - texture conversion tests (these would not even do > > webgl.finish()) > > > > - and most importantly: I think that this is a good basis to > > developer the "Windows Experience Index" kind of benchmarks that > > we > > were recently discussing. > > > > Does this look like it's going in the right direction? > > > > Is there interest in moving this to a different location that would > > be easier for non-Mozilla people to write to? > > > > Cheers, > > Benoit > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > unsubscribe public_webgl > > ----------------------------------------------------------- > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Mar 29 14:54:40 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 29 Mar 2012 14:54:40 -0700 Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <1286866639.412895.1333056095693.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1895775066.19320577.1332886371734.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1286866639.412895.1333056095693.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Nice work! Performance regressions are difficult to detect, so any efforts to do so in an automated fashion are great. Embarrassingly, Chrome Canary, at least, sad-tabs running one of the tests; I've filed http://crbug.com/120977 to track this. I hope that someone on the MapsGL team at Google might see this post and comment. In general the tests you've got look pretty good; they seem to exercise aspects of the WebGL implementation such as reading back pixels outside the viewport and texture format conversions. I think the MapsGL team has more tests in their built-in benchmark which measured fill rate, certain aspects of shader performance, etc. If we were trying to write a cross-platform Windows Experience Index benchmark we'd probably want more of the latter kind of tests. -Ken On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob wrote: > > For what it's worth, the performance regression tests are now much expanded, covering in particular the dreaded texture format conversions. > > Still same URL: > http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html > > Benoit > > ----- Original Message ----- >> >> Maybe I should emphasize that these are performance *regression* >> tests, intended to catch regressions in a given browser, not >> intended to compare performance of different browsers or GPUs. >> >> Benoit >> >> ----- Original Message ----- >> > >> > Hello, >> > >> > Here are some WebGL performance regression tests: >> > >> > http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html >> > >> > Like the WebGL conformance tests, they work as standalone Web >> > pages, >> > or can be run by the above test runner all at once. >> > >> > We plan to add many more in the very near future: >> > ?- more advanced compositing tests >> > ?- texture conversion tests (these would not even do >> > ?webgl.finish()) >> > >> > ?- and most importantly: I think that this is a good basis to >> > ?developer the "Windows Experience Index" kind of benchmarks that >> > ?we >> > ?were recently discussing. >> > >> > Does this look like it's going in the right direction? >> > >> > Is there interest in moving this to a different location that would >> > be easier for non-Mozilla people to write to? >> > >> > Cheers, >> > Benoit >> > >> > ----------------------------------------------------------- >> > You are currently subscribed to public_webgl...@ >> > To unsubscribe, send an email to majordomo...@ with >> > the following command in the body of your email: >> > unsubscribe public_webgl >> > ----------------------------------------------------------- >> > >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From wba...@ Thu Mar 29 15:22:57 2012 From: wba...@ (Bill Baxter) Date: Thu, 29 Mar 2012 15:22:57 -0700 Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: References: <1895775066.19320577.1332886371734.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1286866639.412895.1333056095693.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, Mar 29, 2012 at 2:54 PM, Kenneth Russell wrote: > > Nice work! Performance regressions are difficult to detect, so any > efforts to do so in an automated fashion are great. > > Embarrassingly, Chrome Canary, at least, sad-tabs running one of the > tests; I've filed http://crbug.com/120977 to track this. > > I hope that someone on the MapsGL team at Google might see this post > and comment. In general the tests you've got look pretty good; they > seem to exercise aspects of the WebGL implementation such as reading > back pixels outside the viewport and texture format conversions. I > think the MapsGL team has more tests in their built-in benchmark which > measured fill rate, certain aspects of shader performance, etc. If we > were trying to write a cross-platform Windows Experience Index > benchmark we'd probably want more of the latter kind of tests. > MapsGL guy here. This is great that you're putting together this suite, Benoit. Our benchmark is based mostly on doing lots of texture lookups and dependent texture lookups because that was what we found to be most correlated with MapsGL performance. We also have a compute-heavy fragment shader that does Mandelbrot calcs. We also run continuous perf tests of MapsGL itself, and this shows things that may not show up in the synthetic 1-trick benchmarks. I think following the lead of the other 3D benchmarks and including some packaged up bits of real apps or demos in addition to the synthetic tests would be a good thing for the suite. -bb -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihf...@ Thu Mar 29 15:27:07 2012 From: ihf...@ (Ilja Friedel) Date: Thu, 29 Mar 2012 15:27:07 -0700 Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <1286866639.412895.1333056095693.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1895775066.19320577.1332886371734.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1286866639.412895.1333056095693.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob wrote: > > For what it's worth, the performance regression tests are now much > expanded, covering in particular the dreaded texture format conversions. > > Still same URL: > > http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html I second the very nice. To run this in practice in a regression suite one would need an easy way to adjust the work done for each individual test to say 50ms or 100ms. Right now on my atom test runtimes are between 8ms and 517ms. 8ms is awfully hard to distinguish from zero and computing any sum (or even geometric mean) is dodgy. Maybe allow for some kind of configuration/ parameterization of the number of loops running for each test? Ilja. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Mar 29 15:34:13 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 29 Mar 2012 15:34:13 -0700 Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: References: <1895775066.19320577.1332886371734.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1286866639.412895.1333056095693.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, Mar 29, 2012 at 3:27 PM, Ilja Friedel wrote: > On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob wrote: >> >> >> For what it's worth, the performance regression tests are now much >> expanded, covering in particular the dreaded texture format conversions. >> >> Still same URL: >> >> http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html > > > I second the very nice. To run this in practice in a regression suite one > would need an easy way to adjust the work done for each individual test to > say 50ms or 100ms. Right now on my atom test runtimes are between 8ms and > 517ms. 8ms is awfully hard to distinguish from zero and computing any sum > (or even geometric mean) is dodgy. Maybe allow for some kind of > configuration/ parameterization of the number of loops running for each > test? Good point. The V8 benchmark suite generally runs each benchmark for a fixed period of time, say 2 seconds, and measures the number of iterations of the test that can be performed in that time, rather than using a fixed number of iterations. This seems to be a pretty robust methodology. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Thu Mar 29 16:03:46 2012 From: bja...@ (Benoit Jacob) Date: Thu, 29 Mar 2012 16:03:46 -0700 (PDT) Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: Message-ID: <2107336038.506972.1333062226614.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Thu, Mar 29, 2012 at 3:27 PM, Ilja Friedel wrote: > > On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob > > wrote: > >> > >> > >> For what it's worth, the performance regression tests are now much > >> expanded, covering in particular the dreaded texture format > >> conversions. > >> > >> Still same URL: > >> > >> http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html > > > > > > I second the very nice. To run this in practice in a regression > > suite one > > would need an easy way to adjust the work done for each individual > > test to > > say 50ms or 100ms. Right now on my atom test runtimes are between > > 8ms and > > 517ms. 8ms is awfully hard to distinguish from zero and computing > > any sum > > (or even geometric mean) is dodgy. Maybe allow for some kind of > > configuration/ parameterization of the number of loops running for > > each > > test? > > Good point. The V8 benchmark suite generally runs each benchmark for > a > fixed period of time, say 2 seconds, and measures the number of > iterations of the test that can be performed in that time, rather > than > using a fixed number of iterations. This seems to be a pretty robust > methodology. The performance tests currently run until both conditions are met: they've either done 10 iterations, and run for at least 300 ms. See in WebGLPerformanceTest.js: WebGLPerformanceTest.prototype.hasRecordedEnoughFrames = function(time) { // stop when we have recorded at least 10 frames and run for at least 300 ms return this.timings.length > 10 && time - this.startTime > 300; } The final result is then computed as the median result among all iterations/frames. So when you get "8 ms", it doesn't mean that the test stopped after 8 ms. It means that 8 ms is the median frame time. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Mar 29 17:12:31 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 29 Mar 2012 17:12:31 -0700 Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <2107336038.506972.1333062226614.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <2107336038.506972.1333062226614.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, Mar 29, 2012 at 4:03 PM, Benoit Jacob wrote: > > > ----- Original Message ----- >> On Thu, Mar 29, 2012 at 3:27 PM, Ilja Friedel wrote: >> > On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob >> > wrote: >> >> >> >> >> >> For what it's worth, the performance regression tests are now much >> >> expanded, covering in particular the dreaded texture format >> >> conversions. >> >> >> >> Still same URL: >> >> >> >> http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html >> > >> > >> > I second the very nice. To run this in practice in a regression >> > suite one >> > would need an easy way to adjust the work done for each individual >> > test to >> > say 50ms or 100ms. Right now on my atom test runtimes are between >> > 8ms and >> > 517ms. 8ms is awfully hard to distinguish from zero and computing >> > any sum >> > (or even geometric mean) is dodgy. Maybe allow for some kind of >> > configuration/ parameterization of the number of loops running for >> > each >> > test? >> >> Good point. The V8 benchmark suite generally runs each benchmark for >> a >> fixed period of time, say 2 seconds, and measures the number of >> iterations of the test that can be performed in that time, rather >> than >> using a fixed number of iterations. This seems to be a pretty robust >> methodology. > > The performance tests currently run until both conditions are met: they've either done 10 iterations, and run for at least 300 ms. > > See in WebGLPerformanceTest.js: > > WebGLPerformanceTest.prototype.hasRecordedEnoughFrames = function(time) { > ?// stop when we have recorded at least 10 frames and run for at least 300 ms > ?return this.timings.length > 10 && > ? ? ? ? time - this.startTime > 300; > } > > The final result is then computed as the median result among all iterations/frames. > > So when you get "8 ms", it doesn't mean that the test stopped after 8 ms. It means that 8 ms is the median frame time. Sounds good. Thanks for the clarification. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ihf...@ Thu Mar 29 17:52:33 2012 From: ihf...@ (Ilja Friedel) Date: Thu, 29 Mar 2012 17:52:33 -0700 Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <2107336038.506972.1333062226614.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <2107336038.506972.1333062226614.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, Mar 29, 2012 at 4:03 PM, Benoit Jacob wrote: > > > ----- Original Message ----- >> On Thu, Mar 29, 2012 at 3:27 PM, Ilja Friedel wrote: >> > On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob >> > wrote: >> >> >> >> >> >> For what it's worth, the performance regression tests are now much >> >> expanded, covering in particular the dreaded texture format >> >> conversions. >> >> >> >> Still same URL: >> >> >> >> http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html >> > >> > >> > I second the very nice. To run this in practice in a regression >> > suite one >> > would need an easy way to adjust the work done for each individual >> > test to >> > say 50ms or 100ms. Right now on my atom test runtimes are between >> > 8ms and >> > 517ms. 8ms is awfully hard to distinguish from zero and computing >> > any sum >> > (or even geometric mean) is dodgy. Maybe allow for some kind of >> > configuration/ parameterization of the number of loops running for >> > each >> > test? >> >> Good point. The V8 benchmark suite generally runs each benchmark for >> a >> fixed period of time, say 2 seconds, and measures the number of >> iterations of the test that can be performed in that time, rather >> than >> using a fixed number of iterations. This seems to be a pretty robust >> methodology. > > The performance tests currently run until both conditions are met: they've either done 10 iterations, and run for at least 300 ms. > > See in WebGLPerformanceTest.js: > > WebGLPerformanceTest.prototype.hasRecordedEnoughFrames = function(time) { > // stop when we have recorded at least 10 frames and run for at least 300 ms > return this.timings.length > 10 && > time - this.startTime > 300; > } > > The final result is then computed as the median result among all iterations/frames. > > So when you get "8 ms", it doesn't mean that the test stopped after 8 ms. It means that 8 ms is the median frame time. In understand. And that means that we are mostly there! What I would like to see is (at least) 2 significant digits so one can pick up a 1 percent change in performance. In the run below (on an low end atom) many numbers are 20ms or below. This means that a change in performance is only detected when times changes more than 1ms/20ms or 5 percent. This problem obviously gets worse with faster hardware. Finally perf numbers are often aggregated into a single number by summing them up (bad!) or using a geometric mean (better, but problematic when we get many results). Either way I am worried what happens if the reported numbers start approaching zero. Ilja. *WebGL Performance Regression Test Results* Keep in mind that these tests are not realistic workloads. These are not benchmarks aiming to compare browser or GPU performance. These are only useful to catch performance regressions in a given browser and system. Test pageResultDescriptionclear-10x-default.html 484 ms*Clear with defaults, repeated 10?, size 1024?1024* clear-10x-nondefault-constant-color.html 332 ms*Clear with constant non-default color, repeated 10?, size 1024?1024* clear-default.html 51 ms*Clear with defaults, size 1024?1024* clear-default-preserveDrawingBuffer.html 59 ms*Clear with defaults, with preserveDrawingBuffer, size 1024?1024* clear-nondefault-constant-color.html 64 ms*Clear with constant non-default color, size 1024?1024* clear-nondefault-constant-color-preserveDrawingBuffer.html 56 ms*Clear with constant non-default color, with preserveDrawingBuffer, size 1024?1024*clear-varying-color-and-readPixels.html 159 ms*Clear with varying color and readPixels, size 1024?1024* clear-varying-color-and-readPixels-out-of-bounds.html 182 ms*Clear with varying color and readPixels out-of-bounds, size 1024?1024 *clear-varying-color.html 52 ms*Clear with varying color, size 1024?1024* clear-varying-color-preserveDrawingBuffer.html 51 ms*Clear with varying color, with preserveDrawingBuffer, size 1024?1024* convert-Canvas-to-a8.html 14 ms*Texture conversion, from 1024?1024 Canvas to A8 unpremult.* convert-Canvas-to-a8-premultiplied.html 14 ms*Texture conversion, from 1024?1024 Canvas to A8 premult.* convert-Canvas-to-l8.html 76 ms*Texture conversion, from 1024?1024 Canvas to L8 unpremult.* convert-Canvas-to-l8-premultiplied.html 15 ms*Texture conversion, from 1024?1024 Canvas to L8 premult.* convert-Canvas-to-rgb565.html 109 ms*Texture conversion, from 1024?1024 Canvas to RGB565 unpremult.* convert-Canvas-to-rgb565-premultiplied.html 24 ms*Texture conversion, from 1024?1024 Canvas to RGB565 premult.* convert-Canvas-to-rgb888.html 107 ms*Texture conversion, from 1024?1024 Canvas to RGB888 unpremult.* convert-Canvas-to-rgb888-premultiplied.html 22 ms*Texture conversion, from 1024?1024 Canvas to RGB888 premult.* convert-Canvas-to-rgba4444.html 115 ms*Texture conversion, from 1024?1024 Canvas to RGBA4444 unpremult.* convert-Canvas-to-rgba4444-premultiplied.html 21 ms*Texture conversion, from 1024?1024 Canvas to RGBA4444 premult.* convert-Canvas-to-rgba8888.html 107 ms*Texture conversion, from 1024?1024 Canvas to RGBA8888 unpremult.* convert-Canvas-to-rgba8888-premultiplied.html 18 ms*Texture conversion, from 1024?1024 Canvas to RGBA8888 premult.* convert-Canvas-to-rgb-float.html Skipped*Texture conversion, from 1024?1024 Canvas to RGBA/float unpremult.* convert-Canvas-to-rgb-float-premultiplied.html Skipped*Texture conversion, from 1024?1024 Canvas to RGBA/float premult.* convert-ImageData-to-a8.html 7 ms*Texture conversion, from 1024?1024 ImageData to A8 unpremult.* convert-ImageData-to-a8-premultiplied.html 8 ms*Texture conversion, from 1024?1024 ImageData to A8 premult.* convert-ImageData-to-l8.html 8 ms*Texture conversion, from 1024?1024 ImageData to L8 unpremult.* convert-ImageData-to-l8-premultiplied.html 47 ms*Texture conversion, from 1024?1024 ImageData to L8 premult.* convert-ImageData-to-rgb565.html 17 ms*Texture conversion, from 1024?1024 ImageData to RGB565 unpremult.* convert-ImageData-to-rgb565-premultiplied.html 82 ms*Texture conversion, from 1024?1024 ImageData to RGB565 premult.* convert-ImageData-to-rgb888.html 15 ms*Texture conversion, from 1024?1024 ImageData to RGB888 unpremult.* convert-ImageData-to-rgb888-premultiplied.html 82 ms*Texture conversion, from 1024?1024 ImageData to RGB888 premult.* convert-ImageData-to-rgba4444.html 16 ms*Texture conversion, from 1024?1024 ImageData to RGBA4444 unpremult.* convert-ImageData-to-rgba4444-premultiplied.html 87 ms*Texture conversion, from 1024?1024 ImageData to RGBA4444 premult.* convert-ImageData-to-rgba8888.html 14 ms*Texture conversion, from 1024?1024 ImageData to RGBA8888 unpremult.* convert-ImageData-to-rgba8888-premultiplied.html 84 ms*Texture conversion, from 1024?1024 ImageData to RGBA8888 premult.* convert-ImageData-to-rgb-float.html Skipped*Texture conversion, from 1024?1024 ImageData to RGBA/float unpremult.*convert-ImageData-to-rgb-float-premultiplied.html Skipped*Texture conversion, from 1024?1024 ImageData to RGBA/float premult.* convert-Image-to-a8.html 11 ms*Texture conversion, from 1024?1024 Image to A8 unpremult.* convert-Image-to-a8-premultiplied.html 12 ms*Texture conversion, from 1024?1024 Image to A8 premult.* convert-Image-to-l8.html 16 ms*Texture conversion, from 1024?1024 Image to L8 unpremult.* convert-Image-to-l8-premultiplied.html 15 ms*Texture conversion, from 1024?1024 Image to L8 premult.* convert-Image-to-rgb565.html 21 ms*Texture conversion, from 1024?1024 Image to RGB565 unpremult.* convert-Image-to-rgb565-premultiplied.html 20 ms*Texture conversion, from 1024?1024 Image to RGB565 premult.* convert-Image-to-rgb888.html 21 ms*Texture conversion, from 1024?1024 Image to RGB888 unpremult.* convert-Image-to-rgb888-premultiplied.html 22 ms*Texture conversion, from 1024?1024 Image to RGB888 premult.* convert-Image-to-rgba4444.html 20 ms*Texture conversion, from 1024?1024 Image to RGBA4444 unpremult.* convert-Image-to-rgba4444-premultiplied.html 21 ms*Texture conversion, from 1024?1024 Image to RGBA4444 premult.* convert-Image-to-rgba8888.html 19 ms*Texture conversion, from 1024?1024 Image to RGBA8888 unpremult.* convert-Image-to-rgba8888-premultiplied.html 17 ms*Texture conversion, from 1024?1024 Image to RGBA8888 premult.* convert-Image-to-rgb-float.html Skipped*Texture conversion, from 1024?1024 Image to RGBA/float unpremult.* convert-Image-to-rgb-float-premultiplied.html Skipped*Texture conversion, from 1024?1024 Image to RGBA/float premult.* decrement-dimensions.html 183 ms*Decrement canvas dimensions, size 1024?1024*do-nothing.html 18 ms*Do nothing, size 1024?1024*do-nothing-preserveDrawingBuffer.html 17 ms*Do nothing, with preserveDrawingBuffer, size 1024?1024* increment-dimensions.html 70 ms*Increment canvas dimensions, size 1024?1024*texImage2D-null.html 1 ms*texImage2D with null, repeated 10?*texImage2D-TypedArray.html 87 ms*texImage2D with TypedArray, repeated 10?*texSubImage2D-TypedArray.html 84 ms*texSubImage2D with TypedArray, repeated 10?* -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Mar 29 18:57:27 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 29 Mar 2012 18:57:27 -0700 Subject: [Public WebGL] DataView tests added Message-ID: Per discussion on today's concall, the DataView tests from the WebKit repository have been checked in to the conformance suite under conformance/typedarrays/ . These are for the "development" version of the conformance suite, i.e., version 1.0.2. Please post if you see any issues. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Thu Mar 29 19:24:19 2012 From: bja...@ (Benoit Jacob) Date: Thu, 29 Mar 2012 19:24:19 -0700 (PDT) Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: Message-ID: <376841800.601466.1333074259516.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Thu, Mar 29, 2012 at 4:03 PM, Benoit Jacob < bjacob...@ > > wrote: > > > > > > ----- Original Message ----- > >> On Thu, Mar 29, 2012 at 3:27 PM, Ilja Friedel < ihf...@ > > >> wrote: > >> > On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob < > >> > bjacob...@ > > >> > wrote: > >> >> > >> >> > >> >> For what it's worth, the performance regression tests are now > >> >> much > >> >> expanded, covering in particular the dreaded texture format > >> >> conversions. > >> >> > >> >> Still same URL: > >> >> > >> >> http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html > >> > > >> > > >> > I second the very nice. To run this in practice in a regression > >> > suite one > >> > would need an easy way to adjust the work done for each > >> > individual > >> > test to > >> > say 50ms or 100ms. Right now on my atom test runtimes are > >> > between > >> > 8ms and > >> > 517ms. 8ms is awfully hard to distinguish from zero and > >> > computing > >> > any sum > >> > (or even geometric mean) is dodgy. Maybe allow for some kind of > >> > configuration/ parameterization of the number of loops running > >> > for > >> > each > >> > test? > >> > >> Good point. The V8 benchmark suite generally runs each benchmark > >> for > >> a > >> fixed period of time, say 2 seconds, and measures the number of > >> iterations of the test that can be performed in that time, rather > >> than > >> using a fixed number of iterations. This seems to be a pretty > >> robust > >> methodology. > > > > The performance tests currently run until both conditions are met: > > they've either done 10 iterations, and run for at least 300 ms. > > > > See in WebGLPerformanceTest.js: > > > > WebGLPerformanceTest.prototype.hasRecordedEnoughFrames = > > function(time) { > > // stop when we have recorded at least 10 frames and run for at > > least 300 ms > > return this.timings.length > 10 && > > time - this.startTime > 300; > > } > > > > The final result is then computed as the median result among all > > iterations/frames. > > > > So when you get "8 ms", it doesn't mean that the test stopped after > > 8 ms. It means that 8 ms is the median frame time. > In understand. And that means that we are mostly there! What I would > like to see is (at least) 2 significant digits so one can pick up a > 1 percent change in performance. In the run below (on an low end > atom) many numbers are 20ms or below. This means that a change in > performance is only detected when times changes more than 1ms/20ms > or 5 percent. This problem obviously gets worse with faster > hardware. Two problems here: - I am not aware of timing mechanisms exposed to Javascript, that would have better than millisecond precision. There is some consensus at Mozilla to make that happen, but it hasn't happened yet AFAIK. - Most test results have more discrepancies across runs, than this 1ms precision, anyway. So in most cases (including when the result is < 10 ms) we often have a bigger problem here anyway. Both can potentially be addressed by adding more workload to get higher timings and reduce noise. > Finally perf numbers are often aggregated into a single number by > summing them up (bad!) or using a geometric mean (better, but > problematic when we get many results). Either way I am worried what > happens if the reported numbers start approaching zero. I was wondering if we would want such a synthetic measure. Let's give them a chance to prove their usefulness ;-) Benoit > Ilja. > WebGL Performance Regression Test Results > Keep in mind that these tests are not realistic workloads. These are > not benchmarks aiming to compare browser or GPU performance. These > are only useful to catch performance regressions in a given browser > and system. > Test page Result Description > clear-10x-default.html 484 ms Clear with defaults, repeated 10?, > size 1024?1024 > clear-10x-nondefault-constant-color.html 332 ms Clear with constant > non-default color, repeated 10?, size 1024?1024 > clear-default.html 51 ms Clear with defaults, size 1024?1024 > clear-default-preserveDrawingBuffer.html 59 ms Clear with defaults, > with preserveDrawingBuffer, size 1024?1024 > clear-nondefault-constant-color.html 64 ms Clear with constant > non-default color, size 1024?1024 > clear-nondefault-constant-color-preserveDrawingBuffer.html 56 ms > Clear with constant non-default color, with preserveDrawingBuffer, > size 1024?1024 > clear-varying-color-and-readPixels.html 159 ms Clear with varying > color and readPixels, size 1024?1024 > clear-varying-color-and-readPixels-out-of-bounds.html 182 ms Clear > with varying color and readPixels out-of-bounds, size 1024?1024 > clear-varying-color.html 52 ms Clear with varying color, size > 1024?1024 > clear-varying-color-preserveDrawingBuffer.html 51 ms Clear with > varying color, with preserveDrawingBuffer, size 1024?1024 > convert-Canvas-to-a8.html 14 ms Texture conversion, from 1024?1024 > Canvas to A8 unpremult. > convert-Canvas-to-a8-premultiplied.html 14 ms Texture conversion, > from 1024?1024 Canvas to A8 premult. > convert-Canvas-to-l8.html 76 ms Texture conversion, from 1024?1024 > Canvas to L8 unpremult. > convert-Canvas-to-l8-premultiplied.html 15 ms Texture conversion, > from 1024?1024 Canvas to L8 premult. > convert-Canvas-to-rgb565.html 109 ms Texture conversion, from > 1024?1024 Canvas to RGB565 unpremult. > convert-Canvas-to-rgb565-premultiplied.html 24 ms Texture > conversion, from 1024?1024 Canvas to RGB565 premult. > convert-Canvas-to-rgb888.html 107 ms Texture conversion, from > 1024?1024 Canvas to RGB888 unpremult. > convert-Canvas-to-rgb888-premultiplied.html 22 ms Texture > conversion, from 1024?1024 Canvas to RGB888 premult. > convert-Canvas-to-rgba4444.html 115 ms Texture conversion, from > 1024?1024 Canvas to RGBA4444 unpremult. > convert-Canvas-to-rgba4444-premultiplied.html 21 ms Texture > conversion, from 1024?1024 Canvas to RGBA4444 premult. > convert-Canvas-to-rgba8888.html 107 ms Texture conversion, from > 1024?1024 Canvas to RGBA8888 unpremult. > convert-Canvas-to-rgba8888-premultiplied.html 18 ms Texture > conversion, from 1024?1024 Canvas to RGBA8888 premult. > convert-Canvas-to-rgb-float.html Skipped Texture conversion, from > 1024?1024 Canvas to RGBA/float unpremult. > convert-Canvas-to-rgb-float-premultiplied.html Skipped Texture > conversion, from 1024?1024 Canvas to RGBA/float premult. > convert-ImageData-to-a8.html 7 ms Texture conversion, from > 1024?1024 ImageData to A8 unpremult. > convert-ImageData-to-a8-premultiplied.html 8 ms Texture conversion, > from 1024?1024 ImageData to A8 premult. > convert-ImageData-to-l8.html 8 ms Texture conversion, from > 1024?1024 ImageData to L8 unpremult. > convert-ImageData-to-l8-premultiplied.html 47 ms Texture > conversion, from 1024?1024 ImageData to L8 premult. > convert-ImageData-to-rgb565.html 17 ms Texture conversion, from > 1024?1024 ImageData to RGB565 unpremult. > convert-ImageData-to-rgb565-premultiplied.html 82 ms Texture > conversion, from 1024?1024 ImageData to RGB565 premult. > convert-ImageData-to-rgb888.html 15 ms Texture conversion, from > 1024?1024 ImageData to RGB888 unpremult. > convert-ImageData-to-rgb888-premultiplied.html 82 ms Texture > conversion, from 1024?1024 ImageData to RGB888 premult. > convert-ImageData-to-rgba4444.html 16 ms Texture conversion, from > 1024?1024 ImageData to RGBA4444 unpremult. > convert-ImageData-to-rgba4444-premultiplied.html 87 ms Texture > conversion, from 1024?1024 ImageData to RGBA4444 premult. > convert-ImageData-to-rgba8888.html 14 ms Texture conversion, from > 1024?1024 ImageData to RGBA8888 unpremult. > convert-ImageData-to-rgba8888-premultiplied.html 84 ms Texture > conversion, from 1024?1024 ImageData to RGBA8888 premult. > convert-ImageData-to-rgb-float.html Skipped Texture conversion, > from 1024?1024 ImageData to RGBA/float unpremult. > convert-ImageData-to-rgb-float-premultiplied.html Skipped Texture > conversion, from 1024?1024 ImageData to RGBA/float premult. > convert-Image-to-a8.html 11 ms Texture conversion, from 1024?1024 > Image to A8 unpremult. > convert-Image-to-a8-premultiplied.html 12 ms Texture conversion, > from 1024?1024 Image to A8 premult. > convert-Image-to-l8.html 16 ms Texture conversion, from 1024?1024 > Image to L8 unpremult. > convert-Image-to-l8-premultiplied.html 15 ms Texture conversion, > from 1024?1024 Image to L8 premult. > convert-Image-to-rgb565.html 21 ms Texture conversion, from > 1024?1024 Image to RGB565 unpremult. > convert-Image-to-rgb565-premultiplied.html 20 ms Texture > conversion, from 1024?1024 Image to RGB565 premult. > convert-Image-to-rgb888.html 21 ms Texture conversion, from > 1024?1024 Image to RGB888 unpremult. > convert-Image-to-rgb888-premultiplied.html 22 ms Texture > conversion, from 1024?1024 Image to RGB888 premult. > convert-Image-to-rgba4444.html 20 ms Texture conversion, from > 1024?1024 Image to RGBA4444 unpremult. > convert-Image-to-rgba4444-premultiplied.html 21 ms Texture > conversion, from 1024?1024 Image to RGBA4444 premult. > convert-Image-to-rgba8888.html 19 ms Texture conversion, from > 1024?1024 Image to RGBA8888 unpremult. > convert-Image-to-rgba8888-premultiplied.html 17 ms Texture > conversion, from 1024?1024 Image to RGBA8888 premult. > convert-Image-to-rgb-float.html Skipped Texture conversion, from > 1024?1024 Image to RGBA/float unpremult. > convert-Image-to-rgb-float-premultiplied.html Skipped Texture > conversion, from 1024?1024 Image to RGBA/float premult. > decrement-dimensions.html 183 ms Decrement canvas dimensions, size > 1024?1024 > do-nothing.html 18 ms Do nothing, size 1024?1024 > do-nothing-preserveDrawingBuffer.html 17 ms Do nothing, with > preserveDrawingBuffer, size 1024?1024 > increment-dimensions.html 70 ms Increment canvas dimensions, size > 1024?1024 > texImage2D-null.html 1 ms texImage2D with null, repeated 10? > texImage2D-TypedArray.html 87 ms texImage2D with TypedArray, > repeated 10? > texSubImage2D-TypedArray.html 84 ms texSubImage2D with TypedArray, > repeated 10? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu Mar 29 19:55:37 2012 From: bja...@ (Benoit Jacob) Date: Thu, 29 Mar 2012 19:55:37 -0700 (PDT) Subject: [Public WebGL] WebGL performance regression tests! In-Reply-To: <376841800.601466.1333074259516.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <445265531.623410.1333076137380.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > ----- Original Message ----- > > On Thu, Mar 29, 2012 at 4:03 PM, Benoit Jacob < bjacob...@ > > > > > wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> On Thu, Mar 29, 2012 at 3:27 PM, Ilja Friedel < ihf...@ > > > >> wrote: > > > >> > On Thu, Mar 29, 2012 at 2:21 PM, Benoit Jacob < > > >> > bjacob...@ > > > > >> > wrote: > > > >> >> > > > >> >> > > > >> >> For what it's worth, the performance regression tests are now > > >> >> much > > > >> >> expanded, covering in particular the dreaded texture format > > > >> >> conversions. > > > >> >> > > > >> >> Still same URL: > > > >> >> > > > >> >> http://hg.mozilla.org/users/bjacob_mozilla.com/webgl-perf-tests/raw-file/tip/webgl-performance-tests.html > > > >> > > > > >> > > > > >> > I second the very nice. To run this in practice in a > > >> > regression > > > >> > suite one > > > >> > would need an easy way to adjust the work done for each > > >> > individual > > > >> > test to > > > >> > say 50ms or 100ms. Right now on my atom test runtimes are > > >> > between > > > >> > 8ms and > > > >> > 517ms. 8ms is awfully hard to distinguish from zero and > > >> > computing > > > >> > any sum > > > >> > (or even geometric mean) is dodgy. Maybe allow for some kind > > >> > of > > > >> > configuration/ parameterization of the number of loops running > > >> > for > > > >> > each > > > >> > test? > > > >> > > > >> Good point. The V8 benchmark suite generally runs each benchmark > > >> for > > > >> a > > > >> fixed period of time, say 2 seconds, and measures the number of > > > >> iterations of the test that can be performed in that time, > > >> rather > > > >> than > > > >> using a fixed number of iterations. This seems to be a pretty > > >> robust > > > >> methodology. > > > > > > > > The performance tests currently run until both conditions are > > > met: > > > they've either done 10 iterations, and run for at least 300 ms. > > > > > > > > See in WebGLPerformanceTest.js: > > > > > > > > WebGLPerformanceTest.prototype.hasRecordedEnoughFrames = > > > function(time) { > > > > // stop when we have recorded at least 10 frames and run for at > > > least 300 ms > > > > return this.timings.length > 10 && > > > > time - this.startTime > 300; > > > > } > > > > > > > > The final result is then computed as the median result among all > > > iterations/frames. > > > > > > > > So when you get "8 ms", it doesn't mean that the test stopped > > > after > > > 8 ms. It means that 8 ms is the median frame time. > > > In understand. And that means that we are mostly there! What I > > would > > like to see is (at least) 2 significant digits so one can pick up a > > 1 percent change in performance. In the run below (on an low end > > atom) many numbers are 20ms or below. This means that a change in > > performance is only detected when times changes more than 1ms/20ms > > or 5 percent. This problem obviously gets worse with faster > > hardware. > > Two problems here: > - I am not aware of timing mechanisms exposed to Javascript, that > would have better than millisecond precision. There is some > consensus at Mozilla to make that happen, but it hasn't happened yet > AFAIK. > - Most test results have more discrepancies across runs, than this > 1ms precision, anyway. So in most cases (including when the result > is < 10 ms) we often have a bigger problem here anyway. > Both can potentially be addressed by adding more workload to get > higher timings and reduce noise. > > Finally perf numbers are often aggregated into a single number by > > summing them up (bad!) or using a geometric mean (better, but > > problematic when we get many results). Either way I am worried what > > happens if the reported numbers start approaching zero. > > I was wondering if we would want such a synthetic measure. Let's give > them a chance to prove their usefulness ;-) Done. I'm excited because these averages, especially the geometric one, seem very stable across runs. Benoit > Benoit > > Ilja. > > > WebGL Performance Regression Test Results > > > Keep in mind that these tests are not realistic workloads. These > > are > > not benchmarks aiming to compare browser or GPU performance. These > > are only useful to catch performance regressions in a given browser > > and system. > > > Test page Result Description > > > clear-10x-default.html 484 ms Clear with defaults, repeated 10?, > > size 1024?1024 > > > clear-10x-nondefault-constant-color.html 332 ms Clear with > > constant > > non-default color, repeated 10?, size 1024?1024 > > > clear-default.html 51 ms Clear with defaults, size 1024?1024 > > > clear-default-preserveDrawingBuffer.html 59 ms Clear with > > defaults, > > with preserveDrawingBuffer, size 1024?1024 > > > clear-nondefault-constant-color.html 64 ms Clear with constant > > non-default color, size 1024?1024 > > > clear-nondefault-constant-color-preserveDrawingBuffer.html 56 ms > > Clear with constant non-default color, with preserveDrawingBuffer, > > size 1024?1024 > > > clear-varying-color-and-readPixels.html 159 ms Clear with varying > > color and readPixels, size 1024?1024 > > > clear-varying-color-and-readPixels-out-of-bounds.html 182 ms > > Clear > > with varying color and readPixels out-of-bounds, size 1024?1024 > > > clear-varying-color.html 52 ms Clear with varying color, size > > 1024?1024 > > > clear-varying-color-preserveDrawingBuffer.html 51 ms Clear with > > varying color, with preserveDrawingBuffer, size 1024?1024 > > > convert-Canvas-to-a8.html 14 ms Texture conversion, from > > 1024?1024 > > Canvas to A8 unpremult. > > > convert-Canvas-to-a8-premultiplied.html 14 ms Texture conversion, > > from 1024?1024 Canvas to A8 premult. > > > convert-Canvas-to-l8.html 76 ms Texture conversion, from > > 1024?1024 > > Canvas to L8 unpremult. > > > convert-Canvas-to-l8-premultiplied.html 15 ms Texture conversion, > > from 1024?1024 Canvas to L8 premult. > > > convert-Canvas-to-rgb565.html 109 ms Texture conversion, from > > 1024?1024 Canvas to RGB565 unpremult. > > > convert-Canvas-to-rgb565-premultiplied.html 24 ms Texture > > conversion, from 1024?1024 Canvas to RGB565 premult. > > > convert-Canvas-to-rgb888.html 107 ms Texture conversion, from > > 1024?1024 Canvas to RGB888 unpremult. > > > convert-Canvas-to-rgb888-premultiplied.html 22 ms Texture > > conversion, from 1024?1024 Canvas to RGB888 premult. > > > convert-Canvas-to-rgba4444.html 115 ms Texture conversion, from > > 1024?1024 Canvas to RGBA4444 unpremult. > > > convert-Canvas-to-rgba4444-premultiplied.html 21 ms Texture > > conversion, from 1024?1024 Canvas to RGBA4444 premult. > > > convert-Canvas-to-rgba8888.html 107 ms Texture conversion, from > > 1024?1024 Canvas to RGBA8888 unpremult. > > > convert-Canvas-to-rgba8888-premultiplied.html 18 ms Texture > > conversion, from 1024?1024 Canvas to RGBA8888 premult. > > > convert-Canvas-to-rgb-float.html Skipped Texture conversion, from > > 1024?1024 Canvas to RGBA/float unpremult. > > > convert-Canvas-to-rgb-float-premultiplied.html Skipped Texture > > conversion, from 1024?1024 Canvas to RGBA/float premult. > > > convert-ImageData-to-a8.html 7 ms Texture conversion, from > > 1024?1024 ImageData to A8 unpremult. > > > convert-ImageData-to-a8-premultiplied.html 8 ms Texture > > conversion, > > from 1024?1024 ImageData to A8 premult. > > > convert-ImageData-to-l8.html 8 ms Texture conversion, from > > 1024?1024 ImageData to L8 unpremult. > > > convert-ImageData-to-l8-premultiplied.html 47 ms Texture > > conversion, from 1024?1024 ImageData to L8 premult. > > > convert-ImageData-to-rgb565.html 17 ms Texture conversion, from > > 1024?1024 ImageData to RGB565 unpremult. > > > convert-ImageData-to-rgb565-premultiplied.html 82 ms Texture > > conversion, from 1024?1024 ImageData to RGB565 premult. > > > convert-ImageData-to-rgb888.html 15 ms Texture conversion, from > > 1024?1024 ImageData to RGB888 unpremult. > > > convert-ImageData-to-rgb888-premultiplied.html 82 ms Texture > > conversion, from 1024?1024 ImageData to RGB888 premult. > > > convert-ImageData-to-rgba4444.html 16 ms Texture conversion, from > > 1024?1024 ImageData to RGBA4444 unpremult. > > > convert-ImageData-to-rgba4444-premultiplied.html 87 ms Texture > > conversion, from 1024?1024 ImageData to RGBA4444 premult. > > > convert-ImageData-to-rgba8888.html 14 ms Texture conversion, from > > 1024?1024 ImageData to RGBA8888 unpremult. > > > convert-ImageData-to-rgba8888-premultiplied.html 84 ms Texture > > conversion, from 1024?1024 ImageData to RGBA8888 premult. > > > convert-ImageData-to-rgb-float.html Skipped Texture conversion, > > from 1024?1024 ImageData to RGBA/float unpremult. > > > convert-ImageData-to-rgb-float-premultiplied.html Skipped Texture > > conversion, from 1024?1024 ImageData to RGBA/float premult. > > > convert-Image-to-a8.html 11 ms Texture conversion, from 1024?1024 > > Image to A8 unpremult. > > > convert-Image-to-a8-premultiplied.html 12 ms Texture conversion, > > from 1024?1024 Image to A8 premult. > > > convert-Image-to-l8.html 16 ms Texture conversion, from 1024?1024 > > Image to L8 unpremult. > > > convert-Image-to-l8-premultiplied.html 15 ms Texture conversion, > > from 1024?1024 Image to L8 premult. > > > convert-Image-to-rgb565.html 21 ms Texture conversion, from > > 1024?1024 Image to RGB565 unpremult. > > > convert-Image-to-rgb565-premultiplied.html 20 ms Texture > > conversion, from 1024?1024 Image to RGB565 premult. > > > convert-Image-to-rgb888.html 21 ms Texture conversion, from > > 1024?1024 Image to RGB888 unpremult. > > > convert-Image-to-rgb888-premultiplied.html 22 ms Texture > > conversion, from 1024?1024 Image to RGB888 premult. > > > convert-Image-to-rgba4444.html 20 ms Texture conversion, from > > 1024?1024 Image to RGBA4444 unpremult. > > > convert-Image-to-rgba4444-premultiplied.html 21 ms Texture > > conversion, from 1024?1024 Image to RGBA4444 premult. > > > convert-Image-to-rgba8888.html 19 ms Texture conversion, from > > 1024?1024 Image to RGBA8888 unpremult. > > > convert-Image-to-rgba8888-premultiplied.html 17 ms Texture > > conversion, from 1024?1024 Image to RGBA8888 premult. > > > convert-Image-to-rgb-float.html Skipped Texture conversion, from > > 1024?1024 Image to RGBA/float unpremult. > > > convert-Image-to-rgb-float-premultiplied.html Skipped Texture > > conversion, from 1024?1024 Image to RGBA/float premult. > > > decrement-dimensions.html 183 ms Decrement canvas dimensions, > > size > > 1024?1024 > > > do-nothing.html 18 ms Do nothing, size 1024?1024 > > > do-nothing-preserveDrawingBuffer.html 17 ms Do nothing, with > > preserveDrawingBuffer, size 1024?1024 > > > increment-dimensions.html 70 ms Increment canvas dimensions, size > > 1024?1024 > > > texImage2D-null.html 1 ms texImage2D with null, repeated 10? > > > texImage2D-TypedArray.html 87 ms texImage2D with TypedArray, > > repeated 10? > > > texSubImage2D-TypedArray.html 84 ms texSubImage2D with > > TypedArray, > > repeated 10? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Thu Mar 29 21:05:01 2012 From: kos...@ (David Sheets) Date: Thu, 29 Mar 2012 21:05:01 -0700 Subject: [Public WebGL] OpenGL ES 2.0 GLSL Conformance Tests Published Message-ID: Many OpenGL ES 2.0 GLSL conformance tests were committed to the webgl SVN repository yesterday by Gregg Tavares in r17231. This is a major step for Khronos' web standards effort and significantly improves the status of ESSL as a bona fide WWW language. I am very grateful to Gregg Tavares, Ken Russell, Neil Trevett, and anonymous internal-to-Khronos champions who worked to format and publish these important tests. sdk/tests/conformance/ogles/GL/build appears to contain a number of stubs for important SL tests. What is the restriction preventing publication of these tests? Are these stubs for tests with more extensive API use? I hope that in the near future the revision process of the OpenGL ES 2.0 GLSL language and subsequent languages will at least admit observation by the soon-to-be majority stakeholder population of web shading language authors and tool-makers. Warm World Wide Web Wishes, David Sheets ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From mar...@ Fri Mar 30 07:15:17 2012 From: mar...@ (=?ISO-8859-1?Q?Markus_Sch=FCtz?=) Date: Fri, 30 Mar 2012 16:15:17 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: <-5513049632572584339@unknownmsgid> References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> <-5513049632572584339@unknownmsgid> Message-ID: <4F75BFF5.2030401@gmx.at> I'm writing an app that's targeted at middle class desktop systems and I'd love to have more features available on these platforms. Not just MRTs but also all the other ones that are rejected or would be rejected because not enough mobile platforms support it. Anyone who targets mobiles is free to ignore the extensions or make sure that enough devices support them. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From dma...@ Fri Mar 30 08:36:08 2012 From: dma...@ (Dustin Malik) Date: Fri, 30 Mar 2012 15:36:08 +0000 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> Message-ID: <7619E18BA0B61F47967F09DBBD9F335406C0A6@XMB113CNC.rim.net> Hi Everyone, I just wanted to bring to everyone's attention that the BlackBerry WebKit browser fully supports the WebGL spec on PlayBook and for BlackBerry 10 when it launches later this year. We are also supporting developers who develop applications using WebGL on our platform. Please check out this post on our development blog for more details - http://devblog.blackberry.com/2012/03/download-tunneltilt/ . Hopefully this isn't too shameless of a plug :) Regards, Dustin Malik Sr. Application Development Consultant - Developer Relations Research In Motion Limited [Description: cid:image001.gif...@] Register Now for BlackBerry 10 Jam - May 1-3 in Orlando, FL Join us for BlackBerry 10 Jam - a conference dedicated to providing the BlackBerry developer community with insights on the BlackBerry 10 platform. Don't miss this unparalleled opportunity to learn how to make applications that stand out! Register now at www.blackberryjamconference.com/registration Follow Us #BB10JAM: [Description: Facebook Icon] [Description: Twitter] [Description: YouTube] [Description: Dev Blog Icon - White] From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Kornmann, Ralf Sent: Wednesday, March 28, 2012 11:31 AM To: Florian B?sch; remi...@ Cc: Public Webgl Subject: RE: [Public WebGL] Adobe to tax 3D flash games But still no WebGL in mobile Safari and only very limited support on Android. So I am still at 30% on iOS. Beside of this the 9% for Flash are only in the case you have used some kind of cross compiler. From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Florian B?sch Sent: Wednesday, March 28, 2012 17:17 PM To: remi...@ Cc: Public Webgl Subject: Re: [Public WebGL] Adobe to tax 3D flash games On Wed, Mar 28, 2012 at 4:41 PM, R?mi Arnaud > wrote: slashgear.com/adobe-reveals-flash-tax-for-popular-developers-28220332/ iOS: custom built device ecosystem + iOS only runtime environment + app-store + dev tool = 30% of your revenue Adobe: desktop operating system only runtime environment + dev tool = 9% of your revenue WebGL: self publishing | a variety of app stores + cross operating system (mobiles+desktops) runtime environment + "dev tool" = 0% of your revenue Thank you Adobe :) --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2577 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 888 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1719 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 933 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 1020 bytes Desc: image005.jpg URL: From tpa...@ Fri Mar 30 08:42:23 2012 From: tpa...@ (Tony Parisi) Date: Fri, 30 Mar 2012 08:42:23 -0700 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: <7619E18BA0B61F47967F09DBBD9F335406C0A6@XMB113CNC.rim.net> References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> <7619E18BA0B61F47967F09DBBD9F335406C0A6@XMB113CNC.rim.net> Message-ID: Awesome Dustin! I for one don't mind the plug. Tony On Fri, Mar 30, 2012 at 8:36 AM, Dustin Malik wrote: > Hi Everyone,**** > > ** ** > > I just wanted to bring to everyone?s attention that the BlackBerry WebKit > browser fully supports the WebGL spec on PlayBook and for BlackBerry 10 > when it launches later this year. We are also supporting developers who > develop applications using WebGL on our platform. Please check out this > post on our development blog for more details - > http://devblog.blackberry.com/2012/03/download-tunneltilt/ . **** > > ** ** > > Hopefully this isn?t too shameless of a plug J**** > > ** ** > > Regards,**** > > ** ** > > *Dustin Malik* > Sr. Application Development Consultant ? Developer Relations > > Research In Motion Limited > > [image: Description: cid:image001.gif...@]**** > > ** ** > > *Register Now for BlackBerry 10 Jam ? May 1-3 in Orlando, FL* > > Join us for BlackBerry 10 Jam ? a conference dedicated to providing the > BlackBerry developer community with insights on the BlackBerry 10 platform. > Don?t miss this unparalleled opportunity to learn how to make applications > that stand out! Register now at > www.blackberryjamconference.com/registration **** > > ** ** > > *Follow Us #BB10JAM:* > > * * > > *[image: Description: Facebook Icon]* > * **[image: Description: Twitter]* > * **[image: Description: YouTube]* > * **[image: Description: Dev Blog Icon - White]* > **** > > ** ** > > ** ** > > *From:* owner-public_webgl...@ [mailto: > owner-public_webgl...@] *On Behalf Of *Kornmann, Ralf > *Sent:* Wednesday, March 28, 2012 11:31 AM > *To:* Florian B?sch; remi...@ > *Cc:* Public Webgl > *Subject:* RE: [Public WebGL] Adobe to tax 3D flash games**** > > ** ** > > But still no WebGL in mobile Safari and only very limited support on > Android. So I am still at 30% on iOS.**** > > ** ** > > Beside of this the 9% for Flash are only in the case you have used some > kind of cross compiler. **** > > ** ** > > ** ** > > *From:* owner-public_webgl...@ [mailto: > owner-public_webgl...@] *On Behalf Of *Florian B?sch > *Sent:* Wednesday, March 28, 2012 17:17 PM > *To:* remi...@ > *Cc:* Public Webgl > *Subject:* Re: [Public WebGL] Adobe to tax 3D flash games**** > > ** ** > > On Wed, Mar 28, 2012 at 4:41 PM, R?mi Arnaud wrote:**** > > slashgear.com/adobe-reveals-flash-tax-for-popular-developers-28220332/**** > > ** ** > > iOS: custom built device ecosystem + iOS only runtime environment + > app-store + dev tool = 30% of your revenue**** > > Adobe: desktop operating system only runtime environment + dev tool = 9% > of your revenue**** > > WebGL: self publishing | a variety of app stores + cross operating system > (mobiles+desktops) runtime environment + "dev tool" = 0% of your revenue** > ** > > ** ** > > Thank you Adobe :)**** > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > -- Tony Parisi tparisi...@ Founder, CEO Skybox Networks, Inc. CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 1020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1719 bytes Desc: not available URL: From jda...@ Fri Mar 30 09:16:15 2012 From: jda...@ (John Davis) Date: Fri, 30 Mar 2012 11:16:15 -0500 Subject: [Public WebGL] Webgl-Swiftshader-chrome18 Message-ID: It won't run under xp in a vm. Why not? -------------- next part -------------- An HTML attachment was scrubbed... URL: From van...@ Fri Mar 30 13:14:22 2012 From: van...@ (Vangelis Kokkevis) Date: Fri, 30 Mar 2012 13:14:22 -0700 Subject: [Public WebGL] Webgl-Swiftshader-chrome18 In-Reply-To: References: Message-ID: Do you see the SwiftShader dll's ? In windows xp they should be in: C:\Documents and Settings\\Local Settings\Application Data\Google\Chrome\User Data\SwiftShader\1.0.0.1 SwiftShader isn't packaged with the rest of the browser. It gets downloaded and installed only if needed and sometimes you have to wait a while for the download to kick in. What does your about:gpu page say? If it still an issue, please file a bug at: http://bugs.chromium.org . Cheers, Vangelis On Fri, Mar 30, 2012 at 9:16 AM, John Davis wrote: > It won't run under xp in a vm. Why not? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Mar 30 13:34:13 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 30 Mar 2012 22:34:13 +0200 Subject: [Public WebGL] Adobe to tax 3D flash games In-Reply-To: <7619E18BA0B61F47967F09DBBD9F335406C0A6@XMB113CNC.rim.net> References: <746932693-1332945693-cardhu_decombobulator_blackberry.rim.net-311873587-@b28.c1.bise6.blackberry> <9B3BEF16CBC82A45900B3F159DF91596017576F59869@EU-MAIL-1-1.rws.ad.ea.com> <7619E18BA0B61F47967F09DBBD9F335406C0A6@XMB113CNC.rim.net> Message-ID: On Fri, Mar 30, 2012 at 5:36 PM, Dustin Malik wrote: > Hi Everyone,**** > > ** ** > > I just wanted to bring to everyone?s attention that the BlackBerry WebKit > browser fully supports the WebGL spec on PlayBook and for BlackBerry 10 > when it launches later this year. We are also supporting developers who > develop applications using WebGL on our platform. Please check out this > post on our development blog for more details - > http://devblog.blackberry.com/2012/03/download-tunneltilt/ . > Awesome :) A few points I noticed looking at some logs for the playbook: - 8 vertex attributes is quite low (16 is more usual) - There's no combination of FBO that will accept a floating point texture - No stencil buffer (stencil buffer bits is 0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Mar 30 15:24:03 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 30 Mar 2012 15:24:03 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Wed, Mar 28, 2012 at 9:14 AM, Brandon Jones wrote: > I've been following this thread for a while and I have to admit that the > continued insistence on "protecting" WebGL from things that might not work > on mobile is very confusing to me. > > For one, there aren't a lot of mobile devices right now that can actually > support WebGL in any meaningful sense. Opera on Android seems to be the best > so far but even there the performance is pretty bad when you compare it to > what the device is actually capable of. In fact, the only mobile device I've > seen run WebGL respectably is the iPhone/iPad, and that's currently not > something you can see without having a developer account. Point being that > if we were to restrict ourselves to writing WebGL apps that work nicely > between mobile/desktop it would all look like Starfox for the time being. This is hardly a fair statement. First, there are plenty of mobile GPUs in existence that do a good job running good looking OpenGL ES 2.0 content. Second, during yesterday's WebGL conference call it was indicated by at least one browser vendor that performance issues in their WebGL implementation on Android were caused by inefficiencies in the browser, and were being worked on. There is an expectation that by years' end there will be well optimized WebGL implementations on current ES 2.0 hardware. It would be shortsighted to throw out the WebGL API's focus on portability now. > I do expect that situation to improve in leaps and bounds in the near > future, as I can see this easily becoming a selling point for mobile devices > and browsers, but in the meantime I see nothing wrong with wanting to flex > the?muscles?of WebGL on the desktop. Besides, isn't that why this is being > proposed as an extension and not a part of the base spec? It's common sense > to check to see if your extension query returned an object, at which point > it's on the developer to either take a different render path or notify the > user that their device doesn't meet the requirements for that app. Although > I would like to see as few apps as possible lock out mobile, I also don't > want to sacrifice the possibility of WebGL having it's own version of > the?Samaritan?demo at some point simply because not every WebGL capable > device can run it. There are at least four technical issues with adding arbitrary desktop functionality to WebGL as extensions. First, if there is no expectation that the functionality will appear on mobile hardware any time soon, then the nascent WebGL ecosystem will be fragmented. Second, if the functionality touches several areas of the OpenGL ES specification, it will be difficult to specify it, maintain it as a separate extension, and avoid poor interactions with other extensions. Third, the form of the functionality needs to be carefully thought through to avoid the situation that future mobile hardware integrates the functionality in a radically, or even subtly, different manner. Fourth, there is an expectation that official WebGL extensions will never be removed from browser implementations. See http://www.khronos.org/registry/webgl/extensions/ . To the fourth point, perhaps some extensions could be left in draft state indefinitely, until it becomes clear whether their functionality would ever be folded in to the core specification, and if so, in what form. I'm not sure whether this would help or hinder developers, since it would basically be a statement that at some point, the extension they are building on is going to be removed in favor of an alternative form. In the case of the MRT extension proposal, I've identified some technical issues. I'll reply to Gregg's email separately to detail them. I personally would not support adding extensions to WebGL that are not slated to appear on mobile hardware in some reasonable time frame. > That said, I do think it's sensible to try and inform users as much as > possible when their WebGL application is doing something that will not be > mobile-friendly, since the last thing we want is for people to?inadvertently > exclude mobile and not understand why. I've seen several charts tossed > around on the mailing list giving compatibility of feature X on chipset Y. > If those are available in a sensible format somewhere publicly (or can be > made so) I think it would be a great idea to put together some browser > extensions that monitor the extensions that a WebGL app loads and provide > the user with a "Mobile health report" for their app, detailing what > features they're using that may affect mobile compatibility. Alternately the > same extension could be used to "simulate" the?feature set?of a device class > by restricting the extensions that can be used. I'd be happy to help with > the development of such a tool if it gets us to stop bickering about what > features we can and can't support due to mobile. Such a tool would be useful. I believe Firefox has a mode where it restricts many WebGL parameters to their minimums to see whether the content will run on a hypothetical low-end OpenGL ES 2.0 device. If this were available in pure JS for WebGL, that would be useful for identifying not only the use of extensions that might not be universally available, but also incorrect assumptions being made about device capabilities affecting the behavior of the core spec. Personally, though, the existence of such a tool would not change my opinion above regarding adding functionality that definitely won't appear on mobile hardware in any reasonable time frame. -Ken > --Brandon > > On Wed, Mar 28, 2012 at 2:18 AM, Florian B?sch wrote: >> >> On Wed, Mar 28, 2012 at 4:44 AM, Mark Callow >> wrote: >>> >>> I do not understand your point. What is the pain you are referring to? >> >> Pain, conflict, clashing desires. You want two mutually exclusive things, >> MRTs and cross desktop/mobile compatibility. The discrepancy between >> desktops and mobiles is the measure of pain. It's 13% vs. 80%. So looking at >> it purely from a number point of view, your pain is ?67%. Desktops will grow >> the remaining 80% in the next 2 years or so to nearly 100%. How much will >> mobiles grow? 5%? 10%? So in two years we'll be talking a pain of 77% >> perhaps. If you're committed to waiting out the pain, you're in for a long >> wait. > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Mar 30 15:43:38 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 31 Mar 2012 00:43:38 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Sat, Mar 31, 2012 at 12:24 AM, Kenneth Russell wrote: > First, if there is no > expectation that the functionality will appear on mobile hardware any > time soon, I personally would not support adding extensions to WebGL that are not > slated to appear on mobile hardware in some reasonable time frame. All I'm hearing is "oh it's not coming for mobiles, therefore won't do". Is this confirmed? Is there some kind of official word on the ES workings on MRTs? Because if that's what it is. Then I have a radically different opinion. If Mobiles are *never* gonna support MRTs, then we can just as well add them to WebGL right now. Because, we're not gonna wait 10 or 20 years for them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Mar 30 15:50:40 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Fri, 30 Mar 2012 15:50:40 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Fri, Mar 30, 2012 at 3:24 PM, Kenneth Russell wrote: > > On Wed, Mar 28, 2012 at 9:14 AM, Brandon Jones wrote: > > I've been following this thread for a while and I have to admit that the > > continued insistence on "protecting" WebGL from things that might not > work > > on mobile is very confusing to me. > > > > For one, there aren't a lot of mobile devices right now that can actually > > support WebGL in any meaningful sense. Opera on Android seems to be the > best > > so far but even there the performance is pretty bad when you compare it > to > > what the device is actually capable of. In fact, the only mobile device > I've > > seen run WebGL respectably is the iPhone/iPad, and that's currently not > > something you can see without having a developer account. Point being > that > > if we were to restrict ourselves to writing WebGL apps that work nicely > > between mobile/desktop it would all look like Starfox for the time being. > > This is hardly a fair statement. First, there are plenty of mobile > GPUs in existence that do a good job running good looking OpenGL ES > 2.0 content. Second, during yesterday's WebGL conference call it was > indicated by at least one browser vendor that performance issues in > their WebGL implementation on Android were caused by inefficiencies in > the browser, and were being worked on. There is an expectation that by > years' end there will be well optimized WebGL implementations on > current ES 2.0 hardware. It would be shortsighted to throw out the > WebGL API's focus on portability now. > > > I do expect that situation to improve in leaps and bounds in the near > > future, as I can see this easily becoming a selling point for mobile > devices > > and browsers, but in the meantime I see nothing wrong with wanting to > flex > > the muscles of WebGL on the desktop. Besides, isn't that why this is > being > > proposed as an extension and not a part of the base spec? It's common > sense > > to check to see if your extension query returned an object, at which > point > > it's on the developer to either take a different render path or notify > the > > user that their device doesn't meet the requirements for that app. > Although > > I would like to see as few apps as possible lock out mobile, I also don't > > want to sacrifice the possibility of WebGL having it's own version of > > the Samaritan demo at some point simply because not every WebGL capable > > device can run it. > > There are at least four technical issues with adding arbitrary desktop > functionality to WebGL as extensions. First, if there is no > expectation that the functionality will appear on mobile hardware any > time soon, then the nascent WebGL ecosystem will be fragmented. > Second, if the functionality touches several areas of the OpenGL ES > specification, it will be difficult to specify it, maintain it as a > separate extension, and avoid poor interactions with other extensions. > Third, the form of the functionality needs to be carefully thought > through to avoid the situation that future mobile hardware integrates > the functionality in a radically, or even subtly, different manner. > Fourth, there is an expectation that official WebGL extensions will > never be removed from browser implementations. See > http://www.khronos.org/registry/webgl/extensions/ . > > To the fourth point, perhaps some extensions could be left in draft > state indefinitely, until it becomes clear whether their functionality > would ever be folded in to the core specification, and if so, in what > form. I'm not sure whether this would help or hinder developers, since > it would basically be a statement that at some point, the extension > they are building on is going to be removed in favor of an alternative > form. > > In the case of the MRT extension proposal, I've identified some > technical issues. I'll reply to Gregg's email separately to detail > them. > > I personally would not support adding extensions to WebGL that are not > slated to appear on mobile hardware in some reasonable time frame. > > > That said, I do think it's sensible to try and inform users as much as > > possible when their WebGL application is doing something that will not be > > mobile-friendly, since the last thing we want is for people > to inadvertently > > exclude mobile and not understand why. I've seen several charts tossed > > around on the mailing list giving compatibility of feature X on chipset > Y. > > If those are available in a sensible format somewhere publicly (or can be > > made so) I think it would be a great idea to put together some browser > > extensions that monitor the extensions that a WebGL app loads and provide > > the user with a "Mobile health report" for their app, detailing what > > features they're using that may affect mobile compatibility. Alternately > the > > same extension could be used to "simulate" the feature set of a device > class > > by restricting the extensions that can be used. I'd be happy to help with > > the development of such a tool if it gets us to stop bickering about what > > features we can and can't support due to mobile. > > Such a tool would be useful. I believe Firefox has a mode where it > restricts many WebGL parameters to their minimums to see whether the > content will run on a hypothetical low-end OpenGL ES 2.0 device. If > this were available in pure JS for WebGL, that would be useful for > identifying not only the use of extensions that might not be > universally available, but also incorrect assumptions being made about > device capabilities affecting the behavior of the core spec. > > Personally, though, the existence of such a tool would not change my > opinion above regarding adding functionality that definitely won't > appear on mobile hardware in any reasonable time frame. > The problem I have with this argument is it seems to be applied ad-hoc Today MRT = BAD even though a few mobile phones do support it Tomorrow MRT = OKAY just because it's added to some future GL ES spec even though there will still be few phones that support it. It will be 3-5 years before even 15% of phones support MRT or something other than OpenGL ES 2.0 So by the arguments made above WebGL 2.0 should not even be considered being worked on for 3-5 years. Even if a new ES spec appears, the arguments above say "no, if not enough phones". I feel like that's seriously limiting what people would like to do with WebGL for no good reason. The other idea put forward seems to be, no MRT for WebGL 1.0. MRT for WebGL 2.0 if the next version of ES supports MRT But given that it will be many years before a significant number of people have MRT phones you'll end up with the same situation as adding MRT to WebGL 1.0. Namely developers will do ctx.getContext("webgl-2.0") and if fails they'll either tell the user "S.O.L." or they will fall back to WebGL 1.0. How is that any different than exposing MRT in 1.0? > > -Ken > > > > --Brandon > > > > On Wed, Mar 28, 2012 at 2:18 AM, Florian B?sch wrote: > >> > >> On Wed, Mar 28, 2012 at 4:44 AM, Mark Callow > >> wrote: > >>> > >>> I do not understand your point. What is the pain you are referring to? > >> > >> Pain, conflict, clashing desires. You want two mutually exclusive > things, > >> MRTs and cross desktop/mobile compatibility. The discrepancy between > >> desktops and mobiles is the measure of pain. It's 13% vs. 80%. So > looking at > >> it purely from a number point of view, your pain is 67%. Desktops will > grow > >> the remaining 80% in the next 2 years or so to nearly 100%. How much > will > >> mobiles grow? 5%? 10%? So in two years we'll be talking a pain of 77% > >> perhaps. If you're committed to waiting out the pain, you're in for a > long > >> wait. > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Mar 30 15:52:53 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 30 Mar 2012 15:52:53 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Fri, Mar 30, 2012 at 3:43 PM, Florian B?sch wrote: > On Sat, Mar 31, 2012 at 12:24 AM, Kenneth Russell wrote: >> >> First, if there is no >> expectation that the functionality will appear on mobile hardware any >> time soon, > > >> I personally would not support adding extensions to WebGL that are not >> slated to appear on mobile hardware in some reasonable time frame. > > All I'm hearing is "oh it's not coming for mobiles, therefore won't do". You're misreading my email in that case. > Is this confirmed? Is there some kind of official word on the ES workings on > MRTs? Because if that's what it is. Then I have a radically different > opinion. If Mobiles are *never* gonna support MRTs, then we can just as well > add them to WebGL right now. Because, we're not gonna wait 10 or 20 years > for them. No, there is no official word from the OpenGL ES working group at the present time regarding the incorporation of MRTs or any other functionality in any hypothetical future release of any API or hardware. I'm sorry that I can't be more clear, but members of the WebGL WG are privy to information that we can not share publicly. In a public capacity, I think it is acceptable for WebGL WG members to guide the introduction of WebGL extensions in a way that seems that it would not contradict potential future directions of mobile hardware. For example, by examining the existing OpenGL 4.2 Core Profile spec, or extensions already proposed against OpenGL ES 2.0. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Mar 30 16:02:43 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 31 Mar 2012 01:02:43 +0200 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Sat, Mar 31, 2012 at 12:52 AM, Kenneth Russell wrote: > No, there is no official word from the OpenGL ES working group at the > present time regarding the incorporation of MRTs > We're not talking about anything but MRTs right now. And there is already one vendor extension (NV_fbo_color_attachment) that does it. I'm not asking for hypothethicals but for a specific direction. > In a public capacity, I think it is acceptable for WebGL WG members to > guide the introduction of WebGL extensions in a way that seems that it > would not contradict potential future directions of mobile hardware. I think we can all agree that we do not want to introduce an extension that contradicts the direction of the GL standards. However, there is a problem in that: - We don't get told what direction to go - We don't get a timeline until we'd be told - We don't get permission to go any direction at all in respects to MRTs I'm pretty sure that MRTs are coming, to any kind of 3D capable device sooner or later. I'm also pretty sure that it will look pretty much how MRTs are supported by devices that can do them right now. So I fundamentally do not agree with the "oh ye just sit on your hands" idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Fri Mar 30 16:08:53 2012 From: gle...@ (Glenn Maynard) Date: Fri, 30 Mar 2012 18:08:53 -0500 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Tue, Mar 27, 2012 at 2:38 PM, Gregg Tavares (?) wrote: > On Tue, Mar 27, 2012 at 11:31 AM, Kenneth Russell wrote: > >> It appears that only a tiny fraction of mobile devices support >> multiple render targets today >> > > 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. > ... and it's frustrating, as a developer (from time to time) of games, to be told that I'm not allowed to develop WebGL games unless they work on bottom-end devices that I'm not interested in targeting anyway. If you try to force developers to do extra work to support something that they don't want to, they'll turn their backs and keep writing native applications where they're allowed to make their own decisions. Prioritizing features and development time is fine. It's fine to say "we have limited resources, and we want to put them on other things right now". But, the "supported by mobile" metric just doesn't make any sense. That'll forever keep WebGL years behind competing platforms. Note that you *don't* need to worry about there not being any games that'll work on mobile if you expose non-mobile extensions. If you expose MRT and other currently desktop-class features to WebGL, many people will still want their games to work on mobile, and mobile systems will still have lots of reasons to support WebGL. You just need to make sure it's easy to do so (eg. a capability profile extension set). You don't need to try to force people to support mobile in 2012; that'll take care of itself. On Fri, Mar 30, 2012 at 5:24 PM, Kenneth Russell wrote: > First, if there is no expectation that the functionality will appear on > mobile hardware any > time soon, then the nascent WebGL ecosystem will be fragmented. > The "ecosystem" is inherently fragmented, since it's very easy to write software that requires GPU features (fill rate, texture units) that mobile hardware can't provide. Anyway, you always need to test on mobile if you want an app (especially a game) to work on it, since controls are so different. If you want your stuff to work well on mobile, you have to test on mobile already. You're not preventing fragmentation, you're preventing adoption. Making all WebGL apps "just work" on all systems is long lost. If you want to make it easy, for developers who *want* to (and that's a lot of them!), to write apps that will work on mobile, then you need a capability profile system. I've suggested this before ( https://www.khronos.org/webgl/public-mailing-list/archives/1109/msg00019.html), but didn't get any responses. I still think that's a good idea, even with the feature set that exists today, and I'd be happy to help hash out details for something like it if there's any serious interest in it. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Mar 30 16:15:15 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 30 Mar 2012 16:15:15 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 11:56 AM, Gregg Tavares (?) wrote: > So I've been meaning to propose this. Here's a first stab > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html A few technical issues: 1) I think it is also necessary to include the DrawBuffers entry point in this extension. Even when rendering to an FBO, DrawBuffers maps the color attachments to gl_FragData's indices. If DrawBuffers isn't included, then this extension defines behavior which would be divergent from, say, the OpenGL 4.2 core spec's behavior, or that of NV_draw_buffers. 2) Regarding "Referencing gl_FragData[n] where n is greater then the number of supported attachments will generate a GLSL compile or linker error.": it's not feasible to enforce this behavior. At best it would require extensive static analysis of shaders and at worst it won't be able to be determined at compile time. Instead, similar language to that in http://www.khronos.org/registry/webgl/specs/latest/#4.5 should be used; the behavior should be that the gl_FragData index is clamped between 0..getParameter(MAX_COLOR_ATTACHMENTS). 3) If the intent is to make this extension truly complete then there is a lot of spec language missing which affects the behavior of the OpenGL ES 2.0 pipeline. See for example http://www.khronos.org/registry/gles/extensions/NV/GL_NV_draw_buffers.txt . Note that despite the naming, NVIDIA's extension actually applies only to FBOs: "DrawBuffersNV may only be called when the GL is bound to a framebuffer object". As I see it, (3) is the most serious concern with introducing this particular extension. MRTs seem to modify the behavior of the OpenGL pipeline in several places. If future mobile hardware happens to come out with MRT support, but its semantics are slightly different than that in this extension, then it won't be possible to fold this extension into the core WebGL spec. I don't know how big a problem this would be. Maybe if a hypothetical WebGL 2.0 incorporated MRT support, then that context type could drop support for the "WEBGL_draw_buffers" extension. Or, per my other email, maybe this extension could be left in draft state indefinitely, so that it's always vendor prefixed and browsers wouldn't have to commit to supporting it forever. I think that the majority of this extension's behavior should be defined in an ANGLE extension, as has been done for some others; see http://code.google.com/p/angleproject/source/browse/trunk#trunk%2Fextensions . Then this WebGL extension could reference the other one. (The ANGLE extension would be needed anyway to make this functionality work in Chrome on Windows, and any other browsers using ANGLE.) -Ken > Whether there's any chance to get it approved by the group I don't know. > > Arguments for: > > *) Multiple render targets are super awesome! Lots, in fact most modern > graphics applications use this feature extensively. Supporting it will go a > long way to helping adoption of WebGL with more impressive apps. > > *) It's not really a new feature. No new APIs are added. It's similar to > texture fetch in vertex shaders where the max allowed is allowed to be 1. > > *) It's relatively easy to implement > > *) It doesn't raise any extra security or validation issues that I know of. > > Arguments against: > > *) Some mobile hardware only supports 1 target. > > I don't really see that as much a valid argument in that some day this > feature will be supported one way or another (WebGL 2.0?), at that point the > same issue will exist, some hardware will support 0, some 4, some 8, some > 16, etc.. Apps that use multiple render targets will have to have fallbacks > for hardware that doesn't support the number they ideally need.?So, why not > just expose it now? > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From toj...@ Fri Mar 30 16:18:04 2012 From: toj...@ (Brandon Jones) Date: Fri, 30 Mar 2012 16:18:04 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: <431760053.15155052.1332343796358.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4F727B00.1000001@hicorp.co.jp> Message-ID: On Fri, Mar 30, 2012 at 4:08 PM, Glenn Maynard wrote: > > Note that you *don't* need to worry about there not being any games > that'll work on mobile if you expose non-mobile extensions. If you expose > MRT and other currently desktop-class features to WebGL, many people will > still want their games to work on mobile, and mobile systems will still > have lots of reasons to support WebGL. > > Completely agree! I also think it's somewhat misguided to think that developers can and should try to create the same experience in both places. A pet idea of mine for a while now would be to have a squad-based shooter where desktop players all use first-person controls with detailed graphics, but players can also join in with a tablet or phone to get an simplified overhead "commanders" view, and issue orders or call in airstrikes from there, etc. It would create a compelling experience for both devices within the same game without trying to force those devices to try and support an experience not designed for them. Those type of experiences will work best, though, if each platform is given the opportunity to really embrace their own strong points. --Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Fri Mar 30 16:33:39 2012 From: kos...@ (David Sheets) Date: Fri, 30 Mar 2012 16:33:39 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Fri, Mar 30, 2012 at 4:15 PM, Kenneth Russell wrote: > > On Tue, Mar 20, 2012 at 11:56 AM, Gregg Tavares (?) wrote: >> So I've been meaning to propose this. Here's a first stab >> >> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html > > A few technical issues: > > 1) I think it is also necessary to include the DrawBuffers entry point > in this extension. Even when rendering to an FBO, DrawBuffers maps the > color attachments to gl_FragData's indices. If DrawBuffers isn't > included, then this extension defines behavior which would be > divergent from, say, the OpenGL 4.2 core spec's behavior, or that of > NV_draw_buffers. > > 2) Regarding "Referencing gl_FragData[n] where n is greater then the > number of supported attachments will generate a GLSL compile or linker > error.": it's not feasible to enforce this behavior. At best it would > require extensive static analysis of shaders and at worst it won't be > able to be determined at compile time. Instead, similar language to > that in http://www.khronos.org/registry/webgl/specs/latest/#4.5 should > be used; the behavior should be that the gl_FragData index is clamped > between 0..getParameter(MAX_COLOR_ATTACHMENTS). Array accesses are already restricted to constant integer expressions. What is this extensive static analysis that would be required? In what case would the gl_FragData index be undeterminable at compile time? > 3) If the intent is to make this extension truly complete then there > is a lot of spec language missing which affects the behavior of the > OpenGL ES 2.0 pipeline. See for example > http://www.khronos.org/registry/gles/extensions/NV/GL_NV_draw_buffers.txt > . Note that despite the naming, NVIDIA's extension actually applies > only to FBOs: "DrawBuffersNV may only be called when the GL is bound > to a framebuffer object". > > As I see it, (3) is the most serious concern with introducing this > particular extension. MRTs seem to modify the behavior of the OpenGL > pipeline in several places. If future mobile hardware happens to come > out with MRT support, but its semantics are slightly different than > that in this extension, then it won't be possible to fold this > extension into the core WebGL spec. I don't know how big a problem > this would be. Maybe if a hypothetical WebGL 2.0 incorporated MRT > support, then that context type could drop support for the > "WEBGL_draw_buffers" extension. Or, per my other email, maybe this > extension could be left in draft state indefinitely, so that it's > always vendor prefixed and browsers wouldn't have to commit to > supporting it forever. > > I think that the majority of this extension's behavior should be > defined in an ANGLE extension, as has been done for some others; see > http://code.google.com/p/angleproject/source/browse/trunk#trunk%2Fextensions > . Then this WebGL extension could reference the other one. (The ANGLE > extension would be needed anyway to make this functionality work in > Chrome on Windows, and any other browsers using ANGLE.) > > -Ken > > >> Whether there's any chance to get it approved by the group I don't know. >> >> Arguments for: >> >> *) Multiple render targets are super awesome! Lots, in fact most modern >> graphics applications use this feature extensively. Supporting it will go a >> long way to helping adoption of WebGL with more impressive apps. >> >> *) It's not really a new feature. No new APIs are added. It's similar to >> texture fetch in vertex shaders where the max allowed is allowed to be 1. >> >> *) It's relatively easy to implement >> >> *) It doesn't raise any extra security or validation issues that I know of. >> >> Arguments against: >> >> *) Some mobile hardware only supports 1 target. >> >> I don't really see that as much a valid argument in that some day this >> feature will be supported one way or another (WebGL 2.0?), at that point the >> same issue will exist, some hardware will support 0, some 4, some 8, some >> 16, etc.. Apps that use multiple render targets will have to have fallbacks >> for hardware that doesn't support the number they ideally need.?So, why not >> just expose it now? >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri Mar 30 16:43:40 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 30 Mar 2012 16:43:40 -0700 Subject: [Public WebGL] The state of MRTs In-Reply-To: References: Message-ID: On Fri, Mar 30, 2012 at 4:33 PM, David Sheets wrote: > On Fri, Mar 30, 2012 at 4:15 PM, Kenneth Russell wrote: >> >> On Tue, Mar 20, 2012 at 11:56 AM, Gregg Tavares (?) wrote: >>> So I've been meaning to propose this. Here's a first stab >>> >>> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html >> >> A few technical issues: >> >> 1) I think it is also necessary to include the DrawBuffers entry point >> in this extension. Even when rendering to an FBO, DrawBuffers maps the >> color attachments to gl_FragData's indices. If DrawBuffers isn't >> included, then this extension defines behavior which would be >> divergent from, say, the OpenGL 4.2 core spec's behavior, or that of >> NV_draw_buffers. >> >> 2) Regarding "Referencing gl_FragData[n] where n is greater then the >> number of supported attachments will generate a GLSL compile or linker >> error.": it's not feasible to enforce this behavior. At best it would >> require extensive static analysis of shaders and at worst it won't be >> able to be determined at compile time. Instead, similar language to >> that in http://www.khronos.org/registry/webgl/specs/latest/#4.5 should >> be used; the behavior should be that the gl_FragData index is clamped >> between 0..getParameter(MAX_COLOR_ATTACHMENTS). > > Array accesses are already restricted to constant integer expressions. > What is this extensive static analysis that would be required? In what > case would the gl_FragData index be undeterminable at compile time? It would be necessary to compute the minimum and maximum values for the index expression as the loop iteration variable goes through its range, and the math in the expression can potentially be complex. ANGLE's shader translator doesn't contain any loop analysis code right now and I think it's overkill to require its introduction just for this extension so that the shader compilation can fail. All of the other out-of-range array access behavior in the WebGL spec is defined in a way that allows simple but secure implementations. -Ken >> 3) If the intent is to make this extension truly complete then there >> is a lot of spec language missing which affects the behavior of the >> OpenGL ES 2.0 pipeline. See for example >> http://www.khronos.org/registry/gles/extensions/NV/GL_NV_draw_buffers.txt >> . Note that despite the naming, NVIDIA's extension actually applies >> only to FBOs: "DrawBuffersNV may only be called when the GL is bound >> to a framebuffer object". >> >> As I see it, (3) is the most serious concern with introducing this >> particular extension. MRTs seem to modify the behavior of the OpenGL >> pipeline in several places. If future mobile hardware happens to come >> out with MRT support, but its semantics are slightly different than >> that in this extension, then it won't be possible to fold this >> extension into the core WebGL spec. I don't know how big a problem >> this would be. Maybe if a hypothetical WebGL 2.0 incorporated MRT >> support, then that context type could drop support for the >> "WEBGL_draw_buffers" extension. Or, per my other email, maybe this >> extension could be left in draft state indefinitely, so that it's >> always vendor prefixed and browsers wouldn't have to commit to >> supporting it forever. >> >> I think that the majority of this extension's behavior should be >> defined in an ANGLE extension, as has been done for some others; see >> http://code.google.com/p/angleproject/source/browse/trunk#trunk%2Fextensions >> . Then this WebGL extension could reference the other one. (The ANGLE >> extension would be needed anyway to make this functionality work in >> Chrome on Windows, and any other browsers using ANGLE.) >> >> -Ken >> >> >>> Whether there's any chance to get it approved by the group I don't know. >>> >>> Arguments for: >>> >>> *) Multiple render targets are super awesome! Lots, in fact most modern >>> graphics applications use this feature extensively. Supporting it will go a >>> long way to helping adoption of WebGL with more impressive apps. >>> >>> *) It's not really a new feature. No new APIs are added. It's similar to >>> texture fetch in vertex shaders where the max allowed is allowed to be 1. >>> >>> *) It's relatively easy to implement >>> >>> *) It doesn't raise any extra security or validation issues that I know of. >>> >>> Arguments against: >>> >>> *) Some mobile hardware only supports 1 target. >>> >>> I don't really see that as much a valid argument in that some day this >>> feature will be supported one way or another (WebGL 2.0?), at that point the >>> same issue will exist, some hardware will support 0, some 4, some 8, some >>> 16, etc.. Apps that use multiple render targets will have to have fallbacks >>> for hardware that doesn't support the number they ideally need.?So, why not >>> just expose it now? >>> >>> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Sat Mar 31 04:08:34 2012 From: jda...@ (John Davis) Date: Sat, 31 Mar 2012 06:08:34 -0500 Subject: [Public WebGL] Webgl-Swiftshader-chrome18 In-Reply-To: References: Message-ID: The SwiftShader directory gets created, however it is empty. See bug for about:gpu Issue 121271 :SwiftShader not load if gpu not present On Fri, Mar 30, 2012 at 3:14 PM, Vangelis Kokkevis wrote: > Do you see the SwiftShader dll's ? In windows xp they should be in: > > C:\Documents and Settings\\Local Settings\Application > Data\Google\Chrome\User Data\SwiftShader\1.0.0.1 > > SwiftShader isn't packaged with the rest of the browser. It gets > downloaded and installed only if needed and sometimes you have to wait a > while for the download to kick in. > > What does your about:gpu page say? > > If it still an issue, please file a bug at: http://bugs.chromium.org . > > Cheers, > Vangelis > > > > On Fri, Mar 30, 2012 at 9:16 AM, John Davis wrote: > >> It won't run under xp in a vm. Why not? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzb...@ Sat Mar 31 06:54:45 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 09:54:45 -0400 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER Message-ID: <4F770CA5.5000600@mit.edu> All it says is: Bind the given WebGLFramebuffer object to the given binding point (target), which must be FRAMEBUFFER. What should happen when target is not a FRAMEBUFFER? An exception? (If so which one?) Silently doing nothing? This needs to be defined... -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 07:03:24 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 10:03:24 -0400 Subject: [Public WebGL] Should WebGLContextAttributes be a callback interface? Message-ID: <4F770EAC.8000806@mit.edu> https://www.khronos.org/registry/webgl/specs/latest/#5.2 says yes. https://www.khronos.org/registry/webgl/specs/latest/webgl.idl says no. Is the mismatch expected? I'm not sure why this is declared as a callback interface. https://www.khronos.org/registry/webgl/specs/latest/#2.1 talks about using the options object passed to getContext to set up the WebGLContextAttributes, but that doesn't require the WebGLContextAttributes to be a callback interface. Is the expectation that getContextAttributes will return the same object (when compared with === in JS, say) as was passed to getContext(), or a new object which only has the relevant attributes on it? In any case, it seems like the attributes should be readonly, right? -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 07:05:07 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 10:05:07 -0400 Subject: [Public WebGL] Vestigial module syntax in the IDL Message-ID: <4F770F13.8040907@mit.edu> https://www.khronos.org/registry/webgl/specs/latest/#5.1 has: typedef events::Event Event; typedef html::HTMLCanvasElement HTMLCanvasElement; typedef html::HTMLImageElement HTMLImageElement; typedef html::HTMLVideoElement HTMLVideoElement; typedef html::ImageData ImageData; and of course https://www.khronos.org/registry/webgl/specs/latest/webgl.idl is still using all sorts of module syntax. I thought that was mostly removed back in January (c.f. ); does this file just need updating? -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Sat Mar 31 07:27:14 2012 From: gle...@ (Glenn Maynard) Date: Sat, 31 Mar 2012 09:27:14 -0500 Subject: [Public WebGL] Should WebGLContextAttributes be a callback interface? In-Reply-To: <4F770EAC.8000806@mit.edu> References: <4F770EAC.8000806@mit.edu> Message-ID: On Sat, Mar 31, 2012 at 9:03 AM, Boris Zbarsky wrote: > > https://www.khronos.org/**registry/webgl/specs/latest/#**5.2says yes. > > https://www.khronos.org/**registry/webgl/specs/latest/**webgl.idlsays no. > > Is the mismatch expected? > The IDL is out of date. It doesn't reflect the nullable changes made recently, either. I'm not sure why this is declared as a callback interface. > https://www.khronos.org/**registry/webgl/specs/latest/#**2.1talks about using the options object passed to getContext to set up the > WebGLContextAttributes, but that doesn't require the WebGLContextAttributes > to be a callback interface. The idea is that the object you pass to getContext *is* a WebGLContextAttributes, as if getContext's signature is WebGLContext getContext(DOMString contextId, WebGLContextAttributes attrs), so WebIDL takes care of type conversions for the members. This could also be done by defining it as a WebIDL dictionary. It would be unusual for getContextAttributes to return a WebIDL dictionary instead of an interface, and while it could define the type twice (as both a dictionary and an interface), I'm not sure that actually gains anything. Is the expectation that getContextAttributes will return the same object > (when compared with === in JS, say) as was passed to getContext(), or a new > object which only has the relevant attributes on it? > No, because getContextAttributes says "Returns a *new*WebGLContextAttributes object". > In any case, it seems like the attributes should be readonly, right? > Yeah, probably. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzb...@ Sat Mar 31 07:32:50 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 10:32:50 -0400 Subject: [Public WebGL] Use of invalid type "unsigned byte" in the WebGL idl Message-ID: <4F771592.4080906@mit.edu> The relevant line is: typedef unsigned byte GLubyte; Quite apart from GLubyte being unused in the spec, this is not valid WebIDL. There is no "unsigned byte" type in WebIDL; there is a "byte" type for integers in [-128,127] and an "octet" type for integers in [0,255]. Presumably this typedef, if needed at all, should be "typedef octet GLubyte;". -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Sat Mar 31 07:35:52 2012 From: gle...@ (Glenn Maynard) Date: Sat, 31 Mar 2012 09:35:52 -0500 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: <4F770CA5.5000600@mit.edu> References: <4F770CA5.5000600@mit.edu> Message-ID: On Sat, Mar 31, 2012 at 8:54 AM, Boris Zbarsky wrote: > > All it says is: > > Bind the given WebGLFramebuffer object to the given binding point > (target), which must be FRAMEBUFFER. > > What should happen when target is not a FRAMEBUFFER? An exception? (If > so which one?) Silently doing nothing? > > This needs to be defined... > WebGL depends on OpenGL ES for a lot of its particulars. There are links to the relevant spec next to the function. Unfortunately, since they're PDFs, the section links almost never work so you have to find the section yourself, and it's a pain to read. I wish they'd bring those specs out of the PDF dark ages (but of the list of things Khronos needs to fix, that fight's far down the list, I suppose). That said, ES doesn't actually seem to say what happens here, either. Other functions define it: > enum CheckFramebufferStatus( enum target ); > If target is not FRAMEBUFFER, INVALID_ENUM is generated. If CheckFramebufferStatus generates an error, 0 is returned. but bindFrameBuffer doesn't seem to have this text. That looks like an oversight, but maybe it's defined less clearly somewhere else. GL_INVALID_ENUM is the correct answer, though. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Sat Mar 31 07:39:12 2012 From: cvi...@ (Cedric Vivier) Date: Sat, 31 Mar 2012 15:39:12 +0100 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: <4F770CA5.5000600@mit.edu> References: <4F770CA5.5000600@mit.edu> Message-ID: On Sat, Mar 31, 2012 at 14:54, Boris Zbarsky wrote: > What should happen when target is not a FRAMEBUFFER? ?An exception? ?(If so > which one?) Silently doing nothing? > > This needs to be defined... It is defined in the referenced OpenGL ES 2.0 specification ?4.4.3 : "INVALID_ENUM is generated if target is not FRAMEBUFFER" We do not duplicate all of ES specification for each and every function, hence the references. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 07:42:14 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 10:42:14 -0400 Subject: [Public WebGL] Should WebGLContextAttributes be a callback interface? In-Reply-To: References: <4F770EAC.8000806@mit.edu> Message-ID: <4F7717C6.8060603@mit.edu> On 3/31/12 10:27 AM, Glenn Maynard wrote: > The IDL is out of date. OK. Can the spec at least not link to it, then? The current setup is ... confusing at best. > The idea is that the object you pass to getContext *is* a > WebGLContextAttributes, as if getContext's signature is WebGLContext > getContext(DOMString contextId, WebGLContextAttributes attrs), so WebIDL > takes care of type conversions for the members. Hmm. I guess there's no way to actually express this as WebIDL because the second argument would need to be of different callback types depending on the string value of the first argument and callback types are not distinguishable? But that also means that WebIDL cannot in fact really take care of the type conversions, since WebIDL isn't actually being used to define this. I wonder whether it would be worthwhile to extend overload resolution in WebIDL to handle this case by introducing the ability to declare overloads where an argument is a constant and treating all constants as distinguishable. So then the IDL for getContext could look like this: getContext(DOMString "webgl", WebGLContextAttributes attrs); or something... The syntax could obviously use improving. > This could also be done by defining it as a WebIDL dictionary. Another option would be to define the getContext() argument as a dictionary but the return value of getContextAttributes as a non-callback type. Assuming that's useful, of course. The behavior would obviously be observably different (e.g. the properties would then live on the prototype), but I'm not sure that gets us anything useful. So yeah, probably OK leaving this as a callback. > No, because getContextAttributes says "Returns a /new/ > WebGLContextAttributes object". Aha! Thanks. -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 07:50:08 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 10:50:08 -0400 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: References: <4F770CA5.5000600@mit.edu> Message-ID: <4F7719A0.90302@mit.edu> On 3/31/12 10:35 AM, Glenn Maynard wrote: > WebGL depends on OpenGL ES for a lot of its particulars. There are > links to the relevant spec next to the function. Yes, I understand that. > but bindFrameBuffer doesn't seem to have this text. That looks like an > oversight, but maybe it's defined less clearly somewhere else. > > GL_INVALID_ENUM is the correct answer, though. Yes, but nothing in WebGL seems to define what should happen with GL_INVALID_ENUM in the ES binding. Is the call silently ignored but the return value of getError() on the context object changed to GL_INVALID_ENUM? Is an exception raised? If the latter, how is GL_INVALID_ENUM converted to an exception? I'm guessing, based on thirdhand information, that the call is silently ignored but getError() will return GL_INVALID_ENUM if called after that.... But that's not actually in the spec anywhere that I can find. Simply defining "generate a XXXXXX error" (which is used all over in the spec) would go a long ways here. -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 07:52:08 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 10:52:08 -0400 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: References: <4F770CA5.5000600@mit.edu> Message-ID: <4F771A18.5050708@mit.edu> On 3/31/12 10:39 AM, Cedric Vivier wrote: > On Sat, Mar 31, 2012 at 14:54, Boris Zbarsky wrote: >> What should happen when target is not a FRAMEBUFFER? An exception? (If so >> which one?) Silently doing nothing? >> >> This needs to be defined... > > It is defined in the referenced OpenGL ES 2.0 specification ?4.4.3 : > "INVALID_ENUM is generated if target is not FRAMEBUFFER" > > We do not duplicate all of ES specification for each and every > function, hence the references. I think the confusion arose because the spec does duplicate a normative authoring requirement but doesn't duplicate the behavior that needs to happen when the requirement is not met. It would actually be less confusing to not duplicate only part of the requirements that way.... -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cvi...@ Sat Mar 31 07:59:13 2012 From: cvi...@ (Cedric Vivier) Date: Sat, 31 Mar 2012 15:59:13 +0100 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: <4F7719A0.90302@mit.edu> References: <4F770CA5.5000600@mit.edu> <4F7719A0.90302@mit.edu> Message-ID: On Sat, Mar 31, 2012 at 15:50, Boris Zbarsky wrote: > Is the call silently ignored but the return value of getError() on the context object changed to GL_INVALID_ENUM? Yes. >Is an exception raised? No. >If the latter, how is GL_INVALID_ENUM converted to an exception? There's a number of ways to have this behavior when desired, including: http://www.khronos.org/webgl/wiki/Debugging > I'm guessing, based on thirdhand information, that the call is silently > ignored but getError() will return GL_INVALID_ENUM if called after that.... > ?But that's not actually in the spec anywhere that I can find. It is defined in the referenced glBindFramebuffer man page : http://www.khronos.org/opengles/sdk/docs/man/xhtml/glBindFramebuffer.xml > Simply > defining "generate a XXXXXX error" (which is used all over in the spec) > would go a long ways here. Yes, we probably should add this. Perhaps we should also explicitly define that in case of doubt on undefined behavior, the referenced ES 2.0 spec or man pages take precedence. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Sat Mar 31 08:10:05 2012 From: gle...@ (Glenn Maynard) Date: Sat, 31 Mar 2012 10:10:05 -0500 Subject: [Public WebGL] Should WebGLContextAttributes be a callback interface? In-Reply-To: <4F7717C6.8060603@mit.edu> References: <4F770EAC.8000806@mit.edu> <4F7717C6.8060603@mit.edu> Message-ID: I forgot, I talked with Cameron on IRC a while back about the dictionary vs. callback thing: http://krijnhoetmer.nl/irc-logs/whatwg/20111208#l-281 The short of it is that if callback is used, all of the members need to be nullable, since they're all optional when passed to getContext; or else getContext will get a TypeError when reading them, I think? I'm not sure. On Sat, Mar 31, 2012 at 9:42 AM, Boris Zbarsky wrote: > The idea is that the object you pass to getContext *is* a >> WebGLContextAttributes, as if getContext's signature is WebGLContext >> getContext(DOMString contextId, WebGLContextAttributes attrs), so WebIDL >> takes care of type conversions for the members. >> > > Hmm. I guess there's no way to actually express this as WebIDL because > the second argument would need to be of different callback types depending > on the string value of the first argument and callback types are not > distinguishable? > > But that also means that WebIDL cannot in fact really take care of the > type conversions, since WebIDL isn't actually being used to define this. > I agree that it's currently underdefined. I recommended defining this explicitly: https://www.khronos.org/webgl/public-mailing-list/archives/1112/msg00037.html("Convert options to an IDL value of type WebGLContextAttributesInit..."). I think that fell through the cracks (ping @ Kenneth). > I wonder whether it would be worthwhile to extend overload resolution in > WebIDL to handle this case by introducing the ability to declare overloads > where an argument is a constant and treating all constants as > distinguishable. So then the IDL for getContext could look like this: > > getContext(DOMString "webgl", WebGLContextAttributes attrs); > > or something... The syntax could obviously use improving. Honestly, I'm not sure I'm a fan of the "single getContext method" approach in the first place. I think it would have been better to have context specs define their own getContext method (eg. getWebGLContext) supplementing HTMLCanvasElement, and for Context to just give a framework for that. Oh, well. I'm not sure if a syntax specifically for this would be a good idea, because I'm not sure people should be mimicing it and there's only one place it'd be used right now (2d canvas doesn't take any other parameters)... This could also be done by defining it as a WebIDL dictionary. >> > > Another option would be to define the getContext() argument as a > dictionary but the return value of getContextAttributes as a non-callback > type. Assuming that's useful, of course. The behavior would obviously be > observably different (e.g. the properties would then live on the > prototype), but I'm not sure that gets us anything useful. So yeah, > probably OK leaving this as a callback. > Right, the type would have to be defined twice, which would be a bit redundant, though it'll always be a simple type so it's not that big a deal. You *can* return a dictionary type from functions, so it could, in fact, just define a dictionary used by both getContext and getContextAttributes. It'd lose the interface, but I can't think of any use cases for an interface there anyway. But I guess there's otherwise no real difference between doing that and just making the attributes nullable. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Sat Mar 31 08:23:22 2012 From: gle...@ (Glenn Maynard) Date: Sat, 31 Mar 2012 10:23:22 -0500 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: References: <4F770CA5.5000600@mit.edu> Message-ID: On Sat, Mar 31, 2012 at 9:39 AM, Cedric Vivier wrote: > On Sat, Mar 31, 2012 at 14:54, Boris Zbarsky wrote: > > What should happen when target is not a FRAMEBUFFER? An exception? (If > so > > which one?) Silently doing nothing? > > > > This needs to be defined... > > It is defined in the referenced OpenGL ES 2.0 specification ?4.4.3 : > "INVALID_ENUM is generated if target is not FRAMEBUFFER" > Section 4.4.3 covers renderbuffers, not framebuffers. bindFrameBuffer is in section 4.4.1, and I don't see any mention of INVALID_ENUM in 4.4.1. Unless I'm missing it, this seems like an oversight in the spec. > I'm guessing, based on thirdhand information, that the call is silently > > ignored but getError() will return GL_INVALID_ENUM if called after > that.... > > But that's not actually in the spec anywhere that I can find. > > It is defined in the referenced glBindFramebuffer man page : > http://www.khronos.org/opengles/sdk/docs/man/xhtml/glBindFramebuffer.xml > Manpages aren't specifications, they're user documentation. They're not appropriate as normative definitions; this needs to be defined in the OpenGL ES spec. On Sat, Mar 31, 2012 at 9:50 AM, Boris Zbarsky wrote: > Yes, but nothing in WebGL seems to define what should happen with > GL_INVALID_ENUM in the ES binding. > The ES spec defines what generating an error does, in section 2.5 "GL Errors". The errors are detected with the getError binding, which maps to the underlying glGetError call. For the cases where WebGL itself generates errors, those should probably reference 2.5 somehow, though. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzb...@ Sat Mar 31 08:26:12 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 11:26:12 -0400 Subject: [Public WebGL] Should WebGLContextAttributes be a callback interface? In-Reply-To: References: <4F770EAC.8000806@mit.edu> <4F7717C6.8060603@mit.edu> Message-ID: <4F772214.60106@mit.edu> On 3/31/12 11:10 AM, Glenn Maynard wrote: > I forgot, I talked with Cameron on IRC a while back about the dictionary > vs. callback thing: > > http://krijnhoetmer.nl/irc-logs/whatwg/20111208#l-281 Ah, thank you. That discussion is actually a good argument in some ways for having separate types in the getContext() call (where values can be left out, etc) and the getContextAttributes() return value (where values are guaranteed to be present)... > Honestly, I'm not sure I'm a fan of the "single getContext method" > approach in the first place. I'm not sure of that either, but we seem to be somewhat stuck with it... > You *can* return a dictionary type from functions, so it could, in fact, > just define a dictionary used by both getContext and > getContextAttributes. It'd lose the interface, but I can't think of any > use cases for an interface there anyway. But I guess there's otherwise > no real difference between doing that and just making the attributes > nullable. Oh, there are plenty of differences in terms of actual behavior. They might not matter, though. -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 08:27:01 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 11:27:01 -0400 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: References: <4F770CA5.5000600@mit.edu> Message-ID: <4F772245.6090407@mit.edu> On 3/31/12 11:23 AM, Glenn Maynard wrote: > For the cases where WebGL itself generates errors, those should probably > reference 2.5 somehow, though. Yes, exactly. -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Sat Mar 31 08:31:27 2012 From: bja...@ (Benoit Jacob) Date: Sat, 31 Mar 2012 08:31:27 -0700 (PDT) Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: <4F770CA5.5000600@mit.edu> Message-ID: <2069092429.1724966.1333207887105.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > > All it says is: > > Bind the given WebGLFramebuffer object to the given binding point > (target), which must be FRAMEBUFFER. > > What should happen when target is not a FRAMEBUFFER? An exception? > (If > so which one?) Silently doing nothing? As others already said, the WebGL spec falls through to the GL spec here, which specifies (without any surprise) GL_INVALID_ENUM, for which the WebGL equivalent is webgl.INVALID_ENUM. WebGL does not use exceptions as a general error-reporting mechanism, only uses exceptions in a few explicitly specified cases. So, since it doesn't mention an exception here, it clearly means no exception. If the is why aren'y JS exceptions the primary error reporting mechanism in WebGL, that's because, while half of errors are caught by the WebGL implementation before calling OpenGL, another half of errors come straight from OpenGL. To consistently generate a JS exception on every WebGL/OpenGL error after every call, we would have to call glGetError after every call, which in many cases would force a full sync with the GL (equivalent to glFinish()), removing the asynchronous nature of the GL, killing performance. Cheers, Benoit > > This needs to be defined... > > -Boris > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cvi...@ Sat Mar 31 08:41:45 2012 From: cvi...@ (Cedric Vivier) Date: Sat, 31 Mar 2012 16:41:45 +0100 Subject: [Public WebGL] bindFrameBuffer doesn't seem to define behavior when target is not a FRAMEBUFFER In-Reply-To: References: <4F770CA5.5000600@mit.edu> Message-ID: On Sat, Mar 31, 2012 at 16:23, Glenn Maynard wrote: >> It is defined in the referenced glBindFramebuffer man page : >> http://www.khronos.org/opengles/sdk/docs/man/xhtml/glBindFramebuffer.xml > > Manpages aren't specifications, they're user documentation.? They're not > appropriate as normative definitions; this needs to be defined in the OpenGL > ES spec. Yes, this is a bug (which fortunately enough is 'obvious enough' that it got documented elsewhere indeed). I opened http://www.khronos.org/bugzilla/show_bug.cgi?id=615 Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 09:02:52 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 12:02:52 -0400 Subject: [Public WebGL] Typo in IDL for framebufferTexture2D Message-ID: <4F772AAC.9040601@mit.edu> The IDL is: void framebufferTexture2D(GLenum target, GLenum attachment, GLenum textarget, WebGLTexture texture?, GLint level); The '?' should be before "texture", not after it, I assume. -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bzb...@ Sat Mar 31 09:04:52 2012 From: bzb...@ (Boris Zbarsky) Date: Sat, 31 Mar 2012 12:04:52 -0400 Subject: [Public WebGL] IDL still includes "raises" clauses, which WebIDL doesn't have anymore Message-ID: <4F772B24.8030006@mit.edu> The IDL in the spec still has "raises" clauses, but WebIDL no longer has syntax for those. Not sure what I think of that... -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl -----------------------------------------------------------