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

Re: [Public WebGL] OES_texture_float_linear and OES_texture_half_float_linear extension proposals

On Thu, Feb 21, 2013 at 8:56 AM, Mark Callow <callow.mark@artspark.co.jp> wrote:
so I question how supportable OES_texture_float_linear will be outside of desktop implementations
As of Jan 21. 2013 According to  http://www.glbenchmark.com/
  • OES_texture_half_float: supported by 782/1180 devices
  • OES_texture_float: supported by 733/1180 devices
  • OES_texture_half_float_linear: supported by 417/1180 devices
  • OES_texture_float_linear: supported by 0/1180 devices
On Thu, Feb 21, 2013 at 8:56 AM, Mark Callow <callow.mark@artspark.co.jp> wrote: 
32F textures are not filterable even in OpenGL ES 3.0 so I question how supportable OES_texture_float_linear will be outside of desktop implementations. I do not think we should make a WebGL extension.

Given the discussion that preceded the decision that 32F textures should not be filterable in ES 3.0 - it greatly increases the size of certain paths in the hardware - I am surprised to see we have an OES extension and I suspect it is not well supported.

This argument is faulty for the following reason.
  1. OES_texture_float is not going away.
  2. OES_texture_half_float is not going away.
  3. OES_texture_half_float_linear is needed to figure out if a half float texture supports linear filtering. You cannot assume linear filtering on half-float will work, roughly half of devices don't support it. Hitherto you have no way of detecting that.
  4. OES_texture_float_linear is needed to figure it out, just like OES_texture_half_float_linear, it is consistent to be able to detect linear filtering support, for the supported floating point formats.
The support for mobiles does not matter to the argument at all, since once you have determined what capabilities you have you will be able to provide a seamless fallback to another format or an alternating renderpath. Witholding the extensions already ratified by khronos for OpenGL ES acomplishes nothing but promote rendering that will not work on mobiles because people are just gonna assume linear filtering works because they have no way to figure out it.

On Thu, Feb 21, 2013 at 8:32 AM, Kenneth Russell <kbr@google.com> wrote:
 Any comments or objections to moving these to draft status?

I am strongly in favor of moving this extension to draft ASAP.