Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

StoneLion writes "Since its release, the OpenGL code that is responsible for 3-D acceleration on GNU/Linux has been running on licenses that were accepted by neither the Free Software Foundation (FSF) nor the Open Source Initiative. Today, however, the FSF has announced that the licenses in question have been rewritten, the problems resolved, and the code freed. Peter Brown, executive director of the FSF, says, 'This represents a huge gift to the free software community.'"

Pedantry coming: old nVidia cards and documents used Quads as a primitive, not triangle, so polygons can be anything, even in video cards.

As for the whoosh, there is nothing in the reply from nawcom/Cillian, where the joke about a screen taking only 1 polygon, that says that it is in fact, a triangle. And he says, as a joke, that his screen takes ONE polygon - maybe he meant a triangle-shaped screen? So, whoosh-ever, I'm out.

I can get those laptop drivers fixed, and then I can finally sleep/hibernate properly!

I've never heard of ACPI depending on an API for generating polygons, but hey whateva.

In short ACPI will take care to shut down and turn back on the power consumption of the PCIe bus. But on wake up, the *graphic drivers* will take care that everything, including the content of the graphical memory, etc. return to the exact same state, as if the 3D application running where never interrupted.

Giving an opensource OpenGL 3.x leaves more time for the developers for other parts of the drivers : to develop a nice DRI2/TTM/GEM underneath fixing low level problems like sleep/wake-up among other.

Free Software Foundation and Khronos Group Both Herald New License of Industry Standard Graphics Software

SUNNYVALE, Calif. (Sept. 19, 2008) â" As software developers the world over prepare to mark the 25th anniversary of the GNU System, Silicon Graphics, Inc. (NASDAQ: SGIC) today announced it is releasing a new version of the SGI Free Software License B. The license, which now mirrors the free X11 license used by X.Org, further opens previously released SGIÂ® graphics software that has set the industry standard for visualization software and has proven essential to GNU/LinuxÂ® and a host of applications.

Today's announcement affects software created by SGI that forms the building blocks of many elements of today's gaming, visual computing, and immersive experiential technologies, including a wide range of proven visualization solutions provided by SGI.

Previous SGI contributions to the free and open source community are now available under the new license. These contributions include the SGIÂ® OpenGLÂ® Sample Implementation, the GLXâ API and other GLX extensions. GLX provides the glue connecting OpenGL and the X Window Systemâ and is required by any OpenGL implementation using X. GLX is vital to a range of free and commercial software, including all major Linux distributions.

SGI first released the software under a licensing model in 1999. But now SGI is pleased to release an updated version of the license that meets the free and open source software community's widely accepted definition of "free."

"SGI has been one of the most ardent commercial supporters of free and open source software, so it was important to us that we continue to support the free software development community by releasing our earlier OpenGL-related contributions under this new license," said Steve Neuner, director of Linux, SGI. "This license ensures that all existing user communities will benefit, and their work can proceed unimpeded. Both Mesa and the X.org Project can continue to utilize this code in free software distributions of GNU/Linux. Now more than ever, software previously released by SGI under earlier GLX and SGI Free Software License B is free."

Not all SGI workstations were built like tanks. It started with the Indys, we had a lab of them and after about two years the power supplies started failing and after four only a third still worked when we removed them. In another lab a fan in the O2 power supplies would fail, but that was an inexpensive fix, except for the fact the case was so odd and it was hard to get to that fan.

Interfaces are one of the most important things in modern software creation. Interfaces are often established by implementations. This change by SGI makes sure OpenGL will stay used and even wider adopted. As far as I can see, it is the only graphics library standard that has the potential for long-term usage.

"Someone came to me on IRC and asked if people should start sending angry faxes to SGI, telling them to please clean up their licenses. And I was like, 'No, that's not the right message right now.' We were trying to avoid that kind of reaction, because among the people in the GNewSense community, there was a visceral reaction initially, and it took some time for people to realize that we needed to give them a chance. And it really paid off. SGI was very willing to work with us throughout the entire process.""

Yea but only until that wheel can be replaced. Honestly I really doubt that any of the venom from the masses had anything to do with Mozilla renegotiating. The suggestion that Ubuntu would create or use an unlabeled "fork" of FireFox probably did a lot more than any of the screaming.I don't have any problem with a click through EULA. If nothing else in the case of free software it tells people that they do have the right to use and even give it to other people.

Personally I think it will unload a lot of terms on average users they don't understand or care about (who reads a EULA anyway) but the main concern is the message it sends; usually an EULA is a big, half-unenforceable document intended to scare you into not doing anything.

Since any unenforceable provision is simply discarded without affecting the rest of the document, the company can sue you into oblivion any time it wants.

