Slashdot Mirror

With OpenCL you can code (optionally GPU-accelerated) boob physics while maintaining compatibility with a wide range of hardware and software platforms:

http://www.khronos.org/opencl/

Everything I've seen so far has been "hey look what I can do". It's not the domain of cottage industry game developers, yet.

Just today I was looking at WebGL which will allow hardware accelerated 3d in the browser.

I just hope someone, eventually, figures out that the "full screen" button we have in web video can also be used in web games.

Actually, Blizzard has a long history of supporting OpenGL, and if I recall correctly, they are on the board (Kronos Group) http://www.khronos.org/about/

It's not necessarily because the games are Wine friendly, but because they use open standards to ensure Mac compatibility. Wine compatibility is more the end result of using open standards, not the root cause. DX10 is a nice to have on Blizzards newest games, but certainly not a requirement, and they went with Havok physics (from Intel), rather than Physx (owned by nVidia). This gives them the benefit of working on both ATI and nVidia cards, and again better compatibility.

WebGL works on Linux. For Chromium, you need to launch:

$ chromium-bin --disable-sandbox --enable-webgl
And view some demos: http://www.khronos.org/webgl/wiki/Demo_Repository

There's no point in having ANGLE on Linux, because Linux already has OpenGL support in most drivers.

Khronos, the main authority of OpenGL ES, tells that it "consists of well-defined subsets of desktop OpenGL"

http://www.khronos.org/opengles/

"Basically, they all said it was shit. They didn't like how they couldn't play their existing games or use their existing apps, for instance."

"One of the teachers already has a MacBook from her school, and says it works perfectly fine at the Starbucks when she gets her morning coffee. Plus she can use all of her other apps."

Chrome OS doesn't have any apps for it, while OSX is loaded with apps that *everyone* wants, needs, and uses. Gotcha. Geezus, biased much? While I agree that it sucks being confined to a browser as a lot of apps I use are not, a lot of computer users now days use very web-centric programs. IM, email, and games being some of the more commonly used apps. Our opinions don't really matter, the only question is will web app use continue to rise? I think it will. The web as a "platform" runs on all the major OSes, and thus it continues to be a big lure for developers. As web apps become able to do more, which they are especially with OpenGL coming to the web, it will continue to increase. I think Google has it right and are wise to that, but I will continue using Chromium and Firefox on my full-featured Linux desktop.

Do we get mad at Intel?

Yes. Intel hasn't produced a competitive GPU for its integrated graphics. This will become painfully apparent once web sites start to use JavaScript bindings for OpenGL ES.

IE can't do Flash without a plugin. IE can't do SVG without a plugin. What's the difference?

The IE plug-in for SWF is preinstalled on most PCs, unlike the IE plug-in for SVG. The IE plug-in for SWF is mature, unlike the IE plug-in for SVG and the nonexistent IE plug-in for the <audio> element. The authoring tools for SWF are more mature than the authoring tools for animated SVG with synchronized audio.

And I have to point out, I don't think you really mean "many browsers". I think you mean "IE".

Sixty percent of browsers are IE.

A geek, on the other hand, can install Linux and make an old system useful again.

Unless the old system has Windows-only hardware.

Would adblock suddenly stop working? How about noscript?

Again, like so many other things in your response, this is already an issue with Flash.

Flashblock blocks SWF and only SWF. Its user interface is more focused than that of, say, noscript.

If it's properly sandboxed, there's not a lot it can do.

I think grandparent's point is that a new API will likely not be "properly sandboxed" from day one. There will be holes.

The rest are vulnerabilities in the API exposed to Javascript

And WebGL is exactly that: a new API exposed to JavaScript, according to the press release.

it's also such a simple API to begin with that the vulnerabilities are, again, likely to be in drivers, not the browser.

Malware authors would love to prove you wrong.

No download time.

It takes time to download the JavaScript, maps, meshes, and textures. This isn't any faster just because your game is in JavaScript. And a lot of people are still limited to 0.05 Mbps Internet throughput; to download games, they have a CD or DVD shipped using the postal service.

Flash lets you run languages other than Javascript

