They do bounds checking and shader verification using ANGLE.
712 karma · joined March 19, 2009
OES_texture_float is a current WebGL extension that is implemented by several browsers. The issue is that OES_texture_float does not specify readPixels support. As far as I can tell, even with native OpenGL ES 2, there is no extension that specifies readPixels functionality for floating point textures. I believe this is a bug in the OES_texture_float specification as binding a texture format to a texture engine is entirely type-level and no types are required after the resource is bound. If there is a hardware limitation, you're doing it wrong.
So the current state of support is: some browsers implement OES_texture_float and you can load floating point textures. Some browsers, when you have enabled OES_texture_float, also allow writing floating point textures. Unfortunately, the only thing you can do with a written floating point texture is re-read it in a later vertex (if you can get vertex texture fetch support which is still lacking for WebGL on Windows due to DirectX impedance mismatch) or fragment shader.
If you want to read back the results of your float computations, you have to pack them into 4 x 1 byte pixel color channels and then unpack them on the javascript side back into floats. Of course, when converting the GPU native floating point values into color channel integers, implementations "helpfully" clamp to [0..1] and then multiply by 255 (!) so that 0 -> 0 and 1 -> 255. This plays havoc with floating point precision as 255 is not exactly representable. Complicating matters further, ES2 and its corresponding GLSL have no provision for integer or bitwise operations and so the implementor is reduced to using floating point operations to pack floating point values into 4 [0..1]-values that then get molested into 4 byte arrays which can then be read back into Javascript which can then waste browser/CPU time rebuilding floating point values from pixel byte channels with accompanying (technologically unnecessary) numeric noise.
I've not seen any WebGL implementation running on the iPad and Apple won't say anything about it. If I had to guess, I'd say that WebGL is attractive to Apple in the HTML5 sense but not in protecting their native application advantage. The Steve will probably decree that native 3d apps have superior performance by virtue of not being written in a sloppy, GC'ed language and run in a giant sandbox. I don't think native iOS apps allow float texture read-back, either.
The real question is: Is WebGL's lowest-common denominator (phones) approach to 3d a bug or a feature? On the bug side, it's absurd that I can't read float values off of my desktop GPU in 2011. On the feature side, it means that even your iPhone 3G will be able to poorly execute and render a WebGL application at an unbearably low framerate!
I don't know if you've noticed, but most WebGL users are on personal computers and not mobile devices. The only mobile implementation I've seen is FF4Mobile and it's quite inadequate for all but the simplest WebGL programs. Most PC GPUs have had floating point readback for a few years now. Additionally, the irony of the situation is that ALL of JS numbers are doubles and ALL OpenGL ES 2 GPUs use floating point internally. It is really only the standards that have not caught up and force devs to do int-float conversion across the GPU boundary. Add to this the performance constraints of 3d rendering and any sane dev will want to do as little in JS and as much in GLSL (on GPU) as possible.
I asked Kenneth Russell, the Chrome WebGL lead, about floating point readback support at GDC and I was told that I'd "just have to do the pee-pee dance".
With this single capability, many tasks "needing" WebCL become possible with WebGL. OES_texture_float (according to WG members) only allows loading float textures, not reading out of them.
I wonder if Adobe and Microsoft know to use floating point for GPU computing? Here's hoping that a little competition fixes this blatant oversight.
The software was originally developed for my WebGL OCaml game engine demo, Ooman: http://ashimagames.com/
Put another way: the budget contains a de facto representation of the current economic position as well as economic "velocity" and higher derivatives. In forming the budget, legislators encode these values. In many cases, these values over- or under-shoot reality with poor consequences.
tl;dr: Balancing the budget is a stabilization criterion and bringing the active driver into synchrony with the driven body (the economy) should improve stability.
It is customary to stack operators by indenting.
Why are lines without semi-colons at the end bad?
If you're just getting started in mechanical program transformation, I strongly recommend using something like Structure and Interpretation of Computer Programs and its meta-circular evaluator to get the basics without the grunge of parsing and generation.
The problem regarding race that the article mentions is simply one of social statistics: if 10x more convictions per 1k convictions occur for group A than group B and we assume convictions are familially independent (close enough), people in group A are 10x more likely to be suspected of a crime via familial inference than those in group B.
It's not quite racial profiling but it does imply that you have fewer rights as a genetic relative of a convict than as a non-relative. That's somewhat disturbing.
The small is type systemic. Machine proofs show that you have written your typable logic correctly.
This is still not at the level of concurrency or machine assistance to which I am referring.
You are getting closer with dataflow programming languages. Pipeline and compute farm visualization, spatial/resource quota policies and control, and process calculi equivalences proven across visual/spatial refactorings is what is needed.
Of course you can do all of this with a linear byte array. Of course you can get more dimensions with names and references.
Unfortunately, these methods are very specific and very technical and, despite their accuracy, are relatively devoid of meaning at-a-glance. In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor. This is not possible without heavy use of graphical interfaces and visual representations. This is not possible without an advanced type system and an easily constructible syntax for DSLs and DSL graphical front-ends.
Perhaps you wouldn't classify this as a "visual programming language" as most of the programming itself is not done via virtual objects and connections. However, visual system tools will become increasingly important as programming moves from implementation to specification and control.
"But data and voice have different quality of service criteria and blah blah blah!" So make up a function that accounts for this. Or add another indicator for data exclusively and keep the bars for voice.
I am not suggesting a vanilla browser at all. I am suggesting putting all of the browsing-like functionality (books, newspapers, arbitrary hypertext) in the same application. I don't care whether it is compiled-in, a plugin, or a web app but if it's not even in the browser then it's a bad user experience from my perspective. I want a unified reading experience. I want unified search shortcuts. I want unified bookmarks and hyperlinks in books that open web pages in tabs.
Forcing users to switch apps for a data format that accomplishes most of the same things that the Web accomplishes diminishes the value of the format to the user. Application balkanization is not the answer and the fighting between vendor and publisher over page styling has already played out in the browser.
If I buy a book, I want to get the book how the publisher, editor, author, and designer intended. It is wrong for Apple to intentionally change the display of the book from the design that was intended. If you want to override the styling in your books, fine, but this shouldn't be mandated.
All we're asking is for symmetry. If I send them data, they can do whatever they want with it inside the law, their ToS and privacy policy. If they send me data (even the data I previously sent them), I can do whatever I want with it inside the law.
My problem with the BP situation is that the risks were fairly well understand as oil is a mature industry. I expect BP to be fully liable for their negligence just as I would expect Apple to be fully liable if they released a radioactive phone. Do you think BP is being held fully liable?
Looks to me that we are in our infancy as techocrats.