VizWorld.com

Another stop you may want to make at SIGGRAPH is by the Khronos BOF where they’ll be discussing their newly released OpenGL4.2 specification.  Some of the new features include:

• enabling shaders with atomic counters and load/store/atomic read-modify-write operations to a single level of a texture.  These capabilities can be combined, for example, to maintain a counter at each pixel in a buffer object for single-rendering-pass order-independent transparency;
• capturing GPU-tessellated geometry and drawing multiple instances of the result of a transform feedback to enable complex objects to be efficiently repositioned and replicated;
• modifying an arbitrary subset of a compressed texture, without having to re-download the whole texture to the GPU for significant performance improvements;
• packing multiple 8 and 16 bit values into a single 32-bit value for efficient shader processing with significantly reduced  memory storage and bandwidth, especially useful when transferring data between shader stages.

The press release also has comments from both NVidia and AMD discussing their upcoming OpenGL4.2 compatible drivers.  NVidia’s drivers are available today, but it seems AMD’s aren’t available quite yet.  They mentioned having 4.2 Beta drivers available “with the publication of the OpenGL4.2 specification”, but they dont’ seem to be available yet.

via Khronos Enriches Cross-Platform 3D Graphics with Release of OpenGL 4.2 Specification – Khronos Group Press Release.

Science khronos, opengl

Surely you’ve heard of WebGL by now, the Khronos-developed bindings to OpenGL for Javascript.  What you may not have heard of is a new API from Khronos called WebCL, the same thing but for OpenCL.  Mac Users can check out a simple prototype of the WebCL bindings for WebKit (safari) via a library at Google Code.

WebCL is a new activity in Khronos that is defining JavaScript bindings to OpenCL. The “WebCL for WebKit” project is an early implementation of WebCL for the open source WebKit browser engine. The design and implementation of WebCL for WebKit are similar to that of WebGL. A typical WebCL application will start by making a “WebCLComputeContext” which is then used to invoke OpenCL APIs. An example (not complete, but to show the flavor of WebCL) is:

webcl – WebCL for WebKit – Google Project Hosting.

Science khronos, opencl, webcl

Last week Microsoft made waves with claims that WebGL was an insecure and dangerous standard that could bring us a whole new level of web-based malware, exposing millions of systems to new threats.  I personally found their claims overblown, but Jon Peddie (as usual) has a great balanced writeup on the real story behind Microsoft’s claims based primarily on a report from Context Security which found two possible problems.  One problem is just a classic Denial of Service, that exposing the video card to the browser makes it easy for someone to simply hang the card.  The more interesting attack, IMO, is this cross-domain glitch:

Context demonstrated that a shader program could implement a loop that could be used to approximately reconstruct an image from another domain—a serious potential security hole. Khronos had previously debated on its open mailing list whether this was a real-world possibility and once the exploit was demonstrated by Context, Khronos worked swiftly with the WHATWG (Web Hypertext Application Technology Working Group) to mandate the CORS spec (Cross Origin Resource Sharing) in both the HTML and WebGL specs to make sure servers have to explicitly allow access to media assets across domains.

So yes, as with any new technology there are a few glitches in the early version that will get ironed out with time and more-eyes.

via GraphicSpeak » WebGL: kill it before it grows?.

Hardware, Science jpr, khronos, microsoft, webgl

Update 8/5: By request from Khronos, I’ve added all the little ™ and ® ‘s.

Last week I posted a rather, well let’s just say “sensational”, article about the coincidental announcement by AMD/ATI of their new OpenGL|ES2.0 Driver for Desktops and Khronos’s announcement of the OpenGL® 4.1 spec which offers full backwards compatability with the OpenGL ES 2.0™ standard.  Most people wouldn’t care about OpenGL ES 2.0™ on the Desktop, as it’s the OpenGL Spec for Embedded Systems like set-top boxes and mobile phones, however the OpenGL ES 2.0™ spec is the foundation of the up-and-coming WebGL spec that promises plugin-free 3D graphics on the internet for all to enjoy.

Currently in the WebGL space, you have about 4 options:

• Download a Plugin.  This is basically what Google started out with, you download a plugin that offers a translation layer between the actual hardware support and the WebGL spec.
• Download an OpenGL ES 2.0™ Driver. This is what AMD/ATI Announced just prior to SIGGRAPH.
• Download an OpenGL® 4.1 Driver. This is what NVidia announced during SIGGRAPH.
• Download a new browser. WebGL is currently supported in some fashion or another in the latest dev releases of Chrome, Safari, and FireFox.

However, each of these has problems.  The whole point of WebGL is to be “plugin-less”, so the first one is out.  This leaves the other three, however, they have hidden issues as well.