JavaScript and ActionScript are pretty much the same language, as I understand it.

http://www.khronos.org/

IMO, the fundamental problem with OpenCL is the same as with OpenAL, which is that Operating System vendors don't provide a standard implementation as is done with OpenGL.

(Bus) speed isn't an issue as creating a CPU or GPU context requires a specific creation flag, so one would know what the target platform is.

http://www.khronos.org/registry/cl/

Embrace and extend. So far I'm seeing C/C++ APIs and of course Apple extends their own with ObjC APIs.

What's stopping you from using the C APIs?

The Core Spec is akin to the OpenGL spec. The custom extensions for Intel, Nvidia and AMD will be based upon their design decisions they implement in their GPUs.

However, the CPU specs for Intel and AMD are there to leverage with OpenCL.

What else do you want?

No, it's more like about par with an old-school Amiga demo. All that's missing is a starfield and a scrolltext, but I guess they didn't have any raster left :-p

Anything above 5% CPU for some moving points to music is absolutely ridiculous, as is your idea that this should take more cycles than decoding HD video.

I think we'll have to wait for webgl.

Promoting Members and Contributing Members of Khronos Group

Promoting Members and Contributing Members of Khronos Group

Promoting Members and Contributing Members of Khronos Group

What is PSGL?
PSGL is the high-level graphics library for PlayStation3
PSGL is OpenGL ES

So everyone that is using PSGL is effectively using OpenGL ES and I can't possibly imagine every developer writing their own graphics API. But like I said, please prove me wrong.

I wish Khronos would put some effort into their OpenVG stuff because that is something that is really needed badly. Cairo is not a worthwhile substitute because its performance is not very good, the API is too big (and it sucks), and Glitz is too complicated/buggy.

Currently there is no decent and complete free OpenVG implementation. The reference implementation is slow, ShivaVG is incomplete and appears dead, that Qt version requires Qt, ginkoVG doesn't support OpenGL, etc.

Looking at http://www.khronos.org/registry/cl/api/1.0/cl_gl.h ,they are using the CL prefix. This will cause a huge headache for existing code that uses the ClanLib SDK. http://clanlib.org/docs/clanlib-0.9.0/reference/modules.html

Google Earth 3D models simply use COLLADA XML format. Sketch up just exports it for you in this way.

A lot of 3D modeling software supports export to COLLADA, which can be used in KML (google earth).

For Example:
Blender
3DS Max
Maya

etc...

Remember the part where we just discussed PS & PS2 not using OpenGL?

All of which goes to say that my original point remains correct. There is at present a larger potential market for modern DirectX games than for OpenGL.

Remember the part where we just discussed PS & PS2 not using OpenGL?

I haven't heard that analogy before, and I don't believe it's correct (though if you mean creating unique trees after placement, possibly yes). It's a bit more primitive than plopping the same model down in a different location.

First off, there was a terminology issue for a while where OpenGL used primitive shader instead of geometry shader, but this seems to have been resolved (from a search, the formal extension is GL_EXT_geometry_shader4, which usually is kept in the ARB/core name), so you may find information under either primitive shader or geometry shader for OpenGL - just a heads up. The OpenGL 2.1 Specification, which is current on most cards that include DirectX 10 DOES NOT have to include geometry shaders since they are still considered extensions (EXT) and not ARB or core (which are required); however nVidia does include the extension in their 8xxx cards and I suspect ATI does in their DX10 cards as well. For more formal information, you may want to search the Khronos site for Long's Peak (which will be 2.2 or 3.0) or Mt Evans (likely 3.0 3.1) releases.

