Slashdot Mirror

It also sounds like it might use modern GPU shaders.

As an alpha asshole, you are a great ambassador for Apple. And like a typical Apple camp follower you are a barefaced liar. Apple freeloaded on the Vulkan working group to build its own incompatible API, as any fool can see. Yes it was a plan, however idiotic. Doesn't change the slimy intent. Doesn't matter how a lying fucktard like you tries to spin it. Apple stays on the Vulkan working group to freeload on more of their great work. Just the kind of thing we have come to expect from Apple. Sweet that Autodesk rubbed your face in it, looking forward to more of that.

Metal was RELEASED nearly 2 YEARS before the Vulkan final SPEC was even announced. NOW who copied from whom?

And considering the Metal API is SIGNIFICANTLY different from the much harder to use Vulkan API, plus is more than twice as efficient, I don't see how you can support a claim of "Freeloading" on Kronos' weak-ass, second-rate solution.

BTW, Apple is a "Promoter"-level member of the Kronos group.So I assume they know what is the good, and the bad, in Vulkan:

https://www.khronos.org/member...

And if Apple is "Freeloading" from Kronos, then WTF are AMD, ARM, Google, Samsung, Qualcomm, Intel, NVidia, Sony and Valve (among SCORES of others) doing?

Now, do I think Apple should Open Source Metal 2? Yes I do. But it's their ball, and their game; just like DirectX is MS' ball and their game.

And with the lightweight MoltenVK translation-layer, there simply isn't an argument to whine about Metal 2 being proprietary; because a Vulkan-based Application simply doesn't have to suffer any significant rework to support Metal 2 through MoltenVK Dota 2, which even YOU noted has "Very Good" performance...

Your Hater argument is simply pathetic. Like you.

Oh, you mean like Windows has done for DECADES with DirectX?

No, nothing at all like that, actually. Windows has always given you a choice of graphics APIs, for as long as multiple APIs have existed on the platform. If you chose DirectX and vendor lock-in, that was entirely your choice; OpenGL has always been an option for as long as it's existed and, because MS is obsessed with backward compatibility[1], it's all but guaranteed to remain a choice for as long as Windows exists.

OpenGL hasn't been a choice on Windows for anything with performance needs since NT 4.0. XP came with DirectX 8 IIRC, which was the end of OpenGL gaming on Windows. I'm not sure that you even can run OpenGL on Windows without installing extra drivers these days. A quick search and it appears Windows 10 had some issues with OpenGL. Then again, Windows 10 had all sorts of issues, OpenGL support would be far far down the list.

Lazy Developers, that don't know how to code using a standard Model-View-Controller method, are the ones that will continue to have "porting" problems, you mean...

Really? That's the argument you're going to make with regard to a very performance-oriented segment of the industry?

I wouldn't use "standard" MVC for games either. Too much lag just typing that in.

[1] Yes, you'll find examples where they've broken things in the past. It's literally impossible for them to not have broken something while making sweeping API changes, but they've historically put in the effort to break as little as possible while still progressing. Now, I praise MS about as often as I praise Apple, they're both fuck-ups after all, but MS has done a damn good job with backward compatibility.

I'd respectfully disagree on backwards compatibility - they promoted an entire set of programming practices using sets of frameworks that are all unsupported or gone, at this point. I also have a collection of software for Win95 and XP that won't run on W7 even. And then there's also the question of an entire set of APIs they purposefully broke, under the guise of adding security. The effect was exactly the opposite - less security. I agree MS is the poster boy for fuck ups in software architecture. Backwards compatibility? Not so much.

[2] Which really isn't impending when we're talking about Apple, as they're stuck on v2.1, which was released 12 years ago. OpenGL 3.0 has been with us for a decade, now.

You do realize that OSX 10.7 supports 3.1, and 10.9 supports 4.1? Just asking.

