Slashdot Mirror
A Lawyer's View on the OpenGL Patent Mess
PDAJames writes "This article has an interesting take on Microsoft's claims on OpenGL technology. An IP lawyer says that Microsoft could make things difficult for OpenGL if they feel like it, basically. "
You might want to read this too.
It even mentions MS could put MESA in trouble just by writind a C&D to them.
Nice world isn't it?
.oo00OO
<rantmode>
I don't know if this has changed recently, BUT when I looked into Direct3D a while back I ran across a show stopper for what I was working on. If you use ANY double precision fp math in your code the FPU needs to be 'reset' every time it went into D3D code. This sent performance down the crapper. This basically makes it useless for scientific style applications.
</rantmode>
Thoughts on tech, Software Engineering, and stuff
AMD duplicated the input vs output of Intel while implimenting a system to achieve this other than how the patent describes I believe. But if the patent is broad enough programming a vertex in 3d rendering, not very easy to get around. Sure there are way of rendering the exact same scene without using vertex programming, but its slow.
... and it doesn't take MS to cause problems. The general consensus amongst developers who use the more advanced OGL features (pixel and fragment shaders/programs, etc.) is that things are currently a mess.
;) In any case, there's been a lot of stalling over this issue due to that sort of crap as well.
OpenGL is comprised of a central body of standard functionality which _must_ be implemented in order to use the name OpenGL. Additionally there's an extension mechanim which allows IHVs (like NVidia, ATI, etc.) to implement their own funcitonality which isn't currently a part of the core standard. That's how we have Fragment/Pixel shaders/programs today, as IHV extensions from NVidia and ATI. This system tends to work pretty well, but you start to get into problems with the interface. Essentially what happens is that all the IHVs decide that they need to do something along the lines of vertex programs (a way to manipulated verticies after they have been passed to the GPU, more or less), which is true. It's a cool feature any everyone likes it. Since they're being implemented as IHV extensions they're not standardized at all, so if you want to use a vertex program from NVidia you have to use their vertex program assembly language, but if you want to accomplish the same thing on an ATI card you have to use _their_ vertex program assembly (which, by the by, tends to follow a completely different model than NVidia), ad naseum.
Naturally all of this is a pain in the ass for developers. You now not only have to have different rendering paths for the various combinations of available extensions, but you have to write the same routines in drastically different languages to support a given set of functions.
Now getting all of this into a standard extension to the core API is supposed to solve some of these problems, but the IHVs aren't totally in favour of that as they then lose some product differentiation/control/etc. Mind you, this bit is speculation and observation, I don't actually know what the IHVs are thinking, but history shows that they sometimes have trouble working together
And it's exactly these kinds of disagreements that are holding up OpenGL 2.0, which is supposed to directly address many of these problems. NVidia, for instance, has CG, their high level shading language. CG can be compiled down to their proprietry shader code (for use with NV_* extensions on NVidia cards) and, _in theory_ down to the proprietary code for other cards. However, for that to actually work ATI, etc. need to create so called "profiles" which allow the CG compiler to do it's thing. Clearly NVidia wants some degree of control/name recognition/whatever here... in the case where CG takes off you'd need to get your dev tools from NVidea regardless of which cards you're targeting. Now this idea is in direction competition with the OpenGL 2.0 proposal, which gives much of the same functionality but via a standard set of interfaces that replace current IHV proprietary code rather than a compiler ship on the top. Natrually this makes NVidia a little less enthusiastic about OpenGL 2.0 in it's current (proposed) form.
And on, and on, and on.
Right about now DX 9 (really the D3D componant...) is starting to look pretty damn good to a lot of us. It's got standard interfaces for pixel shading, etc. that just work with the various cards, it's a much improved API from it's early days, and given all the extension thrash it's much easier to write clean, readable code under D3D than OpenGL anymore.
Of course you're screwed if you need to port, but that's the plan, right?
The point of all this is simply that while MS is certainly doing their part to muck about with OpenGL (like not updating the damn dev tools since OpenGL 1.1!!!) they're not alone in that hobby. IHV squabbles have always been an issue in that area, and MS' best tactic to date has been to take advantage of the slowness of the ARB (often arising from IHV squabbling) and run right on by with their own API. So their adding to the infighting isn't really that much of a change to the situation, as I see it.
Behold the Power of Cheese!
You haven't read the article have you?
Oh no! I've fallen for a troll. Nooo!
When a hardware vendor licenses OpenGL from SGI (this isn't free), he undertakes to run the official OpenGL conformance test suite - which is some humungous software package that (theoretically) tests *everything* in your driver.
Two problems with that: Firstly, no test suite can *ever* test everything - so every implementation will still have bugs. Secondly, SGI don't seem to actively monitor this compliance testing anymore. It's been said that they don't want to discourage hardware vendors from providing OpenGL drivers by being too heavy-handed about it.
It's a thin line to tread. Do you allow bad implementations to pollute the standard and thus make OpenGL unpopular with application programmers? Or do you police the standard with a rod of iron and make it too costly for hardware vendors to write allowable drivers? Either one of those policies could kill OpenGL.
www.sjbaker.org