I don't think it's unreasonable of the Mozilla foundation to want this, but I'm some

But why would Ubuntu use an unbranded version of Firefox if there was no 'screaming' as you put it? If it wasn't for the screaming, Ubuntu wouldn't have particularly pushed it, and there would now be a EULA.

Well, with the recent Firefox issue the FLOSS community was on both sides of the table and they're both fairly dependent on each other, it's a bit different than when you're trying to ask for a unilateral favor since I don't see SGI getting much in return, nor the FSF/OSI having much power if they refused. At least the distros could have banded together, told Mozilla that from now on Firefox on Linux == Iceweasel and built their own trademark. Debian doing it is just a freak thing, every distro doing it mea

It's true that it would have reduced Mozilla's value with respect to Linux, no amount of distro forking would be likely to have an appreciable affect on FF in Windows, which has got to be a much bigger value for Mozilla.

I don't think Linux matters much to Mozilla to be honest at least when it comes to dollars and cents. Windows users account for most of their money to be honest. I am just glad they are working it out and not stopping development of the Linux version.And NO not Iceweasel! I am not one to complain about names but that one is just a step too far. Why not just Windroach, or Earthcrab?

Strictly speaking, the games themselves would still be proprietary. But I've never met a free software advocate who had very strong principles against closed source games.

But this is very good news for free games and compositing managers. Hopefully it will also encourage more development and patches on OpenGL, as well; which helps everyone and not just the people building a free system.

Sadly, OGL was never the standard in the gaming world. Games went from mode13 to directx to direct3d pretty much universally. OGL was only used by a small number of players (though ID, obviously was a significant one).

To qualify your point, from the birth of home 3D acceleration until about 1999, OpenGL was the de facto standard for 3D games that supported hardware acceleration, with few notable exceptions. This was less impressive than it sounds, as 3D acceleration had yet to catch on in the mass market. By the time the hardware was common enough, Direct3D 7 and 8.1 were taking over as the standards.

SGI offered a sample software implementation of an OpenGL device driver to hardware vendors. This source code would provide a software specification of the way that any hardware should behave. It could be used as a fallback if a hardware vendor didn't choose to implement a particular feature of OpenGL functionality directly in hardware. It would be the responsibility of the hardware vendor to choose what to implement in hardware and software. Early consumer boards just did the rasterization, and used the Intel MMX2/AMD 3DNow! instructions to do the TLC (transformation/lighting/clipping).

A professional board or gaming card would do everything in hardware. Because of the way OpenGL is implemented, there are a multitude of ways of sending down geometry - any combination of vertices plus optional outward normals/texture coordinates/colors for triangles, quads, triangle strips, triangle fans, line or points. And these might be integers, 16-bit/32-bit/64-bit floating point. Each particular combination might or might not be optimized for the hardware. There was a big fuss in the past, because vendors chose only to optimize the particular combinations for the Quake game. Home developers were confused why their implementations would run slower than the real Quake.

For every possible option at a particular layer (vertex transformation, vertex lighting, vertex clipping, triangle rasterization), there would be a function pointer choosing which function call to make - either to the software implementation or writing to hardware registers.

Mesa-GL is a open-source implementation of the OpenGL specification, written by the open-source community and not SGI. OpenGL was originally a rewrite of SGI proprietary SGI-GL API which worked on all workstations from Indigo's to Extreme's. SGI was charging vendors a license fee for access to their software implementation, which included a verification test suite for hardware. Because of this, they were reluctant to make the software open source.

But with the evolution of 3D hardware, the free availability of an open-source version of OpenGL and the possibility that programmers might even get to be able to use the GPU to write directly to the framebuffer once again, it is strategic for SGI to make this software open source.

Before DirectX and OpenGL, game programmers only used either Mode 13 with 320x200x256 color palette (or other VESA 256 color modes) to write directly to the hardware. Programmers could just use whatever algorithm they could think of - use the 256 color-palette as a Z-buffer for rendering spheres, depth-shading effects, color cycling, sprite animation. Have 16 sub-palettes each a shade darker than the others and you could do shadow effects. Create a pixelmap C++ class that could be memory-mapped to the framebuffer, add some block copy, point drawing line drawing, textured triangle/quad filling routines and you have your own mini 3D API. Since the framebuffer itself was a pixelmap, you could use the framebuffer itself as a texture map (this technique was actually patented in hardware).

It's not OpenGL, so much as GLX. The OpenGL bindings for X11. SGI contributed the reference implementations of these to the X Consortium and this code was merged into XFree86 and then moved to x.org. The code was released under a very permissive license. Unfortunately, it contained some very unclear legalese that, in retrospect, was almost impossible to comply with for anyone.