Geometry Shaders are essentially a higher level object than vertex shaders (executed after the vertex shader on a set of vertices and before fragment processing). For example, if you take a triangle strip (the highest level object considered a "primitive," and probably the reason they're called geometry shaders instead of primitive shaders now) forming a cylinder and want a flare at the bottom, you might add vertices to keep it fairly round and move the existing vertices along the bottom ring outward. That probably isn't the main use for it, but is an example (other uses: cube mapping and probably the #1 I've heard of, CPU independent particle systems not limited to sprites)

Epic? Ships content in Collada format? Uses it for its own art pipeline?

I doubt anyone would ship it, since it's not suitable for that. I can't find any details of how UE3 actually uses it, so I couldn't do more than conjecture - and most other game developers also appear to keep quite quiet about what technology they're using (at least in public). I've not heard of any other games that have been released yet and are using COLLADA - they claim that "active users" include "THQ, EA, Konami, NCsoft, DoubleFine, Rockstar", but presumably the relevant games are still under development. COLLADA itself is pretty recent, so I guess it'll be a few years before anyone can really tell whether it has survived and found a place in the industry.

Why would you need XML to do this?

You certainly don't need XML - but it does those things already, and it's already understood and supported well enough that you could write a quick Python script to read a model and manipulate the DOM and spit it back out again, which saves some effort compared to writing yet more binary importers/exporters for every tool that has to process the file. There's obviously drawbacks to using XML, but it's not as obvious whether they outweigh the benefits.

unless the tool makers start making Collada exporters, and they do not do things like this

XSI mentions it in one of the main features. (They also mention the dotXSI "standard" - it looks like every modelling program has its own proprietary standard for interoperability... COLLADA is the only one I've seen that's somewhat vendor-neutral (but still flexible enough to handle at least some kinds of real data) - I've heard that Sony saw that the vendors themselves would never agree on any neutral standard, which is why they (as people who want to improve the game development process, rather than push their own tools) had to make one themselves.)

For example, using MAX, stacked skin modifiers get baked how? Answer: however the exporter guy wanted which is unlikely to be the way you wanted it done.

I tried a simple test with ColladaMax, with a sphere and two sets of bones and two Skin modifiers. It exports a scene with a Sphere01-node, using the Sphere01-mesh-skin-skin controller with the Bone05-node skeleton. The scene also contains the hierarchy of bones. It says Sphere01-mesh-skin-skin is skinning the Sphere01-mesh-skin object, and lists the relevant bones and the weights and bind pose matrices and things. It says Sphere01-mesh-skin is skinning the Sphere01-mesh object, and gives more weights and things. And it says Sphere01-mesh is a mesh with certain vertex data. (Incidentally, one advantage of XML is that I can actually look at the file in a text editor and see that reasonably complex hierarchy - the actual geometry data is a horrible mass of numbers, but for small scenes it's quite easy to see what's going on. You could make a visualisation tool for any other non-XML format, but it's helpful if there's no need.)

That seems to be fairly close to how it's represented in Max itself. Then you can (/have to) write your own code that loads that COLLADA file (using existing libraries to handle the boring standard bits), and do whatever conversions you want for your particular purpose. It's still a problem if you need e.g. the Character Studio animation curves from Max (instead of it exporting keyframes and you perhaps choosing to fit a curve back onto them) which the exporter doesn't do (because they're too non-standard). At least the exporter is open source and it might be feasible to hack new features in yourself, but it's annoying if you have to do that.

What's the benefit of it over .X for example?

Does

In reality, all but the input (keyboard, etc...) IS there. In reality, DirectX isn't all that integrated- it's just a set of separate APIs, COM based in programming nature, that expose the respective interfaces to the hardware more directly than through the usual GDI, etc. interfaces.

Besides, it's all there and has arrived- and is what is most likely going to be used on mobile devices and
other consumer electronics devices going forward:

OpenGL/OpenGL ES
OpenSL ES
OpenVG
OpenML
OpenMAX

Check out The Khronos Group for that very thing- they're calling it OpenKODE right at the
moment. One stop. One API. Target many platforms easier.

I wonder what affect, if any, this will have upon the future development of the OpenGL standard.

Well reading TFA and not finding Microsoft on either their promoters page or their contributors page I'm cautiously optimistic.

** affect? effect? I can never keep this one straight either.

I wonder what affect, if any, this will have upon the future development of the OpenGL standard.

Well reading TFA and not finding Microsoft on either their promoters page or their contributors page I'm cautiously optimistic.

** affect? effect? I can never keep this one straight either.

The base embedded subset of OpenGL leaves out display lists, any geometry more complicated than a triangle, and all the new programmable shader stuff. It's basically what an SGI machine had twenty years ago.

This may or may not be useful for cell phones, but it will be useful for things like car navigation systems and other embedded devices.

Why people would want 3d on their phones: It looks and sounds cool, and the marketing-people told us so! *must do what those ads told me to do*

I'm sure there are some practical-uses for it as well as entertainment, I know some unnamed car-makers (or at least sub-contractors of car-makers) were looking into 3d-projections of maps on dashboards, and I'm sure it could be cool on a mobile-device (handheld, gps, mobile-phone).

Anyway, having 3d available on mobile-devices need'nt be a bad thing even if it's a power-consuming beast, it's a possibility and I'm sure as it will spread, people will find both cool and useful uses for it. Hopefully there will still be mobile-phones with less gloss available for those that want.

As for power-consumption, it's partly beeing addressed by developing spezialized hardware for 3d-graphics, where one of the design-goals are low power consumption. Having worked as a SA for Falanx Microsystems http://www.falanx.com/ which are designing an IP-core conforming to the OpenGL ES http://www.khronos.org/opengles standard/API, one of their chief design-goals are minimizing power-consumption. I'm sure NVidia, ATI and others designing 3d-hardware, are considering the constraints of their target-platforms. (If my memory serves me right, NVidia has some interests in the mobile-market, and I'm sure the other actors on in the 3d-market are looking at it as well).

-- Kjetil Joergensen

Much more interesting is the ability to render SVG images with hardware acceleration.


The real area for this to make a difference is with mobile devices. This is where an open standard like OpenVG will make things really interesting!

Correct me if I'm wrong, but I think Direct3D is also used on the XBox, since that's basically a Wintel PC w/ an Nvidia chipset.

Interestingly, the next Xbox will be non-Wintel (IBM powerpc or something like that), so the word is Direct3D is getting ported to a non-intel architecture for the first time - so they'll able to call it bi-platform, if not truly multiplatform like OpenGL.

Likewise, cellphones have their own APIs too

There's a stripped down OpenGL (OpenGL ES) for cellphones and other embedded devices, but it's not that widely used yet.

OpenGL/ES has nothing to do with OpenGL? What kind of retard are you? It says right on the OpenGL/ES page on Khronos's web site that it's a set of subset profiles of OpenGL that are accelerated in hardware.

As for the patents, do try to pay attention:
http://www.theregister.co.uk/2002/01/1 6/sgi_transf ers_3d_graphics_patents/

It was covered on Slashdot at the time also.

Does any PDA have the CPU and RAM required to run Flash at a respectable speed? It really does take multi-hundred-megahertz desktop CPUs and make them grind to a halt, even on systems with really good process schedulers. This leads me to wonder how low-power PDA CPUs will cope, unless, of course, we are talking only about future PDAs that don't exist, yet. I suppose when we have 1-watt 3GHz CPUs, this will all be moot.

One possibility is that when, say, OpenVG is done there will be an efficient and simple interface to underlying PDA/Mobile HW to support the Flash/SVG features without the need for the "1-watt 3GHz CPUs".

For those interested in developing 3D games for embedded systems (not just cellphones). You may want to look at OpenGL ES by the Khronos Group.

As a preferred programming environment for embedded systems Java will provide access to 3D graphics through JSR184 a Mobile 3D graphics API for J2ME and more excitingly JSR239 direct Java bindings for OpenGL ES!

It is called OpenGL ES (Embedded Systems) by the Khronos group. The article started of with quotes from some guy from the Khronos group.

There are several initiatives to bring 3D to the Jave platform as well. JSR184 is a Mobile Graphics API for J2ME. Even more exciting is the upcoming JSR239 which will provided Java with direct bindings to OpenGL ES!

The current OpenGL - java bindings are really geared towards the computer side of things - that is, J2SE and regular OpenGL.

There is an OpenGL specification for handheld devices though, I beleive it's called OpenGL ES, and as technology allows it might merge with the handheld-oriented family of Java that is J2ME Although I don't think that doing 3D in such a restricted and computationally limited Java version is at all feasible or efficient, so I think for 3D handheld apps native code is going to stick around for a while.

Nvidia hasn't announced a comparable chip, but they just joined the Khronos group that is promoting the OpenGL ES spec for embedded systems. Product demos are also being given by 3Dlabs, TAKUMI, Hybrid Graphics, Futuremark, Motorola, PowerVR/Imgtec, and NeoMagic at today's digital game summit.

Nvidia hasn't announced a comparable chip, but they just joined the Khronos group that is promoting the OpenGL ES spec for embedded systems. Product demos are also being given by 3Dlabs, TAKUMI, Hybrid Graphics, Futuremark, Motorola, PowerVR/Imgtec, and NeoMagic at today's digital game summit.

http://www.khronos.org/openml/

According to research at an English university, it's only marginally harder to create a clickable link.

This is good news, but I should point out the OpenGL 1.5 spec is not at this moment available yet, it's only been announced. Hopefully it will be available with some headers and implementations Real Soon Now (tm). I know the past few ATI Catalyst drivers have had experimental glslang extensions in them... Of course, it'd be nice if Microsoft would update their implementation such that OpenGL on Windows could make use of this without going through extensions, but I'm not holding my breath, nor is it really a huge issue.

The OpenML SDK is an alpha release and the final spec for it won't be out until about this time next year.

However, the Khronos Group also released the OpenGL ES spec and there's actually a couple implementations already available. OpenGL ES is for embedded systems and mobile devices, it's essentially just a subset of OpenGL. Seems like it might be pretty nifty...

This is good news, but I should point out the OpenGL 1.5 spec is not at this moment available yet, it's only been announced. Hopefully it will be available with some headers and implementations Real Soon Now (tm). I know the past few ATI Catalyst drivers have had experimental glslang extensions in them... Of course, it'd be nice if Microsoft would update their implementation such that OpenGL on Windows could make use of this without going through extensions, but I'm not holding my breath, nor is it really a huge issue.

The OpenML SDK is an alpha release and the final spec for it won't be out until about this time next year.

However, the Khronos Group also released the OpenGL ES spec and there's actually a couple implementations already available. OpenGL ES is for embedded systems and mobile devices, it's essentially just a subset of OpenGL. Seems like it might be pretty nifty...

Thats what openML (Open Media Language) is for.
Its on the same site.

I have to be honest I not read too much about openML, but we have had openGL and openAL for some time. So its not a far jump to openML.
Although I dont see any note of openAL, maybe they reinvented the wheel here

PDA level mobile FPUs are very rare indeed. In practice, devices using the ARM family processors have no hardware float support. It's thus very important for developers to understand floating point intimately, so that they won't be left at the mercy of awful compiler-emulated floating point code. Of course, in those cases most code tends to orient itself for fixed point arithmetic. Fixed point calculations are much better suited for the integer crunching power of, say, the Intel XScale.

There are also good tradeoffs developers can make between floats and fixed point, for example by using block floating point (BFP) formats, where a whole block of values shares the same common exponent.

Now that 3D is really coming to mobile devices, plenty of people will get first-hand experience of emulating floating point for the first time since the 80's. :-)

Jouni

This is why OpenGL ES is being developed. Go to www.khronos.org

Certainly, a standard OpenGL subset for embedded use would be a useful thing, though not in any way essential, since straight-up OpenGL 1.4 (say) will already fit comfortably in today's relatively fat handhelds. What is essential is a software renderer that does a particularly good job on the common render paths needed for these embedded applications. There's no technical obstacle to this, it's just a lot of hard work.

The two main standards currently under development are OpenGL ES by the Khronos group and the JSR-184 headed by Nokia. If you read through the list of participating companies, you'll notice a good bit of overlap; we can expect the two APIs to play quite nicely together.

Mobile 3D hardware will also be coming probably sooner than what most people think. Some Ericsson researchers will be giving a SIGGRAPH talk on the subject ("Graphics for the Masses: A Hardware Rasterization Architecture for Mobile Phones") even if nothing more than the title is known at this time.

While all mobile devices will have to make their own compromises on functionality, battery life, weight and cost, almost all of them are capable of running 3D graphics when the software is carefully constructed. Many modern software rendering techniques are based on dynamically generated/compiled code, and the processes are very similar to what happens inside 3D hardware. As these libraries will also be fairly small, they will not add cost or weight to the devices themselves. 3D chips will be reserved to those more keen on playing games on the road.

The technology is definitely coming, now all we need to do is invent the killer application. Ideas anyone?

Jouni

The point is not whether it works on Linux, the point is whether there is an open specification. And of those, there are zillions: OpenML, QuickTime, Java Media Framework, GNOME Media Framework, aRts. And these are just some of the most ambitious ones.

Now, after reviewing those links, you'll probably say: "but none of these works! none of them is finished!". And that's exactly my point.

I see a good "multimedia framework" to be the same thing as programming using the GNU tools.

Yes. And that's where you would be wrong. It a completely different thing. One works with text and symbolic representation. The other works with audio and video. There is a reason, you know, why all graphical programming languages to date have failed to gain widespread acceptance: it just doesn't work very well.

Instead of seeing Yet Another video player in gstreamer, you should really be seeing another Mozilla. It's big. It's complicated. It's hard work. People ask what the point of it is. It will be awhile before any good results come out of it. But when(if) it bears fruit, you may well find yourself asking how you did without it.

Uh. While Mozilla is not actually a failure, -- owing more to some incredibly fortuitous circumstances (*cough AOL money cough*) than actual competency on the part of the development team -- Mozilla did fail to satisfy *almost every single goal* that it set out to accomplish. So, yes, why not compare to Mozilla? A slow, bloated, overbearing software project, that's years late? You don't even have to take my word for it: just ask Apple. Hell, ask the Mozilla team themselves: what is Phoenix other than an attempt to salvage Mozilla?

Truly, it's great that Mozilla exists, but the only reason why it's anywhere near useful right now is because the team, after years of overengineering, finally started to worry about how the thing was actually going to be used by actual people. Since that point (about 2 years ago), Mozilla has started to make some great leaps towards usefulness.

OpenGL does not provide any other of DirectX's functionality...

Sure, but that why there's OpenAL, not to mention OpenNL (now called HawkNL) and its extensions, and OpenIL (now called DevIL). Wasn't there an open input layer too? They've gotten hard to find now that so many of them changed their names (due to pressure from SGI? See the OpenIL site!)

Anyway, there's also SDL, and for that matter OpenML. Both are far more functional than OpenGL alone.

In summary, if you want a cross-platform DirectX alternative, there are options. You just have to know about them or search them out.

another initiative to create an alternative cross-platform media api is currently underway under the name OpenML. OpenML is a merging of several media apis from SGI and others. the specifications have been released, and whitepapers, specs, and presentations are on the OpenML website.

I am not into graphics programming in any way, shape, or form, but the Khronos Group recently released the specs for OpenML 1.0. Khronos hopes to "promote the creation and deployment of rich media through the creation of open standard APIs to enable the authoring and playback of dynamic media on a wide variety of platforms & devices." It has support from ATI, nVidia, SGI, Intel, Sun, and others. Implemenations of OpenML 1.0 are expected to appear this year on a variety of systems (Solaris, Windows, Linux, IRIX, etc.).

--Greg

sgi also holds the trademark on OpenML, and is one of several companies involved in something called the Khronos Group which is pushing OpenML as a standard digital media api. This may explain some of the reasoning behind their attempt to change any other Open[A-Z]L.

dmSDK is SGI's Digital Media SDK. It was recently released for Linux. The advantage IMHO is that dmSDK is already being deployed on Irix and NT, in other words, it has been field tested and is very well documented. And because it's desktop enviroment independant (i.e. it doesn't have a G or K prefix :) its acceptance might happen more frictionless. It is not (yet?) released under GPL but under SGI's OSS license. But the most important "advantage" is has is perhaps the fact that it is included in the Khronos group's standard which makes it just as standard as OpenGL. I encourage you to go check it out...

-adnans