But besides OpenGL support, Apple still has the best overall GUI of any *nix I've seen. and it's much more consistent in overall experience as compared to Windows, which last time I looked still had NT 3.1/3.5 and 4.0 based fixed size non-scaleable dialogs for some of its system controls. You can tell the differences between OS versions by how horrifically ugly they look on a 4K screen. Speaking of 4K screens, at least as of the pre-Creators release of Win10, the damn thing still wouldn't scale various artificats properly for hi-res monitors.

Apple is a Promoter (highest level) member of the Khronos Group. You're really saying they should be worried about an industry consortium of which they are one of the highest ranking members controlling an open specification and doing so so much that they should create their own closed, proprietary version instead?

an outdated one

If you think OpenGL is outdated then you are living on a different planet. The OpenGL 4.6 and OpenGL Shading Language 4.60 Specifications were released on July 31, 2017 There is not even a remote chance that OpenGL will be displaced by Vulkan in the big dollar engineering sector, which is more than enough to ensure that OpenGL lives on forever, never mind the thousands of applications using those libraries. Vulkan for performance games, OpenGL for pretty much everything else. That is the status quo and it won't be changing fast, if ever.

Apple is courageously moving in an idiot direction. Just keep doing it please.

...easier to use than OpenGL...

I only want to clarify one thing: Vulkan is not easier ot use than OpenGL.

In fact Vulkan is much much more difficult and requires much much more setup. Vulkan is capable of being faster than OpenGL because Vulkan enables multi-threading the rendering commands rather than computing all the rendering commands in a single thread as OpenGL does it.

The reason Vulkan is more difficult to use compared to OpenGL is precisely because setting up a multi-threaded renderer is much more tricky to get right and requires way more in the way of boilerplate and you-just-have-to-already-know-what-you're-doing scaffolding in order to get places. Vulkan is much lower-level than OpenGL.

This post helps explain.

Thanks! I looked at their website and noticed that the "supported engines" list included CryEngines, UX3D, Unity, Unreal, and Source. Does this mean these engines already use Vulkan instead of OpenGL, or that they can be configured to do so by the developer?

There's been many attempts at standard 3D scene format, but glTF format from Khronos seems to be getting traction and is supported by the industry.

Yet if you read the OpenCL Quick Reference Card there isn't anything there but the C version. It seems kinda like retconning to me.
Also, read the original OpenCL version 1.0 specification:
https://www.khronos.org/regist...

OpenCL consists of an API for coordinating parallel computation across
heterogeneous processors; and a cross-platform programming language with a well
specified computation environment.
The OpenCL standard: .. Utilizes a subset of ISO C99 with extensions for parallelism

So yep, it's definitively been retconned.

Here you go: https://www.khronos.org/openxr

From the page again:

"The following are the currently available licenses:

Open source license - for use of the S.I. This is a Free Software License B closely modeled on BSD, X, and Mozilla licenses.

Trademark License - for new licensees who want to use the OpenGL trademark and logo and claim conformance."

It says it in black and white: OPEN SOURCE LICENSE.

Open source license for what? Where is the source they contributed that is covered by this license?

Please read what I wrote above: "OpenGL is one of many open source projects Apple has supported.

So show me the "open source" contribution they made.

As a company, Apple abandoned it when they decided to go in another direction and with their own platform." Nowhere did I say Apple's implementation was open source only that they supported OpenGL.

So what exactly are you saying they contributed that is open source? Where is their contribution?

Even though Apple hasn't implemented anything beyond 4.1 the 4.5 latest release notes show they still contribute to OpenGL.

If you actually bothered to read what they contributed it was Apple-specific extensions to make legacy features work on their platforms.

Do you understand the difference that I pointed out? It seems you do not or you are ignoring it because you dont like it.

I am following the English definition of available:

Because you are ignorant of the technical side of it. As I said it would be intentionally disingenuous to suggest that all Linux, Windows, Android and iOS programs are available on Mac, sure they are through VMs and emulators but that defeats the point of it and nobody who isnt being willfully disingenuous (or mentally defective) is going to argue otherwise. Since you have no idea about 3D graphics APIs you don't even understand why your suggestion is so ridiculous, go get educated so you stop looking so foolish.