Remember, that 'open' in the FOSS sense is one of many meanings of the term in software. When OpenGL was created, the "Open" part referred to the standard and standards process being open. This meant that anyone could volunteer to join the working groups, pay their dues, and contribute to the design. It also meant that anyone could read the standard. Here, Open has nothing to do with the actual code. It had everything to do with it being an industry st

Mesa3D was open because it is not OpenGL - it is an OpenGL API compatible library, and therefore not subject to any licensing fees charged by SGI (OpenGL brand usage and licensing is usually paid for by hardware vendors). WINE is similar - it's a Windows and DirectX compatible library for Linux (i.e. it is not Windows or a Windows emulator).

It looks like SGI is OK with releasing the API and associated royalties, but in a way that makes sense because they are really no longer involved with it (and I'm not even sure if they've collected royalties lately - in the 1990s I recall it was around $20000/vendor).

The response to the latest opengl release has been, to put it mildly, underwhelming. A number of opengl developers in the blogs I have read have declared intentions of moving over to directx. This is the way for opengl developers to get a bigger share of the open source developer mindshare and development effort to make up for the egg they laid earlier this year.

The response to the latest opengl release has been, to put it mildly, underwhelming. A number of opengl developers in the blogs I have read have declared intentions of moving over to directx. This is the way for opengl developers to get a bigger share of the open source developer mindshare and development effort to make up for the egg they laid earlier this year.

Would that be mindshare among the people developing open source 3D games? (Both of them)?

