It's in the agenda now. https://github.com/tc39/agendas/blob/master/2017/05.md
On Wed, May 17, 2017 at 6:13 PM, Leo Balter <[email protected]> wrote: > Sorry for my previous quick - through the phone - answer. > > I wanted to provoke and find a reason why to add this as a proposal. Of > course I missed all the context from 2 years ago on this email thread, my > bad. > > I'll support this and bring it to the next meeting. I'll keep you posted > and updated with the results. > > On Wed, May 17, 2017 at 5:49 PM, Kenneth Russell <[email protected]> wrote: > >> @moriken awesome work -- looks like a solid implementation. >> >> I'm torn about whether this should be subsumed into ECMAScript. Doing so >> implies that all ES engines are going to have to incorporate a significant >> amount of code to convert to and from half-floats. Also, the tests will >> have to be a lot more thorough then they might otherwise be. If compiling >> pure ES code can achieve most of the efficiency, I'd advocate for leaving >> this as a library. In C/C++, developers use libraries for this purpose. >> >> -Ken >> >> >> >> On Wed, May 17, 2017 at 5:28 AM, Florian Bösch <[email protected]> wrote: >> >>> Also keep in mind that Float16 is the only viable format for some >>> operations. Mobiles in particular may not support any or a combination of: >>> >>> - Basic (nearest, clamped, non mipmapped) Float32 textures >>> - Linearly interpolating Float32 textures >>> - Rendering to Float32 textures >>> - Reading back Float32 textures >>> - Repeating (ST) Float32 textures >>> - Mipmapping Float32 textures >>> - Not clamping (numerically between 0 and 1) Float32 textures >>> >>> If your usecase requires any of these capabilities and you need to >>> either upload or readback the data, then there is no primitive you can use >>> to perform computations with the data in JS. The present day way this is >>> handled is you upload/readback UInt16 and then have conversion routines >>> that convert these to floating point values you can work with on the CPU or >>> convert back for use by the GPU. >>> >>> >>> On Wed, May 17, 2017 at 2:15 PM, T.J. Crowder < >>> [email protected]> wrote: >>> >>>> I'd missed that this was the continuation of a thread. Florian Bösch >>>> [started it](https://esdiscuss.org/topic/float16array#content-0) with >>>> interop in mind, in fact. So that makes sense. >>>> >>>> -- T.J. Crowder >>>> >>>> >>>> >>>> On Wed, May 17, 2017 at 1:12 PM, T.J. Crowder < >>>> [email protected]> wrote: >>>> >>>>> On Wed, May 17, 2017 at 1:05 PM, Leo Balter <[email protected] >>>>> > wrote: >>>>> >>>>>> The current spec is based on IEEE 754 and matches the floating point >>>>>> specs. What would Float16 be based on? >>>>>> >>>>> >>>>> There's a binary16 format specified by IEEE-754 2008. >>>>> >>>>> But I agree with the "why" comment. 16-bit (aka "half precision") >>>>> binary floating point is not very useful here in 2017 except for interop >>>>> (森建 >>>>> - is interop your motivation?)... >>>>> >>>>> I'd be much more interested to see support for the "new" (nine years >>>>> ago) decimal formats. >>>>> >>>>> -- T.J. Crowder >>>>> >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
