Slashdot Mirror

10 years ago, Intel was hinting at a massively parallel future (80 core processor rumored in development at the time)

I think the 80 core processor Intel was developing at the time eventually turned in to the Knights Corner aka Xeon Phi chip. Originally Intel developed this tech for the Larrabee project, which was intended to be a discrete GPU built out of a huge number of X86 cores. The thought was if you threw enough X86 cores at the problem, even software rendering on all those cores would be fast. As projects like llvmpipe and OpenSWR have shown, given a huge number of X86 cores this isn't as crazy of an idea as it initially sounds... but still a little crazy :) Ultimately Intel cancelled that project and decided to use that tech for super computing instead of graphics. A result of this is Intel retained the "Gen" design for their graphics core, which is a more traditional GPU design.

And apparently it's not even out yet so this is just the pre-release article about what will be coming in a minor point release. Yawn.

If your talking about these guys, http://www.mesa3d.org/relnotes-9.0.1.html supporting the FOSS drivers, i'm pretty sure NVIDIA's stuff bypasses them entirely.

Theyre useful I suppose for X11 and the framebuffer. But the argument that they are a pain to develop for and that they are a factor in gaming development is FUD.

Typically if you have Linux, old drivers aren't deprecated ever.

Sometimes they are. See http://www.mesa3d.org/relnotes-8.0.html. But those tend to be for really old GPUs, in this case mostly from the 1990s.

In the Windows world, you can usually stick to the old drivers as long as you keep the old OS. For instance, I've recently reinstalled my sister's PC from ~2006 with XP. The old XP drivers for the ATI GPU (R600 series) were still available for download and worked fine.

But problems may arise if you want to install a newer Windows version. AMD/ATI tends to drop older models from new drivers after a few years. In case of the PC above, it happened this summer with Catalyst 12.6. So I guess it would be still possible to use this PC with Catalyst 12.6 and Windows 7, but Windows 8 might be out.

Well, I like graphics, so what about all the work that went into MESA3 OpenGL drivers? Most people I ask "So, what's keeping you from using Linux 100% full time?" Their answer is crappy graphics drivers and no games. In my spare time I'm working to help fix the latter part, so are many other game devs, and a working OpenGL stack is essential.... Think about it, everyone knows Linux is really strong in the server market, so it's these desktop (read: Graphics) users where there's room to grow in a "socially benefiting" way. Now, if only ATI & NV would catch up with Intel on the Linux support front...

Mesa is an open-source implementation of the OpenGL specification - a system for rendering interactive 3D graphics.

The Mesa 3D Graphics Library

Since there isn't a video driver that uses the Cell's SPUs,

http://www.mesa3d.org/cell.html

Then how can publishers assure users that a title still on store shelves is compatible even with a PC manufactured after the game went gold?

