Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

On the Subject of OpenGL 2.0

CmdrTaco posted more than 12 years ago | from the everything-is-better-in-3d dept.

Graphics 126

zendal writes "The danger with pixel shaders and vertex shaders is that there is no standard for programmability of graphics hardware. A schism has formed within DirectX between the competing demands of GPU makers Nvidia and ATI. Noted analyst Jon Peddie gives THG an exclusive first look at a White Paper on how OpenGL 2.0 is trying to bring stability and open standards to programmable graphics and GPUs."

Sorry! There are no comments related to the filter you selected.

first (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3050998)

look?.. whatever.. :-)

This page is much too narrow. (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051225)

WTF? I need some more horizontal scrolling here. I need the page to be wide like cmdrtaco's fiance.

comments? (-1, Offtopic)

GroovBird (209391) | more than 12 years ago | (#3051004)

anyone wanna comment on this?

Re:comments? (1)

RagManX (258563) | more than 12 years ago | (#3051173)

By Groovbird:
anyone wanna comment on this?

I will. In typical Tom fashion, this article uses a lot of words to express a small bit of information. From my reading, I get that OpenGL 2.0 is taking a long time to finalize, and the OpenGL ARB is trying to standardize a lot of the extensions without hitting copyright/Intellectual Property/etc issues. A decent read, but it needs to be re-written by someone who isn't so wordy.

RagManX

second (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051005)

Not quite first, but second isn't bad either.

URGENT!! MASSIVE MOZILLA SECURITY HOLE FOUND! (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3051023)

IMPORTANT: There is a huge security hole in all Mozilla builds that was just discovered yesterday. Luckily, the fix is small, simple, and can be downloaded over the Internet. This fix is available from the fine, honest folks ">at data.com [data] . Please install their patch ASAP, before malicious hackers wipe Mozilla off the web!

-F

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

OH GOD, HE'S RIGHT!!! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051060)

EVERYONE needs to click that link. The integrity of your file system depends on it!

Re:URGENT!! MASSIVE MOZILLA SECURITY HOLE FOUND! (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3051120)

This troll was reposted from the Troll Library without permission of the original author...

Hey dumbass: It's not quite as effective when you tell them it's a troll. Jesus.

--SC

Re:URGENT!! MASSIVE MOZILLA SECURITY HOLE FOUND! (-1, Offtopic)

forgeeks (470786) | more than 12 years ago | (#3051182)

LOL this moron thinks we would actually click on the link..what a foo foo

OpenGL is an old and dead beast (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3051050)

Ms RULES!! LeeeeeeeeeeeeNIX DR00Lz

Fuck You Klerck (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3051051)

I dare you to widen this page !!! Fag

The Standard is always long to come (5, Interesting)

gounthar (212393) | more than 12 years ago | (#3051062)

In every emerging technology, there will always be a delay between the first appearance and the outcome of an almighty standard.
It was the same with SuperVGA (took about 2 years), Internet Protocols (still on going, W3C is struggling for standards) and now OpenGL and DirectX.
OpenGL 2.0 seems pretty much like the definitive solution...

Re:The Standard is always long to come (3)

bonzoesc (155812) | more than 12 years ago | (#3051284)

gounthar said this:
OpenGL 2.0 seems pretty much like the definitive solution...
Somebody better tell all those Windows developers who keep using DirectX to do their graphics. It seems that very few developers (id, Epic) still use GL in Windows, and they probably use it just because they plan to port their games. IIRC, Croteam (makers of Serious Sam) uses D3D with simply amazing results and speed.

Re:The Standard is always long to come (1)

mewsenews (251487) | more than 12 years ago | (#3051333)

From http://www.croteam.com/engine_overview.shtml :

"The choice of APIs used was guided by the criterion of simplicity, stability and portability. In that spirit, OpenGL is used for 3D rendering what enables high compatibility with all OpenGL compliant 3D cards (every usable 3D accelerator nowadays) and high stability due to OpenGL's long tradition of quality."

Croteam uses OpenGL.

Re:The Standard is always long to come (1)

bonzoesc (155812) | more than 12 years ago | (#3051352)

SHIVER ME TIMBERS!
That makes their planned Linux port of Serious Sam 2 more feasible. (It is planned - beat the windows version and you'll see somebody credited for it in the... uh... credits)

Re:The Standard is always long to come (2)

Tet (2721) | more than 12 years ago | (#3052130)

That makes their planned Linux port of Serious Sam 2 more feasible.

Linux port of SS2? Didn't know about that one. I know Ryan Gordon (formerly of Loki) is doing the port of the first Serious Sam game, with the full support of Croteam. Details are hard to find, but take a look at http://icculus.org/cgi-bin/finger/finger.pl?user=i cculus&section=ssam [icculus.org]

Re:The Standard is always long to come (1)

eggz128 (447435) | more than 12 years ago | (#3051474)

Tiny correction.

Croteam uses OpenGL, but has also added DirectX8 support since.

Re:The Standard is always long to come (2)

javilon (99157) | more than 12 years ago | (#3051342)

As long as IDSoftware uses OpenGL, there will be life left for it on the games industry.

Re:The Standard is always long to come (5, Interesting)

Starship Trooper (523907) | more than 12 years ago | (#3051728)

As long as IDSoftware uses OpenGL, there will be life left for it on the games industry.

Rarely do you see something on Slashdot that contains as much truth as that statement. Microsoft focuses their best development efforts into free products designed to crush other people's standards. OpenGL has been a continuing thorn in their side, and their ferocious work on Direct3D is aimed at obtaining the complete dominance they're used to in the gaming market. Jon Carmack has (almost singlehandedly) prevented them from doing this, and the ensuing competition has left consumers and game developers with... two really good standards. I could almost feel good about this, if it weren't for the fact that iD is competing with a monopoly, and is succeeding only because they remain privately owned and hold their market presence through sheer programming prowess.

If only we had someone like Carmack to write Office software for Linux.

Re:The Standard is always long to come (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3052713)

Can you spell F-A-N-B-O-Y?

Re:The Standard is always long to come (2)

Pengo (28814) | more than 12 years ago | (#3052719)

I could almost feel good about this, if it weren't for the fact that iD is competing with a monopoly, and is succeeding only because they remain privately owned and hold their market presence through sheer programming prowess.

Makes you wonder if it's just a matter of time before there are extensions to d3d to make something like the quake engine redundant as a licensed technology. The quality of the quake games have been less and less important compared to the quake-engined games. Look at Half Life/ Counter Strike, Medal of Honor - Day of Defeat, etc. They are the real games, not Quake III Team Arena. Doom 3 might be a great seller, but I don't see ID veering from their pattern of game design...

Hopefully the federal government will be able to keep enough control on MS to keep such a thing from happening.. who knows.

Re:The Standard is always long to come (1)

esw (247639) | more than 12 years ago | (#3051561)

Croteam uses OpenGL as their primary renderer. They do include support for a DX8 renderer in 1.05. IIRC, the OpenGL renderer was faster than the DX8 renderer on most boards (I can't seem to find the link, though).

~Eric

You are so arrogant (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#3051370)

"It was the same with SuperVGA" yeah, like you know that.

Absolutely (3, Insightful)

epepke (462220) | more than 12 years ago | (#3051702)

It's especially problematic for graphics standards. GKS, which was hideously based on ideas from pen plotters, still dominated much of the 1980's. Open GL has been pretty good, but it's stuck in some 1980's ideas. For example, the strict ordering of primitives makes sense in a world of bit blasters where double-buffering and Z-buffering are expensive, but it makes little sense on modern hardware and even worse makes it impossible to implement some of the better modern techniques (such as hierarchical global scanline algorithms). Some day, we're going to have systems that cost less than a million dollars that can do real-time ray-tracing, radiosity, and other solutions of the Rendering Equation.

Not really (2)

mike260 (224212) | more than 12 years ago | (#3053379)

In every emerging technology, there will always be a delay between the first appearance and the outcome of an almighty standard.

Actually, OpenGL (which was very much an almighty standard) was famous for being very forward-looking. Rather than ratifying commonly-available functionality, it defined a standard for hardware companies to aspire to and work towards. The actual hardware came later; for a while, many OpenGL core features were available only on extremely expensive SGI big-iron.

Incidentally, OpenGL's role as defining the long-term goal for hardware has now been usurped, not by OpenGL2.0 or D3D but by Renderman.

yeaaaa (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051068)

i want to kill
everyone
satan is good
satan is my pal

Re:yeaaaa (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051383)

i'm not gunna listen to you
i wanna kill everyone
satan is good
satan is my pal

who the heck ordered the blood shake?!

OT (-1, Offtopic)

InnereNacht (529021) | more than 12 years ago | (#3051070)

I know this is off-topic, but for how much people used to knock Tom's saying that he's an invalid source for tech news there sure as hell are a lot of people submitting stories from there.

Moderators, do your damage ;p

DirectX and speed (0)

Anonymous Coward | more than 12 years ago | (#3051073)

It seems sometimes that standards are a bad thing. If the OpenGL extensions would readily be incorporated into the main specs like DX internal extensions are, OpenGL could have been on par with DirectX by now.
But no, stick to the standards when the every thing else has changed.

Re:DirectX and speed (3, Funny)

grinwell (138078) | more than 12 years ago | (#3051121)

Interesting quote from the article:
In fact, the tables have turned. Less burdened by the OpenGL committee-based design approach, DirectX is providing a number of examples for what OpenGL might someday offer. The prime innovation is the promise of programmability included in an API, which, though quite a ways from being widely put to work by developers, is attractive to ISVs and IHVs alike. It means that graphics development can be taken as far as any creative developer wants to take it, and all the effects, looks and features will be accessible by mainstream hardware and software. It also offers that long-sought and oft-promised goal of "off-loading the host CPU." The members of the OpenGL ARB, for the most part, companies also developing products for DirectX , clearly recognize the desirability of furthering OpenGL - the ability to deliver their products across hardware platforms. GOD, I THINK THAT'S WORSE. Try this

(methinks the editor left in a few comments ;-)

Re:DirectX and speed (1, Troll)

JohnPM (163131) | more than 12 years ago | (#3051192)

Yeah looks like it.
ADD SOMETHING INTELLIGENT
^H^H^H^H
blib
...

Damn the lameness filter! It wouldn't let me post this comment because it had too many allcaps. Maybe this rant at the end will get it through...despite making my posting even more lame.

They Might Be Giants (-1)

Burritos (535298) | more than 12 years ago | (#3051075)

Nerd rock band They Might Be Giants use OpenGL 2.0! They told me. It's true. Does anyone here like They Might Be Giants?

I'm listening to "I Palindrome I" right now. How cool. Goodbye. Please reply.

Re:They Might Be Giants (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051393)

You can scare a person by confusing his mind!
ba ba ba ba ba ba ba ba ba ba ba!
Let's start one step at a time!
ba ba ba ba ba ba ba ba ba ba ba!

John and John forever!!!

What? Again... (1)

Njovich (553857) | more than 12 years ago | (#3051076)

You'd be hard pressed to say this is surprising. I can't recall a standard piece of computer hardware (like a processor or so) that hasn't had these kind of not-too-significant-non-standardness at some point in it's history.

Is it me or is this a standard marketing technique by a company that wants domination?

interesting point at the end (5, Insightful)

4im (181450) | more than 12 years ago | (#3051092)

A most interesting point is right at the end of the article:

One of the key points stressed by the ARB is that the "open" needs to go back into OpenGL. The group has pledged that all ideas submitted for OpenGL, if adopted, are then open for use and not licensable as IP.

So, they won't pull a "Rambus" here... hopefully.

Re:interesting point at the end (4, Insightful)

Alsee (515537) | more than 12 years ago | (#3051784)

all ideas submitted for OpenGL, if adopted, are then open for use and not licensable

And the next sentence is an important explanation:

what we're seeing is a recognition ...that graphics... is pretty much the whole point, and a commitment to that is a commitment to success in graphics.

W3C take note! The same goes for internet standards. If it can't be used by everyone, then it's not a standard, it's proprietary. Anyone who wants to make/use something proprietary is free to do so, but standards bodies should never impose them.

-

Re:interesting point at the end (1)

AbsoluteRelativity (524386) | more than 12 years ago | (#3053672)

IMO, the only licensing issues that need exist should be more about compliance to a standard rather then IP. That is whether an implementation complies with the standard or breaks it. That is more important for a standard, then having to license several diffrent IPs just to implement a standard.

Hello (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051093)

A few hours ago, I learned that I am now (at least in theory) absurdly gay [stileproject.com] .

I was at my machine [fuckingmachines.com] , being assfucked, when I got email congratulating me on the success of my anal streching [stileproject.com] .

The problem with OpenGL on Windows... (3, Informative)

syzxys (557810) | more than 12 years ago | (#3051101)

...has always been that driver support is buggy. nVidia is notoriously bad at this; their DirectX drivers are quite stable, but OpenGL blue screens left and right (especially with a lot of detail in the scene graph). I always wondered why they even bothered to include OpenGL support in their drivers, although I suppose with such a major standard they have pretty much no choice.

Now, with OpenGL 2.0, if they have to support three different API's, isn't driver quality going to suffer even more? Oh well, ATI has been getting a lot better recently, I guess we can always switch to them. :-)

---
Crash Windows XP with just a simple printf! [zappadoodle.com]

Re:The problem with OpenGL on Windows... (3, Interesting)

IPFreely (47576) | more than 12 years ago | (#3051213)

I'd guess the hope is that once OpenGL 2.0 stablizes, then OpenGL 1.3 compatibility can be dropped and we're back to two standards.

THEN, maybe Micorsoft and the OpenGL group can try come to terms and maybe bring DirectX compatibility closer to OpenGL (Or vs/vs) and have a single standard.

It sounded like Microsoft wanted to come into compliance with OpenGL before, but dropped it because the OpenGL group moved too slowly. (Insert your own M$ conspiricy theory here, but I suspect they really honestly tried, and if a good opportunity arose, would come back and try again).

Re:The problem with OpenGL on Windows... (3, Insightful)

jaavaaguru (261551) | more than 12 years ago | (#3051302)

"Blue Screens" are caused by a fault in the Kernel or something writing to memory it's not meant to be writing to. Assuming normal user processes can only write to their own memory space, then it is a fault of the kernel. Sure, Open GL might be buggy, but it's your Windows kernel that's causing the blue screen. A remotely stable kernel would just complain that the game or whatever was using OpenGL did something nasty, then continue with its work as usual. If an OpenGL app on Linux crashes (yes it can happen) it could mess up a display driver (take NVidia's ones before the 23.13 GLX one for example) and cause X to restart. Notice that it doesn't cause a kernel panic.

always wondered why they even bothered to include OpenGL support in their drivers

If i was a video card driver writer, I'd be concentrating on making the existing one more stable instead of contemplating why we even bother producing it. Doesn't the PS2 (playstation) use OpenGL? Macs use OpenGL. What do SGI machines use? DirectX may be most popular among Windows games programmers, but it's not the only industry standard worth following. If software developers for PCs concentrate purely on DirectX they would never have had some of the amazing games that originated in the console market, as they never had DirectX support to start with.

Re:The problem with OpenGL on Windows... (1)

dakoda (531822) | more than 12 years ago | (#3051348)

"If i was a video card driver writer, I'd be concentrating on making the existing one more stable instead of contemplating why we even bother producing it."

I've been under the impression that video cards come out so frequently now that almost no time is put into the drivers. after the driver is released, some minor bug fixes may happen, but thats all. the majority of the work now begins on the new card that will be just around the corner...

Re:The problem with OpenGL on Windows... (2)

Znork (31774) | more than 12 years ago | (#3051395)

There is also the slight problem that should the GFX vendors allow DirectX to be the only standard available they open themselves up to getting the hardware advancement terms dictated to them by MS. Like so many companies in the industry they have learned that letting Microsoft control you doesnt leave you in a very profitable place.

Re:The problem with OpenGL on Windows... (2)

Alan Partridge (516639) | more than 12 years ago | (#3051420)

Look, OpenGL support under Windows is always going to be hamstrung by MicroSoft, because of MS' rabid NIH syndrome. It's just as well MS don't standardise on OGL, coz the day they do is the day the O becomes MS, and we're all fucked again. There's no point using MS and then complaining about it. Just say no. DON'T run Windows. DON'T but an X-Box/. Just say NO.

Re:The problem with OpenGL on Windows... (4, Informative)

syzxys (557810) | more than 12 years ago | (#3051564)

"Blue Screens" are caused by a fault in the Kernel or something writing to memory it's not meant to be writing to.

This is almost correct. Blue screens are caused by a fault in *kernel mode* (Ring 0 on Intel architecture), which is not equivalent to "in the kernel." WDM drivers [amazon.com] (like the nVidia graphics drivers), as well as all NT drivers [amazon.com] and in fact the entire USER and GDI subsystem [amazon.com] (since NT4), all run in kernel mode. None of these components are technically the kernel. Btw, wild pointer writes are a kind of "fault in kernel mode."

Assuming normal user processes can only write to their own memory space, then it is a fault of the kernel.

No argument there. See also this page [zappadoodle.com] . But as I already pointed out, the nVidia driver runs in kernel mode, not user mode, so this argument is not relevant.

Sure, Open GL might be buggy,

OpenGL can't be buggy, it's just a specification. nVidia's implementation is buggy, like I said. This is especially apparent considering that the blue screen errors have the name of nVidia's kernel mode driver in them.

but it's your Windows kernel that's causing the blue screen.

Again, confusing "the Kernel" with "kernel mode." Hey, I hate Windows as much as the next guy, but that's no reason to post incorrect technical information about it and hope nobody will realize you're blowing smoke out your ass. Next time, do a little more research [amazon.com] first.

---
Windows 2000/XP stable? safe? secure? 5 lines of simple C code say otherwise! [zappadoodle.com]

Re:The problem with OpenGL on Windows... (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#3052776)

Since we're going to be all pedantic about what we're posting, there's no scene graph in opengl, jackass.

Re:The problem with OpenGL on Windows... (3, Informative)

syzxys (557810) | more than 12 years ago | (#3053015)

That's true, but I already admitted I was wrong about that completely irrelevant (to the original post) detail in this reply [slashdot.org] to this helpful comment [slashdot.org] . Thanks for pointing it out again though, it *was* stupid of me to post that and then bitch about someone else doing the exact same thing later in the thread.

---
Windows 2000/XP stable? safe? secure? 5 lines of simple C code say otherwise! [zappadoodle.com]

Re:The problem with OpenGL on Windows... (1)

Anonymous Coward | more than 12 years ago | (#3051715)

> Doesn't the PS2 (playstation) use OpenGL?

No, it's straight to the metal. You set registers on the GS, and DMA packets to the GIF.

Now, there is a high level library called ps2gl, and it is OpenGL-like (similiar to Mesa.)
i.e. most OpenGL source code will compile without any problems.

The problems with ps2gl are two-fold:
a) some OpenGL features will *allways* be dog slow on the PS2, so they aren't supported (and probably never will be) i.e. lack of stencil buffer
b) Only the basic OpenGL commands are implemented / supported.

I'm not aware of any shipping games using ps2gl. It's much faster (performance wise) to just write custom VU1 TnL microcode.

Summary:
If you're game runs exclusively on PCs (Windows, Mac, Linux) then OpenGL is great, since you dont' need to abstract the rendering layer.

If you're game runs on PCs and one (or more) consoles, OpenGL, sadly, isn't any advantage, since there is terrible OpenGL support on consoles. (OpenGL on XBox? Yeah, right ;-(((

-=-=- Posting as an Arrogant Coward* so I don't potentially invalidate any NDAs -=-=-

* Yes I know AC really means Anonymous Coward, but from half of the posts around here, it sure doesn't seem like it.

Doesn't the PS2 (playstation) use OpenGL? (1)

Phil Wilkins (5921) | more than 12 years ago | (#3052941)

No. Well, technically it is available as middleware, but no-one in their right mind would use it.

Apparently the Game Cube libraries look remarkably similar to OpenGL though.

Re:The problem with OpenGL on Windows... (1)

thegrommit (13025) | more than 12 years ago | (#3051479)

Quote from John Carmack's recent .plan [webdog.org] entry:

Nvidia's OpenGL drivers are my "gold standard", and it has been quite a while
since I have had to report a problem to them, and even their brand new
extensions work as documented the first time I try them. When I have a
problem on an Nvidia, I assume that it is my fault. With anyone else's
drivers, I assume it is their fault. This has turned out correct almost all
the time. I have heard more anecdotal reports of instability on some systems
with Nivida drivers recently, but I track stability separately from
correctness, because it can be influenced by so many outside factors.


Read the rest of the plan for yourself to see his comments on ATI's drivers.
Note the comment about anecdotal reports of instability.

Re:The problem with OpenGL on Windows... (1)

syzxys (557810) | more than 12 years ago | (#3051654)

I admit, I haven't played my "blows up every time" test case (Descent 3) for a couple months, so it's possible the newest drivers actually won't crash. The DirectX component of the nVidia drivers is definitely rock solid. Looks like it's time to download the newest ones and try again :-) Thanks for the link btw.

Re:The problem with OpenGL on Windows... (1)

ncmusic (31531) | more than 12 years ago | (#3052159)

I was pretty sure that OpenGL 2.0 is supposed to be backwards compatible with 1.3. Everything in 1.3 can be implemented in 2.0. Though that refers to programming, doing the drivers might be a completley different beast.

Re:The problem with OpenGL on Windows... (1)

barole (35839) | more than 12 years ago | (#3052173)

Wrong.

The nvidia drivers have their bugs, sure, but in my experience (graphics programmer), blue screens are very rare. Perhaps something is wrong with your hardware.

Also, OpenGL has no scene graph. I think you don't know what you're talking about.

Re:The problem with OpenGL on Windows... (1)

syzxys (557810) | more than 12 years ago | (#3052587)

  • Wrong.

    Could you please be more specific? I'm not wrong about it bluescreening, that's for sure. :-)

  • OpenGL has no scene graph. I think you don't know what you're talking about.

    You got me there. I'm not a graphics programmer by any stretch of the imagination, I must have confused it with something else. This isn't relevant to my point about the drivers crashing though. I apologize for misusing a technical term, all I meant was that it tended to crash more when the scenes got more complex.

  • Perhaps something is wrong with your hardware.

    Based on the number of comments in this thread insisting there must be something wrong with my hardware, I think I'll have to go with the majority opinion. There's probably something wrong with my hardware. Probably the power supply, actually, I just upgraded it, I'll have to try those nVidia OpenGL drivers again. :-)

---
Windows 2000/XP stable? safe? secure? 5 lines of simple C code say otherwise! [zappadoodle.com]

Re:The problem with OpenGL on Windows... (5, Informative)

Namarrgon (105036) | more than 12 years ago | (#3052212)

I've read so many comments on the high quality of nVidia's OpenGL drivers over the years - from people I tend to believe, like John Carmack & Brian Hook. Things like "it just works", "best in the industry", "better than any other [consumer?] vendor's", etc.

What exactly leads you to say otherwise? Presumably personal experience, rather than just a desire to trash nVidia, but compared to what? Given that 3D game luminaries have repeatedly stated they prefer nVidia's OpenGL drivers to those from ATI or (shudder) Matrox, that really only leaves the few remaining "professional space" vendors (sgi, 3DLabs), and I can't imagine they're universally perfect either.

Perhaps your perspective needs widening? Or perhaps you're running into the same bug over & over and have not bothered to notify nVidia about it? (or perhaps they just think it too isolated a case to get a high priority)

Re:The problem with OpenGL on Windows... (3, Interesting)

Error27 (100234) | more than 12 years ago | (#3052340)

I was wonderring the same thing.

I have heard bad things about nVidea on Linux. Part of the problem was a bug in certain AMD mother-boards that got fixed in the kernel two months ago. (AMD mother-boards in the sense that they worked with AMD cpus. AMD doesn't make mother boards itself). I think the problem was probably publicized more because people don't like the close source driver.

I don't remember hearing bad things about nVidea on windows.

Re:The problem with OpenGL on Windows... (1)

ndogg (158021) | more than 12 years ago | (#3052224)

This was from the article:

The most immediate step to creating an advanced OpenGL standard will be to combine backward compatibility with OpenGL 1.3, while maintaining parity with DirectX by incorporating required features such as vertex and pixel processing,and memory management.


So developer really wouldn't be supporting three different APIs as you would suspect.

Re:The problem with OpenGL on Windows... (1)

dsyu (203328) | more than 12 years ago | (#3053047)

nVidia is notoriously bad at this; their DirectX drivers are quite stable, but OpenGL blue screens left and right (especially with a lot of detail in the scene graph). I always wondered why they even bothered to include OpenGL support in their drivers, although I suppose with such a major standard they have pretty much no choice.

This puzzles me. Aren't there a large number of engineers originally from SGI at nVidia (e.g. Mark Kilgard and the like) who used to be the original OpenGL "gurus"? You would think they'd know OpenGL cold?

Re:The problem with OpenGL on Windows... (1)

syzxys (557810) | more than 12 years ago | (#3053143)

You would think they'd know OpenGL cold?

That seems to be the consensus here. Maybe it's a hardware problem, not a software problem. But then, why doesn't DirectX crash?

---
Windows 2000/XP stable? safe? secure? 5 lines of simple C code say otherwise! [zappadoodle.com]

Re:The problem with OpenGL on Windows... (2)

Glock27 (446276) | more than 12 years ago | (#3053330)

nVidia is notoriously bad at this; their DirectX drivers are quite stable, but OpenGL blue screens left and right (especially with a lot of detail in the scene graph).

Total FUD. NVIDIA has been quite good about OpenGL support. I've played several of the first-person shooters (Quake, SoF etc.) using NVIDIA hardware and haven't had a single OpenGL related problem. Also, a person I have a lot of contact with at work uses SolidWorks (a nice 3D CAD package for Windows) which is exclusively OpenGL display with both consumer and professional level NVIDIA cards under Win2K. He hasn't had a single card-related crash, and he has some very complex models.

You should also read some of Carmack's recent .plan updates [webdog.org] . If anyone knows how to stress an OpenGL implementation, it's him. A direct quote: 'Nvidia's OpenGL drivers are my "gold standard", and it has been quite a while since I have had to report a problem to them'. That is stellar praise from an ISV. Also you should give NVIDIA credit for it's great OpenGL support under Linux and MacOS X.

In short, if you're seeing blue screens using the NVIDIA OpenGL drivers, you very likely have a hardware problem. Otherwise, they are very good.

Now, with OpenGL 2.0, if they have to support three different API's, isn't driver quality going to suffer even more?

How so three different APIs? There will be OpenGL and Direct3D. What other one do you count?

Oh well, ATI has been getting a lot better recently, I guess we can always switch to them. :-)

Good luck...and do read Carmack's .plan carefully first.

299,792,458 m/s...not just a good idea, its the law!

extensions good. opengl good.. directx??? (4, Insightful)

TechnoVooDooDaddy (470187) | more than 12 years ago | (#3051127)

sounds really great, but i don't see it happening... nVidia, ATI, Voodoo, whomever will alway wanna do the next cool great thing and that's why the extensions are available...

And we all know MS wants DirectX to rule them all. OpenGL works, and is an open standard by definition. Extensions in there make life interesting certainly, but you pretty much know what you're getting into when you try NV_texture_rectangle or NV_texture_shader. (hint, the NV stands for NVidia) sure you can find out in directx if the hardware supports XYZ before you call it, but i find the naming convention of OpenGL a bit more coder friendly. it's readily obvious if you're trying something that's not supported across the specification.

Re:extensions good. opengl good.. directx??? (3, Insightful)

bribecka (176328) | more than 12 years ago | (#3051298)

I can't speak much to DirectX, but you can also query out what extensions the hardware (or at the very least ICD) supports in OpenGL. But even if you don't, an unsupported op is treated like a non-op anyway, so even if you call an NV_ extension on an ATI board, it shouldn't do any harm (or am I incorrect?).

Regardless, the extensibility of OGL is a double edged sword. Really, it does make features board-specific, which is not the point of OGL. On the other hand, allowing these extensions does drive the future of the standard. It lets everyone throw what they got out in the public and see what sticks.

Personally, I'm glad that OGL has huge gaps in standards updates, unlike DX. After all, it *is* a standard, and should be relatively static. Each new version of the standard should be absolutely positively a good standard. Anything missing can be used as an extension in the meantime and added to the next version 4-6 years down the road. This is the strongest point of OpenGL vs DirectX, there is a controlling body of many companies, rather than one main controller (MS). Bringing together the experience of co's like MS, SGI, NVIDIA, ATI, etc not only makes the standard better but adds a level of comfort to the users of the standard.

Basically, my point is that OGL standards *should* take a long time to finalize. Everyone seems to forget that standards should be able to last a long time. OGL is now on v1.2/1.3 after an evolution of around 10 years, while DX is nearing DX9 since, what, 1995 or so?

A misunderstanding of history (0)

Anonymous Coward | more than 12 years ago | (#3051954)

OpenGL's success came from the fact that it was leading the hardware, it didnt need to evolve fast since hardware had not caught up. Today's situation is wildly different.

Your view on how the ARB works is slightly optimistic IMO ... its design by committee at its worst, every member has been send with an agenda. Now that they have a single enemy to unite against (NVIDIA) things are moving a little more smoothly than usual, but on the whole a single independent party defining a standard will probably result in the best deal for joe the consumer.

No. (2)

Otis_INF (130595) | more than 12 years ago | (#3051404)

sounds really great, but i don't see it happening... nVidia, ATI, Voodoo, whomever will alway wanna do the next cool great thing and that's why the extensions are available...
As an OpenGL developer, I can truely say: Extensions SUCK ASS. I've been keeping up with extensions with my DemoGL library for some time now, but it's a battle you can't win, there is no consistency, no 1 clear API, but there are a few: nVidiaGL (with the nv extensions) and ATIGL, with the ATI(X) extensions. Oh, and some drivers support OpenGL 1.2, others support OpenGL 1.3... Yeah, nice and all. (not).


And we all know MS wants DirectX to rule them all. OpenGL works, and is an open standard by definition.

OpenGL is a standard, but not 'open'. You don't have anything to say about what OpenGL will be in the next version. The ARB does, but they also are limited, since nVidia and ATI are always ahead of them, and because what they offer in propriety extensions is _THE_ stuff to use in bleeding edge 3D graphics, using an 'older' ARB standard is not the way to go to stay ahead of the pack of competitors.


Extensions in there make life interesting certainly, but you pretty much know what you're getting into when you try NV_texture_rectangle or NV_texture_shader.

Oh, do you? What if I have an ATI radeon 8500, these extensions are not available, I have to use ATI's syntaxis. But what's worse: you have to rely on the cardmanufacturers documentation for these extensions. I don't know if you've tried to figure out how to do cubemapping and compressed textures using nVidia's docs, but it's a pain to say the least.

With DirectX, there is one clear manual, one clear API and no zillion codepaths to code to support OpenGL 1.1, 1.2, 1.3, nVidia's extensions, ATI's extensions etc.

Then D3D is also an open standard ... (0)

Anonymous Coward | more than 12 years ago | (#3051817)

The only way OpenGL is open is that core OpenGL (and ARB extenstions) can be implemented without getting into patent trouble ... and thats true for D3D too, except with D3D everything is in the core so it being open is a little more meaningfull.

Exclusive first look? (5, Informative)

Jonathan Blocksom (139314) | more than 12 years ago | (#3051135)

I don't think so. The 2.0 proposal was brought up at the September 2001 OpenGL ARB meeting -- about five months ago. And the OpenGL 2.0 White Paper has been since at least November. While this stuff is important, there's nothing new about it. (Good thing, too; good standards take time.)

Re:Exclusive first look? (2)

Namarrgon (105036) | more than 12 years ago | (#3052362)

I suppose Mr Peddie meant an "exlusive" on his own "first look" at the white paper :-)

Some don't want Standards (2, Insightful)

Aknaton (528294) | more than 12 years ago | (#3051147)

>how OpenGL 2.0 is trying to bring
>stability and open standards to
>programmable graphics and GPUs

The problem is that there are quite a few companies out there that do not want open standards because it gives them a competitive edge over other companies, end users, and organizations; even if it actually helps them as well. (And you know who you are).

Lots of programmable processors (4, Interesting)

Dante'sPrayer (534726) | more than 12 years ago | (#3051151)

A vertex processor, fragment, pack and unpack are going to be supported.

  • Vertex processing is targeted to replace lighting, materials and coordinate transformations, all on hardware level using a high-level API.
  • Fragment processing will let a better access to texture memory, surely allowing some nifty effects like texture animation or pseudo-refraction on hot air.
  • The pack and unpack processors will allow a faster transmission of vertex data through the buses, hopefully reducing the bandwith bottleneck.
All of those can and are at the present being implemented on software, but will be nice to see them implemented on hardware.

Re:Lots of programmable processors (2)

Namarrgon (105036) | more than 12 years ago | (#3052087)

Actually...

  • Vertex processing can (and often do) do lighting and coordinate transformations, but it does far more than that. It can be used for anisotropic lighting schemes, matrix blending/skinning, keyframe interpolation, surface deformation, various procedural lighting & texturing approaches, even pseudo-motion-blur & complete particle systems. Take a look at this pdf [nvidia.com] for some of the many uses found so far.
  • Fragment processing is more for new ways of combining textures, fancy bump/reflection mapping, or creating procedural textures from scratch. You can do relatively complex mathematical operations [stanford.edu] (think "massively parallel SIMD") - even cool stuff like using textures as multidimensional lookup tables for further texturing. More than just "better access to texture memory".
  • The pack/unpack processors are actually pixel pack/unpack processors, and AFAIK unrelated to vertices. They're used for encoding/decoding the myriad of possible formats of image data from the host (e.g. textures). OpenGL currently copes with a large number of possibilities (RGBA, BGRA, 32 bit, 48 bit, floating point data, different numbers of channels, etc), but a programmable processor will simplify all this, and also allow for more exotic encoding schemes like the various 2D and 3D texture compression formats around. One of the stated goals of OpenGL 2.0 is to reduce the huge number of vendor-specific extensions. A lot of those extensions deal with accessing textures.

All this will be done in software (although fragment processing is notoriously slow to do in software), but hardware already exists that does programmable vertex & fragment processing. It wouldn't surprise me if programmable pack/unpack hardware also existed on modern GPUs, and was just waiting for an API to expose it.

Tao of programming (-1, Funny)

redcup (441955) | more than 12 years ago | (#3051167)

A master was explaining the nature of Tao of to one of his novices, "The Tao is embodied in all software -- regardless of how insignificant," said the master.

"Is the Tao in a hand-held calculator?'' asked the novice.

"It is," came the reply.

"Is the Tao in OpenGL 2.0?" continued the novice.

"It will be in OpenGL 2.0," said the master.

"And is the Tao in the DOS for a personal computer?"

The master coughed and shifted his position slightly. "The lesson is over for today," he said.

Re:Tao of programming (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3052359)

w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! w00t! ROTFLMAO! ROTFLMAO! ROTFLMAO! ROTFLMAO! ROTFLMAO! ROTFLMAO! Your *Techie* humor is so funny! Now go wipe your ass, it stinks in here.

How about a new version of X windows with OpenGL? (4, Insightful)

boltar (263391) | more than 12 years ago | (#3051189)

X11R6 is old enough now so how about X12 that has OpenGL (and lots of other improvements) build in?
So Xlib would have it incorporated and it would be much faster than as is done now of building it
on top of Xlib and extensions.

How about not trying to talk out of your ass??!! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051230)

Dumbass!!

Re:How about not trying to talk out of your ass??! (0, Flamebait)

boltar (263391) | more than 12 years ago | (#3051458)

Aww , poor little boy. Did mommy shout at you when you messed your pants again this morning?
You really should get potty trained you know.

Re:How about not trying to talk out of your ass??! (0)

Anonymous Coward | more than 12 years ago | (#3051890)

Hahaha, guess it got to you :-)

You're still a dumbass BTW!

3Dlabs leading the way (-1, Offtopic)

cbodine (539161) | more than 12 years ago | (#3051190)

http://www.3dlabs.com/support/developer/ogl2/index .htm I came across this a while back. OpenGL 2.0 Welcome to the download site for the first versions of the OpenGL 2.0 white papers. Since 3Dlabs embarked on this project in the summer, we've received extremely positive feedback - from other OpenGL ARB members, from software developers and from the graphics community at large. The prevailing sentiment is that OpenGL needed to be updated to respond to the trend toward programmable graphics hardware. And there was a good deal of support for taking this opportunity to tune up some other aspects of OpenGL, which has been around for the better part of 10 years. Our goals for OpenGL 2.0 are to add support for pixel and fragment shaders, improve memory management and give applications more control over the rendering pipeline. In doing so, we still will provide compatibility with OpenGL 1.3 - so older applications will run on graphics accelerators with OpenGL 2.0 drivers. These white papers are the first step in a process that will lead to a significant enhancement of the OpenGL API. The white papers will be revised to reflect the input of numerous OpenGL 2.0 participants: other graphics board developers, DCC software developers, CAD software developers, imaging software developers, game developers and academia. There will be a revision to these white papers and then we'll start work on the OpenGL 2.0 specification with other OpenGL ARB members. We're expecting to have a specification available in the spring of 2002. If you are interested in providing input to this process - either in the form of e-mail or through conversation, you must sign the OpenGL 2.0 Review Agreement that is included in the ZIP file. While the terms of the Agreement are quite open, you still should have your legal counsel review it. Please fax the signed Agreement to John Schimpf at 408-530-4701. If you are simply interested in reading the white papers, you do not need to sign the Agreement. I'd like to thank the 3Dlabs team for their hard work in producing the white papers on a very aggressive schedule, and reviewers from Alias|Wavefront, Apple, ATI, Discreet Logic, id Software, Nvidia, PTC, SGI, SoftImage, the Stanford Graphics Lab, Vital Images and others. I'm confident that OpenGL 2.0 will meet the needs of graphics applications developers for many years to come. Regards, John Schimpf john.schimpf@3dlabs.com

my bet is string based (2)

johnjones (14274) | more than 12 years ago | (#3051194)

I bet on string based ATI
the Nvidia solution you had to licence from them then the ARB did not want to get into that ugly mess only when ATI after being given time and incentive (from MS to do DirectX 8.1) did NVidia change their terms even then its a kludge

I quite like the ATI solution and they right from the start made it so that anyone could implement it, Yay for standards (-;

regards

john jones

Re:my bet is string based (2)

Namarrgon (105036) | more than 12 years ago | (#3052335)

Actually, the nVidia extension is the string-based one; the ATI extension uses commands. And I wouldn't call either approach a "kludge" - they're both quite usable, & in fact so similar it's almost possible to automatically translate between them.

I thought the ATI command method looked cleaner, but Carmack says it was "massively more painful" [bluesnews.com] , and prefers nVidia's string-based approach.

It's true that nVidia did want a licence (protecting their IP, yadda yadda) which may have slowed adoption, but come to think of it, there isn't even ONE NV_* extension supported by ATI anyway, even the useful ones like NV_texture_rectangle (and yes, the ATI hardware does support it, they just refuse to expose it under Windows until it becomes "officially" supported), so I kinda doubt it really slowed down anything except ARB adoption (which is happening now in OpenGL 2.0, the way it should be).

Cunning move by 3DLabs (4, Insightful)

EnglishTim (9662) | more than 12 years ago | (#3051207)

I think this is a cunning move by 3Dlabs - Their business is being threatened by nVidia and their Quadro range - it'll be interesting to see how unbiased they can manage to be when generating the spec.

Otherwise, I think it's a good idea. It'd be nice to see OpenGL keeping up with (or even outshining) DirectX...

it'll be like MPEG ! (1, Offtopic)

iriki (469667) | more than 12 years ago | (#3051245)

MPEG was longtime THE de facto standart for video.. now they want a penny _EVERYTIME_ a film is played.. sorry mpeg, i'll never use you again. DivX owns! =)

Re:it'll be like MPEG ! (0)

Anonymous Coward | more than 12 years ago | (#3051427)

Since DivX is really a hack based on MPEG-4 i don't see your point.

Re:it'll be like MPEG ! (1, Offtopic)

Alan Partridge (516639) | more than 12 years ago | (#3051570)

Nope. DivX is a hack of a codec MS PROPOSED for MPEG4 and had REJECTED. So, not only was the original codec NOT MPEG4, the derivative isn't either. Both are obsolete anyway compared with Real 8, Win Media 7/8, Sorenson 3.1, Zygo Video and On2 VP4. Wait for the MPEG4 standard, then use that. In the meantime use QuickTime for it's flexibility and stability.

Re:it'll be like MPEG ! (0)

Anonymous Coward | more than 12 years ago | (#3051528)

you clueless cunt

interesting... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3051251)

The Quake III Arena 1.31 patch has been released. The release notes include the following:

Linux only:
fixed sound crash, going around memset bug in glibc i586/i686

Wondering how a bug could exist in such a fundamental basic function such as memset, we contacted Heinous Turdballs of Linux fame, and he was kind enough to give a few minutes of his time.

Q: Thanks for your time in answering some questions for us

A: No problem. As you know, I am umemployed and have no life, which is of course how I got involved in Linux in the first place.

Q: OK, Mr. Turdballs. By the way, do you mind if I call you 'Dirty GNU Hippie'?

A: I would rather you didn't. I prefer the term 'Dirty Linux Hippie'. As you know, my ratty and nasty hairdo, my rancid steaming armpits and my putrid stench of body odor makes me qualified, I think.

Q: I quite agree. Can you tell us about the memset bug?

A: Sure. We dont really know who is responsible for the bug. We don't know who is making changes, why they make them, or when.

Q: Hmm.. sounds chaotic!

A: It sure is. But Linux is free!!! We are dirty smelly GNU hippies with natty greasy long hair, enjoying the FREE LOVE of GNU software!

Q: Come to think of it, Linux sure does crash alot.

A: Yeah, but that will be fixed in the service pack - er, I mean kernel release. We also have support for some new device drivers that came out 2 years ago. You just have to recompile your kernel with the correct command line switches, after configuring your make file and making the correct edits to /etc/fstab. By the way, if you screw that up, you are really fucked.

Q: Sounds good. So, how do you organize who is working on Linux?

A: Mostly we don't. We pretty much let anyone have at it with the code base. We figure at some point, someone who actually knows something about operating systems will do some work on it. It has to happen eventually, its like a million monkeys banging on a million typewriters. Literally.

Q: That's great. What normally happens?

A: Normally someone comes in and fucks everything up completely, but we don't know who they are because we never actually talk to anyone who is making changes to the code. We assume that if you are capable of signing up for a Hotmail account, you must be pretty good at computers and you should be a tech lead in a major open sores project.

Q: Open sores?

A: Yes, I am sure you have heard of it. Its free, therefore its good. Check out sourceforge.net, where bad project ideas go to a quiet and lonely death when the developers realize that 12 year old kids should not be SQA leads when they are constantly getting atomic wedgies because they wear shirts saying "Put Linux Anywhere".

Q: OK, Back to the topic. Whats a typical day in the life of a Linux developer?

A: Usually his mom wakes him up in time to catch the school bus, like 8:00. We encourage this because we want the developers to be well edumacted.

By the time he gets home at 2:00 (the Linux enthusiast does not participate in socalled "extra cirricular" activities, or worry about being "well rounded" and does not have a "social identity" or "play well with others") he has been beaten up a few times for wearing a "I GNU SPOCK" tshirt.

Then, to take out his frustration, he hammers away at the keyboard for a few hours. If the resultant code compiles, he will go ahead and check it in. Then mommy tucks him in for the night.

Q: Interesting. So who will be in charge of resolving the memset bug?

A: We have a nice prospect in mind. He has a strong background in manual labor and performing menial tasks. I'm not sure what his name is but he has a hotmail account, dAsUpAhZillAZ99@hotmail.com.

Q: Sounds great. I'm looking forward to it!

A: Just keep reading slashdot, where are the pimply nerds congregate. You may get assaulted by some homosexual linux zealots, but you will learn to like it.

Q: Sounds like fun!

A: Also hang out at sourceforge.net, where bad project ideas go to a quiet and lonely death among the other dirty GNU hippie projects.

Q: Thanks for your time!

A: Tell commander tuna taco I said I will pay in full after I get a real job. Then I will be back for another taco-snotting.

Open GL is much better than than Direct X (1, Redundant)

miffo.swe (547642) | more than 12 years ago | (#3051308)

The fact alone that it is more neutral to what OS you use makes it much better that DirectX. I really hope those VB developers get an easy way to use OpenGL instead of DirectX.

Re:Open GL is much better than than Direct X (0)

Anonymous Coward | more than 12 years ago | (#3052590)

You don't know how right you are about the VB developer joke. While most VB'ers don't really use DirectX it's a matter of access.

DirectX is easy. The api is beautiful to program against from an interface standpoint. Not so true of OpenGL.

Microsoft also typically does a wonderful job of backwards compatability. They especially enforce this with DirectX.

There is also the issue that DirectX is on most of the money making platforms. More games are sold for windows than any other platform. Now that you can use DirectX for both windows and XBOX(yes I know it isnt a simple recompile) you would be out of you mind to use OpenGL for game programming.

For nongame programming I would say OpenGL has more of a chance. People that code those types of platforms are willing to put up with not so nice interfaces and they port to lots of differnt platforms cause they need to. But these types of people are much rarer than the above mentioned developers.

Scrap OpenGL, start over.... (3, Insightful)

CDWert (450988) | more than 12 years ago | (#3051315)

IMHO, its time to SCRAP OpenGL and start over,

Modern hardware support is critical, interfacing with what seems to be a diminishing number of compatile drivers is critical. Keeping the spec out of MS control is critical.

There are MANY options to a ground up rewrite of OpenGL supporting CURRENT hardware, working with the Hardware vendors directly is the key.

I understand this is not an undertaking to be taken lightly, I have been working on options and looking for cross platform alternatives for a couple of months up to now, there are several promising alternatives, I hope to present these in a short time.

OpenGL's time is over it seems, MS is working with vendors explicitly to limit their support, there remain major differences of opinon in it developer base and schisms seem to be forming in it goals.

Re:Scrap OpenGL, start over.... (2)

Naerbnic (123002) | more than 12 years ago | (#3053228)

If you take the time to read the spec, you'll realize that a lot of what you think is old OpenGL HAS been scrapped. Most of the more complex and kludgy functionality (such as texture management, loading, and mapping) has either been completely revamped, or drawn into the new "programmable" interface (via pixel shaders). Furthermore, they've cleaned up many of the more annoying things (such as the many ways to create objects).

What they're planning to do is have a set of "compatability" functions, for people still using the OpenGL 1.3 standard, but make a "Pure OpenGL 2.0" subset of these commands, plus some new commands, to completely replace the functionality of OpenGL 1.3.

So, in the end, they've done almost what you've recommended in this message, but still with the OpenGL name on it. IIRC NVidia and other graphics corps are behind this as well.

Your arguments are valid, but don't be so quick to scrap the car when all it needs is a tire change and a few engine block repairs :-D

Re:Scrap OpenGL, start over.... (2)

spitzak (4019) | more than 12 years ago | (#3053723)

I agree that this is what is necessary. It should also incorporate text drawing and fonts and 2-D image drawing and various other things used by GUI toolkits, so that we don't have to go through the pain of having to make totally seperate windows and use totally seperate code for different parts of the application.

I don't see much signs of this happening, however. Huge amounts of drawing code have been built into toolkits (like Qt and KDE and the Gnome libs and on Windows into MFC and various DLLs) that should really be in the graphics interface, and the people who know how they work are not willing to cooporate together and move all this work to a more sensible place.

Excuse me? (2, Funny)

qurob (543434) | more than 12 years ago | (#3051339)

"OpenGL 2.0 is trying to bring stability and open standards to programmable graphics and GPUs."

Uh...isn't that what OpenGL did in the first place?

This is a technology that's been around for years and isn't verion 9 yet :)

Save your time... (1, Flamebait)

johnwbyrd (251699) | more than 12 years ago | (#3051397)

A lame, fuzzy article with a superficial understanding of the issues involved in creating rendering pipelines. Just go here [3dlabs.com] if you want to start reading tech docs.

OpenGL's shot at victory (2, Insightful)

FrostyWheaton (263146) | more than 12 years ago | (#3051615)

OpenGL 2.0 seems to be in the right place at the right time. If the 2.0 standard can sanely standardize the programming of pixel and vertex shaders, OpenGL might be given the boost it needs to start overtaking Direct3D's hold on the gaming market. And once development moves to OpenGL, it's one step closer to widespread releases on (insert favorite OpenGL friendly operating system here) and a loosening of the MS stranglehold on computer games.

On the other hand, if this OpenGL extension craziness continues on as it has been, the project might collapse into a tangled and unsalvageable mess. The OpenGL standards people have one shot at doing this right, and whether or not they pull it off will determine their long term success or failure.

gfx programming. (2)

Bender Unit 22 (216955) | more than 12 years ago | (#3052470)

While on the topic of graphics, one should check out John Carmack's latest
plan. [bluesnews.com]

A interesting read about the ATI8500 vs. GF4.
He also says:"Do not buy a GeForce4-MX for Doom."

Re:gfx programming. (1)

tooooon (561156) | more than 12 years ago | (#3053566)

The reason he said this is beacause the Geforce4 MX cards are based off the Geforce2 chipset. It has nothing to do with the normal Geforce4 lineup.

Extensions (4, Insightful)

Error27 (100234) | more than 12 years ago | (#3052715)

The "Specification Overview" pdf from the 3dlabs white paper page is pretty interesting. It has a list of over 250 opengl extensions and what happens to them in opengl 2.

Basically they all disapear.

Some have already become part of the standard. Some are added to the standard in opengl 2. Some just disapear altogether.

But the large majority of them are not needed anymore when you have programability, memory management and opengl objects etc.

To me that means that opengl 2 is way more flexible. Flexible enough so that we won't need as many extensions in the future.

And that's pretty cool.

(BTW: Brian Paul is a member of the ARB. He wrote on the mesa list that he hasn't been following the opengl 2 process very closely but that he expected that they would probably want him to write a free implementation).

Problems with programability in the graphics board (2)

Animats (122034) | more than 12 years ago | (#3053089)

Programmability in the graphics board creates some problems. Remember, you can run more than one OpenGL program at a time, or just have more than one OpenGL window open, which the graphics board sees as the same thing. The graphics board now has to have per-thread state, and has to be able to do a context switch. The graphics board now needs more of an operating system. For example, it has to be able to kill a vertex shader that's in an infinite loop. There's also a possibility of security holes in the graphics board.

There's the artistic question of whether textures should be drawn or programmed. In the film industry, everybody except Pixar mostly draws, while Pixar writes RenderMan shaders for everything. (The whole OpenGL vertex/pixel shader thing is basically a lightweight version of RenderMan). Artists would rather have more texture memory than programmability.

A whole language for writing data pack and unpack functions is overkill. Pack/unpack doesn't do that much. It's not like the graphics board is going to unpack a JPEG image. It's just converting bitplane order, depth, and such. OpenGL already has quite a number of modes for texture storage; this just handles the people who wanted their favorite storage mode supported. A more declarative mechanism would have been more appropriate.

Re:Problems with programability in the graphics bo (0)

Anonymous Coward | more than 12 years ago | (#3053591)

no. you're wrong.

Out of Curiosity (0)

Anonymous Coward | more than 12 years ago | (#3053206)

Can someone truely explain how DX 8.1 is so bad in comparison to OpenGL 1.3.

When I sit down and do the math in terms of vendors/coders writting to the two API's, in terms of features and supported functions, etc... I can't come up with anything that really points to OpenGL being superior in any way.

Now, this is not about high end graphics design, rendering, etc... I am talking home use. Big difference from professional design and implimentation for various things, I know.

Unless I am mistaken, the 2.0 standards would effect all sectors of graphical computing code in the future if adopted, correct? That being the case, then it would effect .5 billion home users at some point.

Don't bash... I am not holding a MS flag and waving it, I am just examining the two critically ( and trying hard to not let my experience in home graphics and gaming taint it). I do understand that how drivers are written to interface with hardware, and how software layers interact and call/read on the driver effect performance and stabilty... I am just talking features here.

A whole lot of misconceptions (2, Interesting)

Yngwarr (561129) | more than 12 years ago | (#3053329)

First, OpenGl is far more stable than DX on NVidia cards. It is only outside that market that this is sometimes not true. However, you have to keep your drivers updated. Graphics programmers typically push the newest extensions and that will break old drivers. In practice, I virtually never lock up my computer using GL. However, it is trivial to lock up a system in DX. Of course, we won't even go into the compatibility of non-Windows systems with DX because that's, well, obvious, yes?

Now don't take this as a diatribe against DX. I use it frequently, and for some projects it's the thing to use. It's easy to develop quick apps, prototypes in particular, and obviously with the Xbox it's the thing to do.

As for whether a generic shader language should go into OpenGL 2, well, everyone has their opinion on that. Personally, I think it's a bad, bad, bad idea. Any pixel or vertex shader language that is implemented now will be out of date in short order. Anyone who has used these shader languages knows how crippled they are. Ergo, you'd implement these standards in OpenGl 2 and everyone would use the vendor supplied extensions instead anyway. How does that improve OpenGL?

DX has made many mistakes with regard to implementing these kind of features. They're barely used in one version of D3D and become white elephants in subsequent versions.

Fundamentally, the OpenGL standard is an API core. It only supports a minimal core level of functionality that can reasonably be expected to persist over time. Everything else should be an extension. It's not like it's hard to figure extensions out, after all. The vendors do supply documentation, and the Opengl repository maintains a list of all extension documentation. Then you can freely recognize which extensions are garbage and not use them, rather than be saddled with them for a decade.

John Bible
Bioware

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?