Can you use Vulkan? Yes. Is it officially supported? No. When you says something isn't available it means there is no way to get it.

So when Apple says Vulkan isn't available on their platforms you are saying they are lying? In fact they aren't lying it is just that you quite clearly cant understand the fundamental issue here. I have tried pointing it out to you but you refuse to learn.

I don't think you understand Apple's plan here: They want to base WebGPU on ideas in Metal to start. That does not mean it will be Metal APIs. It does not mean it will be Vulkan APIs.

I do, it is to start with an API that maps to their own native proprietary API, this means more performance and less overhead for them instead of going with an industry standard.

No I am not wrong, you simply misunderstand.

From the page again:
"The following are the currently available licenses:
Open source license - for use of the S.I. This is a Free Software License B closely modeled on BSD, X, and Mozilla licenses.
Trademark License - for new licensees who want to use the OpenGL trademark and logo and claim conformance."
It says it in black and white: OPEN SOURCE LICENSE.

To help you along just try and show me Apple's open source OpenGL implementation. Oh you cant do that? Im not surprised, because it is not open source.

Please read what I wrote above: "OpenGL is one of many open source projects Apple has supported. As a company, Apple abandoned it when they decided to go in another direction and with their own platform." Nowhere did I say Apple's implementation was open source only that they supported OpenGL. Even though Apple hasn't implemented anything beyond 4.1 the 4.5 latest release notes show they still contribute to OpenGL.

Do you understand the difference that I pointed out? It seems you do not or you are ignoring it because you dont like it.

I am following the English definition of available:

able to be used or obtained; at someone's disposal

Can you use Vulkan? Yes. Is it officially supported? No. When you says something isn't available it means there is no way to get it. An out of stock item is not available meaning even if you put down money, the retailer can't sell it to you. At best you can get a rain check for later.

Even Apple's proposal for WebGPU points out that Vulkan is not available on their platforms because to implement it on top of another 3d graphics API completely defeats the purpose of a low-level API. Do you understand that? Or are you still confused?

I don't think you understand Apple's plan here: They want to base WebGPU on ideas in Metal to start. That does not mean it will be Metal APIs. It does not mean it will be Vulkan APIs.

> For one, Vulkan and its competitors aren't designed for use with untrusted code,

[[Citation]]

Do you have an _actual example_ that shows this or are you just repeating dogma that everyone else does?

> neither Vulkan nor its competitors are actually cross-platform in practice today.

Um, Hello, McFly. We already have WebGL. Hell, even Microsoft supports it on Edge! Of all the graphics API available WebGL is the most cross-platform. The only exceptions that I'm aware of are consoles such as PS3/PS4 and Xbox360/Xbone.

WebGL 2.x was here in 2013. We don't need Yet-Another-Graphics-API. It is time to get rid of proprietary vendor lock-in regardless of how much "freedom" it promises.
 

Valve is not stupid. They have received a lot of flack for StreamOS and pushing linux as the future platform, particularly since, today, it only offers negatives (specifically, library support is small compared to winblows). But, clearly, Valve has been anticipating this from Microsoft for a long time. Any decent company knows that it isn't terribly wise to be so dependent on a competitor. Microsoft is a competitor of Valve's and the platforms look increasingly similar now that internet distribution is the norm. Vulkan is starting to look very promising. Soon, the only reason I'll need to run windows is for work and to fire up the occasional retro game like GTA San Andreas. Hear, hear, Valve!

Why is the above downmodded? People may come to expect that OpenGL is the right choice for cross-platform 3D gaming but the fact is that only applies if by "cross platform" you mean Windows PCs and Linux PCs. Consoles do not use OpenGL. Mobile systems that support OpenGL actually use the mobile variant called OpenGL ES, Apple platforms have been lagging in OpenGL/OpenGL ES support for a while and have now moved to focussing on Metal instead.

What purpose does it serve to keep propagating the idea that OpenGL is the cross platform choice when that is clearly not the case?

I find it odd that so many people on a tech news site like this would not know this, I find it even more bizarre that some would actively try to suppress the information.