Before I continue, many people ask “Why do I need a driver?”, and it’s a valid question.  Right now, without any OpenGL ES 2.0™ driver, you can go download development versions of Safari, Chrome, and FireFox and get WebGL.  It all works just fine, but you’ll notice it works a bit differently in each one.  This is what the driver is for: consistency. With working drivers in place, the visuals will be identical across browsers and hardware, because the rendering is all handled in the Driver, not the Browser.  Currently, browsers have a built-in translation layer that turns the JS-based OpenGL ES 2.0™ commands and turns them into regular OpenGL commands, and some do a better job than others.

Initially, as in the article, I was a bit harsh on ATI for releasing a dedicated OpenGL ES 2.0™ driver and favored NVidia’s announcement of an upcoming OpenGL® 4.1 driver that would encompass the same results.  This way, the user only has 1 driver to manage that in future systems will be installed by default, so the user literally has to do nothing.  Unfortunately, NVidia’s OpenGL4.1 support is limited to only the latest revisions of hardware:

You will need any one of the following Fermi based GPU to get access to the OpenGL® 4.1 and GLSL 4.10 functionality:

• Quadro Plex 7000, Quadro 6000, Quadro 5000, Quadro 5000M, Quadro 4000
• GeForce GTX 480, GeForce GTX 470, GeForce GTX 465, GeForce GTX 460

This means all those people with little GeForceM cards in their laptops are out of luck, as well as anyone with the GTX285 or earlier.  No doubt these cards have the horsepower to handle WebGL, but they’re currently unable to get the drivers necessary.

ATI’s solution is a bit less elegant, but by offering a dedicated driver they open it to all of their hardware, not just the latest and greatest.  Unfortunately, it does return us a bit to the previous world of loading plugins, except you’re loading a system-level driver instead.  However, this opens the world to all those old ATI Rage chipsets in laptops and FirePro’s in the wild, covering the full gamut of users.

In the end, I’m sure NVidia will offer a driver for WebGL to older hardware, but there’s no news on when that will be.   If NVidia lags too far behind, we could find ourselves in a “VRML Situation”, where individual browsers begin to support various extensions in attempts to best utilize the hardware, leading to inconsistencies and incompatibilities we already see with HTML & CSS across browsers.  Hopefully, with a good standards organization in place like Khronos, which VRML didn’t have, we’ll find consistent drivers coming to all platforms soon.

Hardware, Science amd, ati, feature, khronos, nvidia, opengl, webgl

If you couldn’t make it to the various Khronos BOF’s at SIGGRAPH on OpenGL, OpenCL, or COLLADA, then you can at least view the presentations online. There’s several to look at:

• OpenGL BOF:
  • Ecosystem Update
  • GLSL Overview
  • Intro and Overview
  • Jon Peddie Intro
  • SPEC Update
  • gDEBugger Update
• OpenCL BOF:
  • AMD GREMEDY
  • Intel
  • Intro and Overview
  • NVIDIA
• COLLADA BOF:
  • Intro
  • Extensions Process
  • Alan Chaney
  • Rightware
  • Web Viewer
  • Publishing 3D Characters
  • Kanzi

Khronos Developer Presentations Library.

Science collada, khronos, opencl, opengl

Update 8/3/2010: Read a followup to this post here.

I just got a press release from Khronos about the first OpenGL ES2.0 driver for Desktop systems coming to market from AMD.  Upon further inspection, this looks a bit fishy.

At SIGGRAPH 2010, AMD (NYSE: AMD) today announced availability of the first software driver for desktop computing environments to support the WebGL industry standard, which is designed to bring plugin-free 3D graphics to the Internet. The AMD OpenGL^® ES 2.0 driver is intended to help developers easily create exciting 3D content that can be rendered more quickly for consumers using open-source web browsers, thereby helping create an application-like browser experience.

Ok.  So where do I get it?  Read further down the press release and see:

The OpenGL ES 2.0 driver from AMD will be generally available with the upcoming ATI Catalyst™ 10.7 beta for OpenGL ES 2.0, expected to be available later today.

So it’s not “official”, it’s “Beta”.  But, how did AMD beat NVidia to the punch on this one?  In fact, why is a special OpenGL ES2.0 driver needed anyway?  OpenGL ES is a subset of regular OpenGL targeted at embedded systems, and in fact that’s exactly what NVidia did with it.  NVidia’s OpenGL ES2.0 support is right where it’s designed to be, in the development kit for their embedded system Tegra.

So why do we care about it?  WebGL, the coming common standard for 3D on the Web, is based on OpenGL ES2.0 (presumably to make it an option for smartphones and other portable devices that lack full OpenGL compatibility).  So most companies haven’t focused on putting OpenGL ES on the desktop, because that’s not where it belongs.

