If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

WARNING: THIS IS A CHEAP TRICK!!!!
Nvidia is trying to exclude their competitors by introducing their own "standards". They must not be allowed to do this. The only way it can be prevented is by NOT ACCEPTING.

Anticipate it to be about as open as "VDPAU", which is an abomination, only useful with nvidia hardware.

WARNING: THIS IS A CHEAP TRICK!!!!
Nvidia is trying to exclude their competitors by introducing their own "standards". They must not be allowed to do this. The only way it can be prevented is by NOT ACCEPTING.

Anticipate it to be about as open as "VDPAU", which is an abomination, only useful with nvidia hardware.

Without trying to fire another conspiracy theory, this is obviously a strong strategic decision.
We all know how open-source friendly NVidia usually is.

Anticipate it to be about as open as "VDPAU", which is an abomination, only useful with nvidia hardware.

It's only useful with nvidia hardware, because only they have a full implementation. VDPAU itself is fully open, there's a state tracker using it, for example. Though for now it only decodes mpeg2. But it's there.
Intel could provide hardware decoding via VDPAU, there's nothing technical preventing them from doing it, it's just that they're already using VAAPI.

Saying VDPAU is not open, just because one implementation is closed, is silly. That would mean xvmc is not open either, seeing as how nvidia has a closed implementation in their driver. Which is, of course, equally silly.

I don't mind being less closed source. It's LLVM, not GCC, where this doesn't affect the rest of the compiler if it's implemented.

Also people can start using it, but OpenCL is more like it.

Sound a bit like 3Dfx to me; open sourcing a GPU lib in the light of a more general open source one.

But OpenCL isn't the end-to-end-all either, since the code is still pretty much hardware bound. For example if you want to squeeze parallel performance, you have to implement a very GPU architecture specific dataset. So OpenCL isn't as generic as OpenGL (yet).