check out the API cheatsheet

the rest of the API documentation is here: https://www.khronos.org/regist...

check out the API cheatsheet

the rest of the API documentation is here: https://www.khronos.org/regist...

Well no, you misunderstand. In fact quite clearly most of your assertions are wrong and you have obviously misinterpretted what I said, you also seem to disagree with people like Graham Sellers, Tim Foley and Cass Everitt, yet are not able to explain why.

The fact that you find memory barriers, a basic concept of asynchronous programming - that of course already exists in GLSL - to be too complex demonstrates that you aren't very experienced despite your attempts at credential-dropping. However since you aren't able to realize this on your own and you won't take my word for it I invite you to enact change if indeed your criticisms are valid:

Please post your objective criticism(s) here on the Vulkan forums. You genuinely believe your criticisms to be comprehensive and valid so please post them in the appropriate place.

True. But the content of the file can be a scene, and can use URIs to reference any external resource (which the importing program must work out how to deal with - the same with any 'file format').

I would say that the ability to use URIs to point to any arbitrary resources is a fairly powerful capability, IMHO
https://www.khronos.org/collad...

COLLADA use URIs to reference external ressources, including other COLLDA files. Pretty neat, eh? https://www.khronos.org/collad...

It is up to the program interpreting the COLLADA to determine how to use the URI. At least, that's how I use it.

I state this again for readers, a COLLADA file can be used to contain a scene, not just a single 'object'. The reason I say this is I like XML (because it has some advantages and is pretty ubiquitous in computing) and I like well-defined standards (as big projects require standards as assets are created over time). I know many other Slashdotters do to.

Thanks for taking the time to post.

How do you know Metal isn't the basis for Vulkan?

Because it is based on Mantle, which is not Metal.

Put up, or shut up

Sure, it's not hard to use Google but it's obviously beyond you. So Here, here and probably plenty of other places.

instead of basing all your "arguments" on the fact that you have an irrational hatred for Apple.

Sorry but it's not irrational and it's not "hatred", I know there are Apple fanboys and there are Apple users, I'm the latter because don't have an emotional attachment to the company.

Anybody else think that Apple should ditch Metal in favour of Vulkan? If they want the latest games ported to Mac then they should use an open API that is used on other platforms.

Oh, the old "Shouldn't Apple use the new standard that will be finished next year instead of their own solution, which has been used by developers for a year now (and was the reason why the new standard has been pushed from being two years away)."

Anyway, https://www.khronos.org/vulkan... lists Apple under Working Group Participants. FWIW

It's a nice suprise, though the downside may be the need for recent hardware. Article leaves out the minimum hardware feature level

The official Vulkan page says that it will work on any platform that supports at least OpenGL ES 3.1. Of course another question is whether a Vulkan stack will actually be created for older hardware too.

According to Khronos, those issues have been addressed and the possibility of DOS attacks is the only serious remaining issue.

https://www.khronos.org/webgl/security/

Yes, this group of greasy students is clearly late on their open source coursework. ;)

This is not magic or novel. It is just extension of stuff already used in the GPU world and available in OpenCL.

http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/exp.html

see the function for exp? half_exp? native_exp? That is what you can optimize - floating point operations mostly.

There are several languages that are written on top of OpenCL - that is the whole idea of this API. But if your read the article, it seems this guy was the actual inventor of the wheel.

Same response happened when some guy made Rootbeer and let some marketeer write an alike article. It was suggested that you could just run existing Java-code on the GPU, but that was not true at all - you had to rewrite the code to the rootbeer-API. This Harlan-project is comparable: just beta-software that has not run into the real limits of GPU-computing - but still making big promises that in contrary to their peers they actually will fix the problem.
I'm not saying it can be in the future, but just that this article is a marketing-piece with several promises on future advancements.

Check out Aparapi and VexCL to name just two. There are loads and loads of these solutions - many of these wrappers slowly advance to higher level languages, and have been in the field a lot longer.

Arguably, the fact that this specific hack had to take place is a bad sign, just not one specific to Wayland, or even (particularly) to the rPi.