Not that it matters too much anymore, thanks to another press release that I got mere minutes after the accolades came rolling in for AMD.  Khronos, the group behind the OpenGL and OpenGL ES standards has just announced the standard for OpenGL 4.1, with one fascinating addition:  Complete compatibility with the OpenGL ES 2.0 APIs.  This means that being OpenGL4.1 compliant means you’re already OpenGL ES2.0 compliant.  So what has NVidia been doing the last few months?

“The release of OpenGL 4.1 just five months after OpenGL 4.0 shows that collaborative innovation to build market opportunities for high-performance GPU acceleration is not slowing down.  The ARB is also working hard to ensure backwards compatibility with each release so developers can absorb new functionality at their own pace,” said Barthold Lichtenbelt, OpenGL ARB working group chair and senior manager Core OpenGL at NVIDIA.  “I am also pleased to announce that NVIDIA will release OpenGL 4.1 production drivers on our developer site for all Fermi-based graphics accelerators, including the GeForce GTX 400 series, during SIGGRAPH.  OpenGL 4.1 is not just a specification – it’s here and now.”

Myth Busted.

See both press releases after the break.

Read more…

Science amd, khronos, opengl, opengles

Big news on the GPU computing front, as Khronos has just released the specification for OpenCL1.1, the industry standard in GPGPU API’s.

“The clear commercial opportunity to unleash the power of heterogeneous parallel processing that drove multiple OpenCL 1.0 implementations has also fueled the ongoing industry cooperation to create OpenCL 1.1,” said Neil Trevett, chair of the OpenCL working group, president of the Khronos Group and vice president at NVIDIA.  “The OpenCL 1.1 specification is being released 18 months after OpenCL 1.0 to enable programmers to take even more effective advantage of parallel computing resources while protecting their existing investment in OpenCL code.”

The new spec includes new data structures like 3-component vectors and new operations like multi-device control.  I also hear that Nvidia already has a Conformance Candidate of their OpenCL1.1 driver to GPU Computing Registered Developers.

Read the full release after the break.

Read more…

Science gpgpu, khronos, opencl

Recently we reported that the Khronos Group released the specifications for OpenGL 4.0 at GDC. Now, Iain Thomson from V3.co.uk interviews Neil Trevett from the Khronos Group about OpenGL 4.0. Neil talks a little bit about the history of OpenGL and where it is headed to in the future. You can click the link below to see the video, which is about 5 minutes 30 seconds long.

via GDC 2010: Khronos Group discusses OpenGL 4 – V3.co.uk.

Science glsl, khronos, opengl

OpenGL programmers at GDC should stop by room 123 of the Moscone Center to see Khronos presenting various aspects of OpenGL, OpenCL, and WebGL, and most importantly get an inside look at OpenGL3.3 and OpenGL4.0.  What’s new in OpenGL4.0 ?

OpenGL 4.0 further improves the close interoperability with OpenCL™ for accelerating computationally intensive visual applications.  OpenGL 4.0 continues support for both the Core and Compatibility profiles first introduced with OpenGL 3.2, enabling developers to use a streamlined API or retain backwards compatibility for existing OpenGL code, depending on their market needs.

You can just feel the influence of GPGPU in the air, can’t you?  The new OpenGL4.0 spec support 64bit double-precision shader operations (not needed for graphics, but mandatory for scientific computing), allowing OpenGL to both generate and render data, and new shader stages for offloaded geometry tessellation.

It’s a huge advance, although it will probably be a year or so before we see it in any product.  Read the full release after the break, and get the OpenGL4.0 spec at OpenGL.org.

Read more…

Science gdc, khronos, opengl

The first public WebGL specification draft has just been released by Khronos, and they’re actively seeking community involvement to see what they got right and what they got wrong.  So far, it’s heavily influenced by the OpenGL ES 2.0 standard and exposes basic OpenGL API’s to JavaScript, working with the current HTML5 Canvas element.

Model loading and other high-level functionality will be implemented in third-party libraries on top of WebGL. Modern high-performance JavaScript engines are finally fast enough to be able to handle that kind of computationally intensive work. The major WebGL implementations support hardware-accelerated rendering, which means that the user’s graphics hardware is responsible for the heavy lifting. Mozilla also has a software-based backend for computers that don’t have sufficient graphics hardware.

You can view the current draft here, where it’s curiously housed in a SVN repository, so it might change.  So far I see support for ArrayBuffer’s, Textures and VBO’s, stencil/alpha/depth buffers, all the usual functions and data types of OpenGL.   The supported rendering types are a bit limited, I only see points, lines, and triangles (Regular, Strips, and Fans), no Quads or Polygons.  That’s probably not a big deal, not many people use them anyway and several systems just devolve them into triangles anyway.

See anything particularly interesting?

via WebGL draft published, Khronos seeks community involvement.

Science khronos, webgl