Did we read the same article? In the interview they talk about future processing units (either CPU or GPU doesn't really matter) that consist of a lot of small general purpose processors that you access like a regular CPU. Developers will use them just like they use CPU's at the moment.

Which took an order of magnitude longer to get going from scratch than a typical GLUT or AllegroGL app. Because developer time is still valuable, software rendering won't make the OpenGL API go away, even if only because of OpenGL in software.

OpenGL won't go away. It'll still be around for backwards compatibility but it will be obsolete. What software rendering will afford you as an engine developer is flexibility. I don't have time to repeat what's in the article anyway but the gist of it is that it will allow you to take advantage of the hardware more optimally than if you use a fixed function API like DX or OpenGL.

I didn't say they would release the source code. Only that they would write directly to the CPU/GPU

Then how can publishers assure users that a title still on store shelves is compatible even with a PC manufactured after the game went gold?

The same things they used before OpenGL/DirectX became prevalent. The same things they used during the DOS era.

Which took an order of magnitude longer to get going from scratch than a typical GLUT or AllegroGL app. Because developer time is still valuable, software rendering won't make the OpenGL API go away, even if only because of OpenGL in software.

There is the Mesa-3D Implementation of OpenGL. The most recent version offers support for the Cell processor.

1. Is is C++0x ready?
2. Does it work with FreeGLUT or MESA for OpenGL support?
3. Can it make ice cream?

Its open to a select few.

from http://en.wikipedia.org/wiki/Direct3D_vs._OpenGL

Performance

Shortly after the establishment of both Direct3D and OpenGL as viable graphics libraries, Microsoft and SGI engaged in what has been called the "API Wars". Much of the argument revolved around which API offered superior performance. This question was relevant due to the very high cost of graphics accelerators during this time, which meant the consumer market was using software renderers implemented by Microsoft for both Direct3D and OpenGL.

Microsoft had marketed Direct3D as faster based on in-house performance comparisons of these two software libraries. The performance deficit was blamed on the rigorous specification and conformance required of OpenGL. This perception was changed at the 1996 SIGGRAPH (Special Interest Group on Computer Graphics) conference. At that time, SGI challenged Microsoft with their own optimized Windows software implementation of OpenGL called CosmoGL which in various demos matched or exceeded the performance of Direct3D. For SGI, this was a critical milestone as it showed that OpenGL's poor software rendering performance was due to Microsoft's inferior implementation, and not to design flaws in OpenGL itself.

Direct3D 9 and below have a particular disadvantage with regard to performance. Drawing a vertex array in Direct3D requires that the CPU switch to kernel-mode and call the graphics driver immediately. OpenGL, because its drivers have portions that run in user-mode, can perform marshalling activities to limit the number of kernel-mode switches and batch numerous calls in one kernel-mode switch. In effect, the number of vertex array drawing calls in a D3D application is limited to the speed of the CPU, as switching to kernel-mode is a fairly slow and CPU intensive operation.

Direct3D 10 allows portions of drivers to run in user-mode, thus allowing D3D10 applications to overcome this performance limitation.

Outside of this, Direct3D and OpenGL applications have no significant performance differences.

-------

In other words, OpenGL is not that bad performance-wise if you use a good implementation (aka not Microsofts). A good open source implementation is http://www.mesa3d.org/. Don't make me sic Carmack on you.

This has been done at least twice before. NVidia, when they release new drivers, implement new features in software for older hardware (at least they have done so in the past).

Mesa 3D http://www.mesa3d.org/ has supported vertex and fragment programs since 2003.

Think of it this way... How many programs have you seen written for the 3DFX glide API? So, if you are one of the people who still has a glide card, but it was designed so that it couldn't do OpenGL becuase it used completely different technology, how useful would it be to you?

Glide was a great API. Software writtent to use Glide was often much more impressive with stunning visuals that could only be access by directly using the Glide API. As well, Glide was used to accelerate the openGL API which is the way software drivers were meant to be in the first place; an open hardware-specific API for everyone else to adapt their popular API. This solves the disorder of graphics developers from sitting the long route to stable drivers for openGL and Direct3D; someone, like Microsoft or Mesa3D (to voodoo2 Glide API) would just pick up the API from a vendor and run the trials of translating an construment to use it. Of'course, this could lead to practical design limitations, but it would allow some sort of API to appear from a graphics developer

Woops, did I forgot to remove the "sarcasm" tag all this time? Ok... [/sarcasm]

Go take a look at Manticore design on the icculus.org server and just see how near this articles subjective FPGA design is in likeness.

He worked on MESA, here's a pic of him collecting his reward.

My undergrad thesis with a colleague of mine, back in 1999, was essentially a very, very simple realisation of persistent worlds. We created a three-dimensional version of Pong where all activity in one-half of the arena (in our case it was a cube) was handled by one machine. The other half was, obviously, processed on the second machine. The communication between hosts only consisted of periodic heartbeats and the movement deltas of the paddles. Rendering, I/O, physics and the predictive calculations were all done locally (i.e., the machine on which the person was controlling his/her paddle). When we took one machine offline, the user on the still-active machine was notified but was permitted to simply bounce the sphere against the interior of the cube until he/she got bored.

Our game was written in C using Mesa (a 3D graphics library with an API which is very similar to that of OpenGL). Our development machines were IBM boxes running RedHat Linux 5.x. We got the rendering code all working on Solaris machines too. For networking we used UDP and referred to the Stevens book alot.

The ultimate goal of our humble project was to split our arena into octants. Once all eight (8) machines were online we would remove N < 8 machines from the cluster and see how the remaining machines handled the loss of nodes. Because the network is no longer receiving heartbeats from a given machine, another machine would take responsibility and inherit all the process duties thereafter. Ideally, this transfer of duties is totally transparent to all who are watching and/or playing the game.

What drove our desire investigate persistent worlds back in 1999 was my interest in Quake 2 CTF and deathmatch. To hop from one server to the next the user had to explicity exit the server and reconnect to another. I would have preferred if I could seemlessly "walk through a doorway in the game world" and find myself in a different environment. In the background, of course, all network traffic came from a totally different host running a Quake 2 CTF / deathmatch server.

Wouldn't a review of the OpenGL Programming Guide, listed towards the end been a bit more appropriate? I can see Brian Paul rubbing his hands with glee at the thoughts of this one, but for developers I think the programming guide plus the man pages are what you're looking for.

(or, if they're really bright, a second hard drive with Linux/*BSD/whatever, so they can pick up GTK+ or QT or whichever widget set is trendy these days).
This is exactly what made me finall make somewhat of a switch. After continuous poking and prodding at openGL, I finall got tired of trying to get old GL samples to compile in my current VC++ version (or maybe it's also because VS6 doesn't like XP?).

First, I've tried installing Mesa 3d on my laptop, which was already 'nix. For a P2-266 /w a tiny graphics card, the samples render livably. Now, since I really want to test out how well GL apps render on an accelerated card+fast PC, I've installed an extra HD on my main box just to use GL with 'nix.

One of the biggest issues I've had so far is that simple Mesa/GL samples with documentation don't seem very easy to come by. Yes, there are books (and supposedly good ones), but to find one in stock costs over $100 at the moment.

I'm comfortable enough with 3d (from my early D3D/GL days) and C++ to make a go at getting something up and running using GL/GCC, but the lack of starting tutorial or simple samples... tracing down which libs to link etc etc is quite maddening when trying to start with 'nix programming.

Perhaps this is also a good place for any veteran gcc coders (or better, openGL /w GCC) to step forward and provide links and samples?

The high price every new version of Visual Studio seems to be a real detriment to MS. If startup developers can't even afford to teach themselves a little coding, then I will expect more and more developers to move to 'nix. With more 'nix developers, we will find better and cooler 'nix apps amongst the dross (maybe even some nice games eventually), and gradually accelerate away from the world of windows.

• They wanted to optimize for the only the operations they use. Their renderer performs no lighting calculations, for instance.
• They can optimize for a specific operating system and processor. They use MMX instructions, for instance.

It was nice knowing you. openGL was sorely missed, that they were thrown out of their own ARB building by Microsoft. Yes, Microsoft wants nothing to do with openGL. Yes, Microsoft now owns the ARB building that was once the conservatory of openGL.

Don't let the doorknob spank you on the way out.

Aside from nVidia and PowerVR, there are NO HIGH QUALITY OPENGL DRIVERS capable of meeting todays needs. No the DRI project (http://dri.sourceforge.net) is not viable as nobody of such caliber of skill is capable of meeting the requirments of qualifying as a maintaner of the DRI for any brand of closed-documentation graphics accelerator.

Today, only DirectDraw and Direct3D are willingly supported by graphics card designers and manufacturers. Nobody wants a second PC operating system; they just want to deal with Apple Mac OSX or Microsoft WindowsXP. Not another. And with Linux being so fucking binary incompatible with future, past, and present distributions of other companies, that just to provide Linux support they know they will be forced to troubleshoot over 20 fucking possible different Linux distributions. Linux is portable at the Protocol and is why everyone secretly boosts at as the opensource operating system. Without opensource shit, stuff doesn't get re-compiled and without compilation you can kiss Linux software goodbye.

On a stinking XFree86/DRI developer's list, Linus Torvalds confirms your worst fears. Sorry to say it, but Linus Torvalds' quote may be applied to the rest of his stinking world of the Linux kernel; including Mesa3D.

essential for the OpenGL 1.4 specification is *apparently from ARB meetings* owned IP from Microsoft, which means NVidia has to license the technology to use it.

It does not become "port from Windows to Unix" instead. Porting to X11 and porting to the MacOS X gui are not the same.

Ahhh. But we were speaking of 3D Rendering software (Assumed to include modeling and animation). In that case, the choice is simplified because Mac OS X uses OpenGL, as does SGI, Solaris, Linux, etc. "Porting to OpenGL" can be very close to "Porting to Mesa"

Perhaps I should have said more of "Port from Direct3D to OpenGL". Hmmm... but in that case... OpenGL is an option on Windows also, so it could go with "Develop for Windows only, or develop for Windows, Mac OS X, Linux..."

Where the OSes differ with regard to porting (having to change source code, rather than simply recompiling) is mainly in the user interface.

Yes. However, when an application is ported (or developed initially for cross-platform) cleanly, the functionality and UI are abstracted in a better way. Platform specifics are minimized, and shared common code is maximized. Then going to another platform is simplified.

However, there's another issue. The vast majority of games out there don't rely heavily on the native UI widgets. Most gamers like their own UI. If you're doing a game on OpenGL anyway...

But ... doesn't it cost money for an implementation to be tested for OpenGL compliance? Like mesa is an open source software implementation of opengl, and probably satisfies all the tests. But it ain't certified as compliant because a) nobody's coughed up the cash and b) probably past interests in not having an open source implementation back then (though opengl is fully open sourced now). Think of how JBoss had a hell of a time getting Sun to admit JBoss was even halfway J2EE compliant...

It's an interesting project but drivers guys, put some thought into the drivers...

If you ask me GNU Applications and a few other programs are the killer apps for GNU/Linux as a CS student.

1. GCC, Binutils, Emacs/Vim (General Hacking)

2. Mesa (Graphics)

3. Bison/Flex (Compilers)

4. Linux (Operating Systems)

5. Various Packet Analyizers (Networking/Security)

5. MySQL/Postgres (Databases)

The only non opensource application I use is Mathematica, but Wolfram provides student discouts and packages such as Combinatorica are opensource.

In 1998, Larry Wall for his work on Perl and other software.

"Larry Wall won the Free Software Foundation Award for the Advancement of Free Software for his many contributions to the advancement of freely distributed software, most notably Perl, a robust scripting language for sophisticated text manipulation and system management. His other widely-used programs include rn (news reader), patch (development and distribution tool), metaconfig (a program that writes Configure scripts), and the Warp space-war game."

In 1999, Miguel de Icaza for his work on GNOME

"de Icaza headed a team of more than 300 programmers worldwide, most of them volunteers, in the development of GNOME. GNOME is a user-friendly graphical users interface (GUI) and programming platform for GNU/Linux. GNOME 1.0 was first released in March, 1999 and has since had a step-up release."

In 2001, Brian Paul for his ground-breaking work on the Mesa 3D Graphics Library

"The Mesa 3D Graphics Library allows free software users to model and render in full 3D." Jeff Bates, chairman of the Free Software Foundation Awards Committee said. "The library has added tools and capabilities to the GNU/Linux system that are being utilized by people all over the world."

Wouldn't Mesa be exactly that? Of course, in the Introduction
section on the site they note:

"To the extent that Mesa utilizes the OpenGL command syntax or state machine, it is being used with authorization from Silicon Graphics, Inc.(SGI)."

I imagine there would need to be some modifications.

While I would love to see something like that happen I think we would have to wait for a long time. Some apps are really complex and specialized. I don't think we'll see anytime soon something like Maya, Softimage XSI, a Mediacomposer or Inferno like GPL app.

FX companies don't share most of their propietary code because 1) it's written by them, not taken from other GPL code and 2) they need that competitive advantage. Linux usage in FX is a relatively fairly recent occurence. And besides there is tons of propietary stuf that no one knows about outside those places. Sometimes you get brief insights at SIGGRAPH or in specialized publications. It's a very particular market that doesn't lend itself to just open stuff overnight. Then again from time to tiem you see stuff that could be the beginings of the ideas you propose. There is AQSIS (a RenderMan compliant renderer), Mesa and Falmaidan (a fluid simulator) at sourceforge.

There has been talk of FX companies of releasing a lot of code (Michael Goldfarb of Rhythm and Hues for example). It may eventually happen. Some companies have already released stuff or are working on it. Just check some of the RenderMan SIGGRAPH course notes.

Probably best way is to keep an eye on SIGGRAPH and the VESTECH meeting to see how much progress is done, it amazes me every year.

Or you could use Mesa.

Brian's home page
Slashdot interview with Brian
Press release about Brian winning Free Software Foundation Award for Mesa

From the Mesa site (http://www.mesa3d.org) :

Please do not refer to the library as MesaGL (for legal reasons). It's just
Mesa or The Mesa 3-D graphics library.

The reason your programs written in C using Mesa worked on different systems running Redhat Linux is because Mesa by default uses X11 (and the X device drivers) - so you are generally going to trade off performance for portability. (Note that software GLX support is now included in XFree86 version 4 - prior to this Mesa required its own device drivers to take advantage of certain graphics cards.)

MESA is free software why don't you port it?

So the question is, how long before the cheap renderfarm is joined by the cheap rasterisation farm, stuffed with nothing but GeForce2s, Celerons and RAM? Anyone?

There's still a lot of algorithms that you can't easily map to hardware (in other words, stuff that's much easier to program in software only). There's also the problem about the ammount of memory on the graphics card being much lower than the system's memory. Even if you can rasterize textured triangles much faster in hardware than in software, you still want to apply lots of texture layers to your objects, you want to work with larger and much more detailed textures or in general you need more realism than what current hardware-based algorithms can deliver.

But yes, you are right, hardware accelerated render farms will be something common in the future. The massively parallel pieces of silicon that current GPUs are is something you can't ignore. I have done some work on hardware accelerated distributed rendering, but alas, the website is not up yet. For interactive applications is not as good as I had hoped (instead of increasing the speed I can increase the problem size with a little performance gain on the side) but for applications where you want your stuff rendered faster (100x or 1000x faster), it's definitely a go.

The OpenGL case is really sweet: you can use GLX PBuffers (I understand WGL supports something similar too, as will DX-something, if not the current one) to render off-screen. In practical terms that means the size of your image is limited by the size of the available memory on the card. If you don't have GLX 1.3 support (ATI can I have some docs please, I want to understand how the card performs memory management in order to write such an extension for the Radeon under XFree86) you can still use tiling and get the same result (slower maybe, but anything faster than pure software is a gain here)

The OpenSSH teams needs to take a lesson from Mesa. OpenGL is a trademark of SGI. Just change the name of OpenSSH, and you never have to worry about these stupid trademark infringements again.

*shrugs*

Well, as far as graphics go, we do have OpenGL / Mesa.

--

It depends. If you want to program still and animated 3D graphics, then you have quite a few choices. Here are a (tiny) subset of the ones I know:

• Here is a series of accessible tutorials on the mathematics and implementation of 3d graphics
• OpenGL is the API of choice for most platforms. Simple, clear and easy to understand. It does assume that you know what the basics are though.
• Mesa is a free workalike implementation of OpenGL for most platforms. Reading the source to the included demos is a good way to start learning.
• Python is a very good language with OpenGL bindings with which to start messing around. If C and C++ seem too tedious just for experimenting then try PyOpenGL. Python itself can be learned in a weekend after which the GL module is there to play around with.

If you're not interested in programming - just modelling and creating then check out:

• Povray - a flexible raytracer
• Blender - a modelling, animation and sequence editing suite
• Some examples of what is possible

All of these tools and references are free and work on Windows and Linux alike.

Also, how prohibitive is the hardware for this kind of thing?

All you need is a resonable midrange PC and a decent accelerator. A hardware-accelerated graphics card on your platform is a must to view complex 3D graphics at any kind of framerate. Vendors with good Linux support include include Ati, nVidia, Matrox and 3Dfx.

They could redirect the work into porting Inventor too as many platforms as possible just like Mesa does with the OpenGL API. With the *nix base in Open Inventor plus Coin's BeOS, and Windows versions, most people should be covered if they merged.
Then if TGS open sourced their Windows and MacOS versions of Open inventor that would be even nicer.

IMO Games are one area where the GNU/Open Source Model is unlikely to work.

Wrong.

Game engines


http://www.devolution.com/~slouken/SDL/

3D graphics


http://crystal.linuxgames.com/

http://www.mesa3d.org

etc are now a mature software area, and
with today's hardware we're almost at the point where brute forcing it will be a "good enough" programming strategy.

Wrong. Copying graphics to the screen one pixel at a time will _always_ suck.

And artists are, for the most part, a greedy and opportunistic breed....

... suddenly, i feel as though i'm being trolled.

well, reading it again, he wasn't saying that OSS can't produce the code to do the low level stuff, but, since i bothered to paste those links, i'm leaving them in. :P

--
blue

This is such disinformation...Software OpenGL under windows does not go through D3D. It is just not highly optimized. They are using the same Software OpenGL layer that they have always used and it existed before Direct3D was a glimmer in MS's eye...

Yes, its a crappy implementation, but its not THAT crappy. If you must have software OpenGL, then use Silicon Graphic's replacement or use Mesa.

I was rather surprised when I realized that DeltaForce 2, which requires DirectX to run, ran under WINE. It slowly sunk in that Direct3D support had been implemented using mesa (OpenGL). But it's using unaccelerated OpenGL -- I have a Voodoo3 3000. I would very much love to be able to use my Voodoo3 to accelerate Direct3D games under Linux.

OpenGL ... No true Open-Source "implementations,"

Then what's Mesa? It implements the OpenGL API on several platforms.

I have been using the beta version for a while. Extremely nice. We actualy started ordering a linux render farm before we knew when it was going to be released for linux.
As with NT, the images will differ slightly due to floats and rounding and all that jazz. The images will be similar enough to mix shots but not individual frames.

Also, along the SGI and Linux front, I will post a tad of what I had tried to post as a story... no hard feelings here, just infot I thought you all would like to know.

This is from my review of SGI's Spring Linux University.

"Linux OpenGL
The presentation on Linux/OpenGL discussed the opening of OpenGL and the release of IRIS Performer for Linux. The current Mesa/OpenGL hardware
model was presented, with and without GLX (also opened by SGI). The statement was made that SGI was working with NVIDIA on video cards for 3D
graphics workstation level quality. It was also implied that the card would work with other Intel motherboards as well, but in an SGI Linux system one
would see an improvement.
SGI has been working on the direct interface for OpenGL to hardware for a while and has had to go through kernel modules to achieve the results that they
are looking for. No mention of DRI or XFree86 4.0.
"

and

"
Final Thoughts:

All in all, this was a good experience and I would suggest it to anybody. I learned about where SGI stood and where they were going with Linux. SGI is
not taking Linux lightly. We were assured that IRIX for MIPS was going to be continued to at least 2010, but that SGI was going to go into Linux without
looking back. Several mentions of open sourcing parts of IRIX for Linux were made.
I would say that SGI might become a Linux powerhouse in the near future and that what they have learned from previous business ventures has not been
wasted."

*Note: If anyone is working on migrating their render farm to support both SGI's and Linux boxes, I would love to get in contact with you. We use LSF on both platforms with a heavy perl backbone.

On a twisted note, the Mesa domain is hosted by VA Linux.

This leaves David Dawes and Brian Paul. Brian Paul wrote Mesa, and is thus hopefully praised for it among people more interested in 3D than me. David Dawes appears to be an "ordinary" XFree worker, who happened to be with the project from the start, and is still working on it in his spare time.

To me, this leaves David Dawes as the perfect candidate for this award. A person doing a lot work in his spare time for an important project, without getting a lot of credit. I.e. a hero that most of the free software developers can relate to.

What is "MesaGL"? Oh, I see, you're talking about Brian Paul's Mesa project? I suggest you get over there and read the first paragraph, the one titled Introduction... The last line of that paragraph is instructive.
</NITPICKER>

Quake 2 looks good (in a window) and q3test looks great (full screen) with my TNT2 and XFree86 3.3.5. You'll probably also want to update your Mesa library. (I think I had to make a symbolic link to a slightly-modified libMesa, too.)

--
QDMerge 0.4!

Mesa would not presently pass OpenGL certification, check out their homepage and click on the CONFORM link there. Mesa is more feature rich than the MiniGL drivers but its still not a feature complete or even 100% accurate in the features it does support. Mesa != OpenGL, in fact presently Mesa OpenGL. This isn't a flame against you or Mesa, but is just a statement of the facts as they presently stand.

Mesa would not presently pass OpenGL certification, check out their homepage and click on the CONFORM link there. Mesa is more feature rich than the MiniGL drivers but its still not a feature complete or even 100% accurate in the features it does support. Mesa != OpenGL, in fact presently Mesa OpenGL. This isn't a flame against you or Mesa, but is just a statement of the facts as they presently stand.