There are, attempts at least, at standardizing the interfaces for the sorts of features that this Wayland modification used to get better performance on the pi; but they certainly aren't anywhere near where OpenGL is in terms of adoption, and so the compositing and windowing modification had to be made specifically for the 'DispManX' API used exclusively on these Broadcom Videocore parts.

At least this isn't a situation where applications have to have much platform-specific knowledge; but it's always nice to keep platform-specifics abstracted in some standard way as low in the pile as you can.

Huh indeed. I think you might be confusing NEON the ARM SIMD engine with OpenMAX the media processing API.

here

Actually, if you're going to give credit to someone for OGL, Apple is about the LAST company you should be thanking.

These are the companies you should be thanking. Oh look at that there's Apple. Apple sits on the board of directors that determines the direction OpenGL takes. So Apple is no where near the last company you should thank.

It is a standard. At least in name. The Khronos group manages it here.

It's a spec...but it seems to be turning into at least a defacto standard.

The "the security and stability implications of exposing the most volatile piece of computing hardware through the browser" is exactly why every browser exposes WebGL through a wrapper/translator library that acts as a validator to prevent bad behaviour. WebGL-based exploits have been shown in the past.

The issue is that video driver crashes are one of the most common causes of system crashes, so driver stability is a major issue and not going to be fixed by a translation layer. The other is security, especially given you are writing to GPU memory, having that sort of access to hardware through the browser is potentially a huge security issue with the ability to exploit driver bugs, cross domain image hacks using fragment shaders, denial of service attacks, sampler overflows, etc... and these don't have easy solutions.

It is a standard. At least in name. The Khronos group manages it here. The "the security and stability implications of exposing the most volatile piece of computing hardware through the browser" is exactly why every browser exposes WebGL through a wrapper/translator library that acts as a validator to prevent bad behaviour. WebGL-based exploits have been shown in the past.

OpenGL 4 manual pages (297 functions):
http://www.opengl.org/sdk/docs/man4/
OpenGL ES 2 manual pages (109 functions):
http://www.khronos.org/opengles/sdk/docs/man/

Apart from the number of functions:
* Many OpenGL ES functions support fewer options than the equivalent OpenGL functions (e.g. the ES version of glTexImage2D supports 5 formats, the real version supports 81 formats)
* There are another 124 OpenGL 1.x functions which are deprecated but still available in the compatibility profile; those aren't listed in the OpenGL 4 manual pages.
* The ES version of the shading language is similarly "cut down" down compared to that in desktop OpenGL.
* ES has much lower minimum implementation limits (OpenGL 3 and later require support for 1024x1024 textures; OpenGL ES only requires 64x64).

Internet or Google? No never heard of http://bit.ly/viyioS
Now, instead of being a smart-ass or dumb-ass why don't you add something _constructive_ to the thread like answering the question.

99.99% of people claiming WebGL is a security risk are blowing smoke out of their ass.
i.e.
http://www.khronos.org/news/permalink/webgl-security
"There are no known WebGL exploits and Khronos will continue to place close attention to technical and ecosystem opportunities to ensure WebGL is a secure technology that can be used with confidence. "

Can WebGL read user's cookies? NO.
Can WebGL read user's private data? NO.

There was only *one* OVER-rated exploit I have ever seen: cross-origin images and that was fixed (internet years) ago.
http://www.khronos.org/webgl/security/

Until I see an actual *working* WebGL exploit, to say "WebGL was is insecure by design" to spouting ignorance. Do you even understand what vertex and fragment shaders are limited to?

Now, I agree that *WEB* Browsers (in general) are *insecure*, but one sub-system of them remains to be *proven* that *it* is insecure. I have not seen any other exploits since May 2011, almost 1.5 years ago.

So again, (0-day-exploit) [citation]

Internet or Google? No never heard of http://bit.ly/viyioS
Now, instead of being a smart-ass or dumb-ass why don't you add something _constructive_ to the thread like answering the question.

