|
On 12-11-19 09:03 PM, Mark Callow
wrote:
On 2012/11/20 0:35, Benoit Jacob
wrote:
For many WebGL functions taking GLfloat, it is actually very important
to _not_ throw, because these floats are often the result of nontrivial
arithmetic, and nontrivial floating-point arithmetic does produce
non-finite values, and good floating-point API design is to handle such
non-finite values gracefully.
So it's actually very important to make GLfloat unrestricted.
+1
For GLclampf, I don't know. Since GLfloat must be unrestricted, and IIUC
current browsers implement unrestricted anyways, it may be simpler to
keep it unrestricted. That may also be a good idea as GLclampf's too may
be the result of nontrivial floating point operations.
If GLfloat is unrestricted GLclampf should also be.
But note that the ES 2.0 spec says using NaN or infinity will
produce unspecified results; it also says that these values
should not result in "GL interruption or termination."
It's OK, in fact inevitable, to say that rendering results are
undefined. Keep in mind that whether or not a non-finite value is
produced at any stage in a shader, is undefined in the first place,
as the shader compiler is allowed (AFAIK) to perform optimizations
that can change the results of floating point arithmetic, such as
a*(b*c) -> (a*b)*c.
Also note that the question of whether non-finite issues occur
cannot be reduced to the question of whether non-finite values are
passed to any GL functions. For example, if I set a uniform float to
1e20, that's a finite value, but if I square it in my shader, it
will become infinite even with highp. So, sad as it may seem, a GL
spec can only say very little about non-finite values. It can say in
a non-normative way that non-finite values should only be produced
at any stage if that is a reasonable result given the inputs and the
shaders; and it should say that non-finite values only result in
undefined rendering for the specific triangles that involve them.
Since it's probable that current GL implementations behave like that
anyway, it should be safe to bet on that, add a note to that effect
in the WebGL spec, and maybe have that conversation with other GL
working groups if needed (I don't know that that is needed).
Cheers,
Benoit
The WebGL spec. does not specify what the results should be
either so I would hardly say that non-finite values are handled
"gracefully." Graceful handling would probably require that the
values be propagated as specified in IEEE 754. But I think
throwing an exception would be akin to "GL interruption" so I
come down on the side of unrestricted.
Regards
-Mark
--
注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、
再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いい
たし ます.
NOTE: This electronic mail message may contain confidential
and privileged information from HI Corporation. If you are not
the intended recipient, any disclosure, photocopying,
distribution or use of the contents of the received
information is prohibited. If you have received this e-mail in
error, please notify the sender immediately and permanently
delete this message and all related copies.
|