Or the people developing open source desktop apps that depend on 3D? (who are either already fairly committed to OpenGL anyway or weren't even remotely interested in open source, regardless of 3D API)

This is the source for the reference implementation of openGL. It would be of interest if your planning on writing a 3D 'rendering' engine (not 3d game engine) from scratch, or are interested in how the opengl stack works.

FYI, mesaGL's source has always been readily available and is based off SGI's implementation.

I am sorry, but someone has to ask. If you had told me that this happened five six years ago, I would be ecstatic, as this would have proven to be a worthy deterrent to Microsoft's DirectX, which was lagging behind OpenGL adoption.

But with DirectX with what 90% of the market(?), I fear its too little, too late. SGI, though one of the icons of the past, has had to suffer from people at the top in late 90s who had really not much vision as to how the PC world was going to pan out over the next few years and was really caught unaware when OpenGL went the way of the doodoo.

But hey, SGI was still the only place then who had Aeron chairs (this from a friend of mine who was gracious enough to invite me to their awesome lunch cafe).

OpenGL has NOT gone the way of the Dodo, and as far as I know, is still kingpin of the 3D visualization world outside the gaming community (CAD/CAM/Modelling).

OpenGL was never very big in the gaming world either. Quake/HL was a standout in this regard, but most 3D game engines have been very custom, or based on DirectX - DirectX was sort of mandatory once game authors lost direct access to hardware.

OpenGL was never very big in the gaming world either. Quake/HL was a standout in this regard, but most 3D game engines have been very custom, or based on DirectX - DirectX was sort of mandatory once game authors lost direct access to hardware.

While I agree with your first statement (OpenGL is still big outside gaming), I disagree with this part. The Quake line of engines were very widely used in games in the mid-to-late 90s, and because of the impact they had on the gaming world most game developers developed for OpenGL or Glide (or both). Of course, since Glide only worked on 3dfx, and OpenGL never worked really well on 3dfx (not at all for most of the time they were putting out chips), there wasn't a significant overlap in the markets for the

SGI, though one of the icons of the past, has had to suffer from people at the top in late 90s who had really not much vision as to how the PC world was going to pan out over the next few years and was really caught unaware when OpenGL went the way of the doodoo.

I can assure you that the doodoo is very much stil around, and in fact fills the pants of every non-toilet trained infant and toddler around the world.

I wait for the day were the posts change from "Why don't my drivers work" to "Dude, wtf is the problem with this linux pos. This sux!!!'

The funny thing is I always had more success being a bit insulting when I needed Linux help on a forum. If I asked "I can't get foo to work. I've read the docs and tried bar and baz, but it didn't help." I'd get crickets. If I said "Linux sucks because it can't do foo." Then a ton of fanboys would pile on, call me every name in the book, and then explain in exacting detail how foo can be done. They might've thought I'm a retard, but at least my question got answered.:-)

I think this has the largest number of comments from people who have absolutely no clue what the story is about than any other Slashdot story.

The relevant code was already released to the X Consortium and has been distributed with XFree86 and X.org for well over a decade. The license was badly worded and when someone noticed that it was basically impossible to comply with (and therefore not Free Software) and so SGI fixed this to clarify the original intent of the license.

Well, DirectX is obviously going to be the big thing by volume. However, I think the way graphics interfaces work will change quite a bit and the most exciting part of that is Gallium3D. It's a low-level interface to expose programming functionality in a generic way, while you have frontends like DirectX, OpenGL and such working as state trackers and APIs for applications. Since modern graphics cards are pretty much all moving to a unified shader architecture, it's not going to be like the old days when you

When OpenGL 3.0 came out 5 weeks ago [slashdot.org], there was much talk about new features that had been shown and old stuff had been dumped, and then all of that was tossed because of needed backwards compatibility for the CAD software. Is this maybe a chance for the gaming crowd to get the new stuff, developed by a collaboration between AMD, Intel, nVidia (if they're interested) and any game makers and other open source companies that want to participate in a more open API.

SGI is a company much weaker than it was when it first released OpenGL and drove it. Microsoft has no use for OpenGL, and so now, we have OpenGL being offered up as free software? This can be spun as having an "open license" as much as we want, but to me it looks more like OpenGL is really without any serious corporate sponsorship.

The code was already "free" for a given definition of "free", however, three problems were identified.

The old licences:

"forbid the distribution of code that infringes on somebody else's intellectual property rights"

distributors of the code are required to obey any export laws that might apply

require users to inform the distributor if they learn of any potential intellectual property infringement of code releases under the licenses

As such, it was easy to modify the code, but it wasn't free or open enough by the standards of either the Free Software Foundation or the Open Source Initiative.

OpenGL is a standard, just like Java is. The fact that there are many implementations of those standards doesn't mean that there is a problem. Besides which, it doesn't really matter, most people will code for the reference implementation (Sun Java and SGI OpenGL).

Aren't the first two clauses simple facts? I don't see why stating "Don't use this in a way you can't legally use it" in a license is a problem. The third clause I understand, because it is an additional requirement or restriction added to the license.

They took issue with the first clause because, with the current patent situation in the US, anyone could be violating someone's IP rights and not even know it. The 2nd clause, because it's kind of redundant. It's already against the law, why put it in the license?

The grandparent oversimplified this slightly. The problem related to when you had to stop distributing - it was very difficult in practice to be sure you were actually in compliance with the license. In principle, the license was okay, it was just so badly worded in places that it was almost impossible to comply with.

Um, OpenGL already has a documented extension mechanism that is widely used, by virtually every vendor, to provide documented and open access to their extensions. Changing the licensing on one implementation of the standard will not increase the fragmentation of OpenGL, and fragmentation of OpenGL has not led nVidia and ATI to drop it.

In fact... looking at the listed extensions [opengl.org] I see 15 _ATI_ extensions and 54 _NV_ extensions.:)

A significant portion of those NV and ATI (and SGI and APPLE and etc) specific extensions have been promoted to cross-manufacturer standards when a EXT or ARB version of the extension is created. When DirectX gets a new feature added to the cards they get exposed in OpenGL as a (usually) NV extention first, and then when the next OpenGL version comes out there would be a EXT or ARB extention for it that will probably work on ATI cards by that time as well.

Well, Firefox is open-source, but manages to adhere (pretty well) to the standards set for HTML, Javascript, etc.

OpenOffice is open-source, but manages to adhere to a farily well-defined guideline for file formats (ODF).

There are plenty of other examples of open-source projects sticking to well-defined standards and guidelines. I understand your concern; there is no guarantee that incompatible forking won't happen. But, there is at least precedent for open-source communities working together to maintain coh

One of the biggest complaints about OpenGL is that it is slow to evolve and doesn't reflect real world needs as well as Direct X. By opening it up, this allows for unofficial extensions that will be based on the standard but will help fill in some of these gaps. The most popular of these extensions will become part of future standards with the added benefits of already having an existing implementation and having been used in the real-world.

It's a matter of interface vs code. Even though the code is free there's still an OpenGL organization that puts the official stamp on what the OpenGL specification is. Sure you can deviate from that but if noone else cares the it won't be useful. And if you read the actual license issues (you did RTFA right?) none of those would have prevented you from doing the same under the old license.

Like X, it's a matter of a vital developer community. X.org keeps to MIT/X11/BSD-style permissive licenses, but is unlikely to fork as long as the developer community is vital and active - a vendor proprietary fork is counterproductive because changes won't make it back into the ever-changing main tree. Even XFree86's license change was just the last straw - the devs were already pissed off at the impossibility of getting code into the damn server.

The original OpenGL sample implementation was very basic - no vertex/fragment/geometry shaders. Even multi-texturing was still relatively new. There is really nothing to change there. Most developers hav moved on to using to vertex and fragment shaders to keep control of rendering (rather than use OpenGL lighting).

If anyone wishes to make modifications to OpenGL, they can do so by creating extensions. It is up to vendors and the ARB to decide whether they