99.99% of people claiming WebGL is a security risk are blowing smoke out of their ass.
i.e.
http://www.khronos.org/news/permalink/webgl-security
"There are no known WebGL exploits and Khronos will continue to place close attention to technical and ecosystem opportunities to ensure WebGL is a secure technology that can be used with confidence. "

Can WebGL read user's cookies? NO.
Can WebGL read user's private data? NO.

There was only *one* OVER-rated exploit I have ever seen: cross-origin images and that was fixed (internet years) ago.
http://www.khronos.org/webgl/security/

Until I see an actual *working* WebGL exploit, to say "WebGL was is insecure by design" to spouting ignorance. Do you even understand what vertex and fragment shaders are limited to?

Now, I agree that *WEB* Browsers (in general) are *insecure*, but one sub-system of them remains to be *proven* that *it* is insecure. I have not seen any other exploits since May 2011, almost 1.5 years ago.

So again, (0-day-exploit) [citation]

No. My day job is working with OpenGL ES 1.x, 2.x, and WebGL. You will want this link. Don't let the title through you -- WebGL *is* OpenGL ES 2.0
http://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences

It's been mentioned before . Many times the hardware may have features that are not yet fully developed or licensed. I remember Nvidia saying this about Linux driver and shader languages - that GLSL wasn't licensed for Linux or something. Then you have patent trolls who will jump at every keyword as evidence that you are violating the patents they bought off craigslist or ebay. Your mention of "geometry tree" might mean list of vertices, To them, it's their super-spiffy collision detection algorithm, so you end with paying lawyers large sums of money to fight it out on your behalf. You might also get the odd nutter or academic department who will go off and patent a future feature enhancement documented in the comments.

Like the early days of the PC, somebody figured out a way of reprogramming the real-time clock to drive 8 Kilohertz interrupts so low-quality sound could be played on the internal speaker. They actually patented it, even though it completely scrambled all file update and creation times.

Given the rate of change that is going on (GLES 3.0 is out today, it would be very confusing for developers if ARM had one version of the driver that supported the current standard, and the user community has their own with custom extensions.

This has been my experience as well. You are 100% correct and succinct. While the text-string pragma-hack
      "use strict"
helps, it doesn't solve the root problem. Who knew that we'd come back 100% full circle back to Basic (lack of type safety) after all these years. :-)

If you think debugging JavaScript is fun, try debugging WebGL! gl.GetError is so broken it is not even funny. One the same hardware as a native C/C++ app you can get descriptive error messages. On WebGL you are lucky to get _anything_. Fortunately you only have to debug your WebGL base shader code once.

Yes, I'm aware of:
http://www.khronos.org/webgl/wiki/Debugging

Now if only we could get a proper mouse-lock for web applets...

Bingo! None of the banks or online transactions will use it because it isn't cross platform and AMD doesn't have a big enough share of the CPU market so the only ones that will use it is those who want DRM on top of their DRM.

There is a cross-platform way to target heterogeneous ISAs, such as a Cortex A5 integrated along side a multi-core x86 CPU and Radeon GPU, from a single language and host framework. In fact, AMD has been pushing it pretty hard along with other vendors, including Intel, ARM, and Apple. Perhaps you've heard of it? It's called OpenCL.

http://www.khronos.org/news/press/2008/06

The Compute Working Group will follow proven Khronos processes and invite member contributions as a basis for standardization efforts. Apple has proposed the Open Computing Language (OpenCL) specification to enable any application to tap into the vast gigaflops of GPU and CPU resources through an approachable C-based language.

Of course, "proposed" can mean different things, but it looks like Apple made the first draft.

Basically, in OpenCL, float operation is faster than double. But there are different functions that you can use, potentially speeding up your routine further..

https://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/exp.html

With regular exp(), you get full accuracy. With half_exp(), you get minimum 10-bits. With native_exp(), it depends what your hardware feels like.

So here, you have a choice. In a way, yes, it is used in graphics hardware, though you generally get FULL precision for basic ops like +, -, *.

