[Public WebGL] WEBGL_debug_shader_precision extension proposal

Florian Bösch [email protected]
Mon Nov 17 10:14:08 PST 2014


Yes, but in C/C++ the modifiers are part of the type, and you'd do things
like typedef unsigned int uint; typedef long long iquad; etc. , and of
course short is 2 bytes, int is 4, long long is 8. Floats of course could,
in theory, be something else than IEEE. They mostly aren't though. the 4
bytes that constitute a float have been stuck into files and sockets for
ages now. It's common practice to do it. You might run into byte order
trouble, which is easy enough to resolve. But I've never, not even once,
run into a case of trying to load a 4-byte float that one machine produced,
that another machine didn't understand.

Strangely though GLSL has introduced double and uint (and their vector
types). But you cannot typedef to get type consistency. For instance you
cannot typedef mediump float half; That'd be useful, but GLSL doesn't have
a half data type (and neither does it have a short, or byte), and anyways,
it doesn't have typedef either. Which is strange, because it also contains
packing/unpacking instructions, which explicitly refer to formats like
that. The modifiers modify  globally for a type, or of the variable being
modified, not of the type being used.

Anyway, it'd be tremendously useful for consistency of a program if a
programmer could rely on numerical implementation. And that's what I'm
bemoaning.

On Mon, Nov 17, 2014 at 6:23 PM, Tibor Ouden, den <[email protected]>
wrote:

> Paragraph 4.5.2 of the OpenGL ES standard specifies the minimum precisions
> for the qualifiers, but in principle they all could have the same precision.
> Isn't this similar to how it is done is C / C++ : short int, int, long
> int, long long int ?
> In principle they all could have the same count of bits, but hardware
> vendors are free implement them as long as the next type is at least as big
> as the preceding type ?
>
> But there is no way to query the bit size of the in C / C++ (you can
> figure it out with some tests), at least in WebGL you can query the bit
> size of the significand and exponent
> (although most of the time the reported significand bit count is one less
> compared to what it should be).
>
>
>
> 2014-11-17 17:42 GMT+01:00 Florian Bösch <[email protected]>:
>
>> I would, if at all feasible, prefer it to be a library, because then it
>> can be used to run it across every browser. Which is kinda important
>> because the architecture of the backends trough ANGLE, and in IE11 is
>> probably quite different, and may lead to different results.
>>
>> I'd rather see this happening in some fashion, no matter what fashion
>> though, than not.
>>
>> As a sidenote, I wanted to comment on precision qualifiers. It's always
>> struck me that the OpenGL specification is deficient in its definition of
>> numerical types (as in that it didn't specify which type has what precision
>> and which standard it'll have to implement). I understand that this is
>> largely historical. I also understand that the precision modifiers came to
>> be later on as the GL API was adopted for mobiles. But the combination of
>> no implementation guarantee, no precision guarantees, no numerical
>> implementation guarantee, and "types" which can change precision depending
>> on a specifier, strikes me as a particularly bad idea. I cannot recall any
>> statically typed language that would've followed the same logic (though
>> there might be one). And that's probably because most statically typed
>> languages designers thought, that would've probably been a wonky and bad
>> idea.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141117/fb32465a/attachment.html>


More information about the public_webgl mailing list