I think this is a niche marker. Maybe they fudge + on 32-bit int such that adding only the most significant 8 bits set and ignoring the others and stuff like that..

Stefan, you know about http://www.khronos.org/registry/typedarray/specs/latest/ right?

Not that EGL, nothing to see here, move along.

The LLVM project and OpenCL look interesting. I've never understood why a virtual machine is, in any way, better than an intermediate language that can be compiled to native code for a particular platform. An interpreted language may make sense for dynamically created code. Even so, why not just compile it first? You can run interpreted code in a sandbox, but any IM compiler could add the same features to native code.

Depends on your fglrx version apparently.
And for intel, your mesa version.
I was getting crashes in the webgl test suite with my intel card until I updated the machine to Natty Narwhale.
Mesa in that version is apparently fixed.

My fglrx works fine in Maverick with the test suite. Has never crashed.
Use the environment variable MOZ_GLX_IGNORE_BLACKLIST=1

You can add it to /etc/profiles.d or whatever your distro equivalent is if your results are good.

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
Basically if you can run through this without crashes (including crashing on closing the tab or exiting the browser) you're probably fine.

I ran 1-2 tests from the demos.mozilla.org site and they did not seem to work as intended (especially the Remixing Reality one). My guess was that maybe WebGL was not working properly on my system and I ran the webgl-conformance-tests suite found at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html. Results were 5389 of 5468 tests passed, 1 timed out. Same results with latest Minefield.

Now I'm a bit at loss: the above tests (the failure of which may or may not be related to the demo pages) may fail because of several reasons:

1. The WebGL implementation by FF4
2. The Javascript and Java implementation on my system
3. The OpenGL implementation (latest AMD Catalyst on HD4670)
4. The specific tests, or FF4, or WebGL, or OpenGL may be not fully amd64 compatible (running Win7 Pro x64)
5. Other OS and non-OS related issues.
6. A combination of the above

I'm not a 3D guru, but my guess is that a lot of people eager to experience the latest and greatest HTML5 bling won't know where to start troubleshooting. I wish Mozilla realises the problem and posts in that demo page:

a. specific prerequisites list (hardware, OS, programs, drivers, accessories etc) for properly running the demos
b. testing procedures to check if the above prerequisites are met
c. troubleshooting instructions (which may be based on a. & b. above).

I hope some of the above are implemented as soon as (or better, before) FF4 final is released. Otherwise I expect vicious browser/platform wars that won't do HTML5 development any good.

Safari is a supported browser on Snow Leopard *after* you open Terminal and run a command line to set a flag in the (normally not seen) configuration file. Totally obvious - NOT.

WebGL is not part of the standard Safari on Snow Leopard. It's still in beta and you have to grab the nightly builds, THEN set the default com.apple.Safari WebKitWebGLEnabled to YES.

You're on the cutting edge man, don't expect it to be automatic just yet. If you take a look at the WebGL spec that I linked you'll see that it says "Working Draft", not a released spec. WebGL is not yet ready for the masses who don't know how to set a hidden default.

The bodybrowser page links you to http://khronos.org/webgl/wiki/Getting_a_WebGL_Implementation which gives you WebGL information and, for Safari, links you to http://nightly.webkit.org/

It's fully possible to do everything that you can do with native technology with web technologies". Which sounds pretty dubious,

Pretty easy, actually — just add some way to execute machine code via javascript or something. Granted, there are some issues with this strategy.

Chrome's V8 JS engine already compiles JavaScript into machine code to gain performance... Granted, there are some security issues with this strategy (note: Firefox, IE & Safari also run JS as machine code).

Provide some bindings for JS to take advantage of OpenGL (like WebGL), and sockets (like WebSockets), and yeah, you can do just about anything with JS compiled into machine code as you can with C compiled into machine code.

IMO, machine code should run in a hardware supported VM environment to help prevent exploits... Davlik is a software VM, perhaps this should have just been an Android tablet... I just can't wait to fully "jail break" a Chrome OS tablet and install Android on it (I already develop for Android... Google, STOP FRAGMENTING THE MARKET).