Which API is better?

[DemoCoder]

I'm still waiting to see how all of this (GLSL approach) has in fact practically benefitted the consumer. Get your own friggin clue.

Well, since OpenGL1.5 was just ratified and it generally takes about 18 months to design a new game engine, perhaps you should be a little more patient. Many people have been waiting for PS2.0 to practically benefit them, or the D3DX effects framework.

BEcause it was a piece of crap 1+ years ago? Or did was (and still is?) HLSL compiling BETTER (performance and bugs) than Gc not exactly what happened? I could've sworn that the Cg compiler was a big sore spot of the whole effort...

The first versions of MS's FXC also produced poor code. Not as bad as Cg BETA, but poor none the less. Of course, you're still missing the essential fact that the biggest part of the compiler is in the drivers which convert PS2.0 token streams into native code.

So in any situation...you still need to download "a patch." And of course...with "compilers built into drivers" that have "across the board increases / fixes", you seem to have negated the "it can BREAK apps that happened to 'rely' on the older functionality" effect.

Yay...id tells me to download the latest driver, which does wonders for Doom3...but breaks whatever other game someone decides to actually code in GL.

None of your arguments have anything to do with GLSL specifically. The problems you cite apply generally to the design of operating systems today.

Yes, you need to download a single patch, instead of N patches. Sure, dynamically linked code is a central point of failure which can effect multiple applications, but this is no different than any piece of code in modern software development. All operating systems have moved to shared libraries, shared components, and shared drivers. Why? Because the benefits outweigh the problems.

Here's an example of a problem with static linking. In the past, a majority of applications statically linked in functions to lookup domain names, many from the libresolv DNS client library. In the mid-90s, I discovered a buffer overflow attack in this library which allowed intruders to seize control of just about ANY internet enabled application (ftp, browsers, etc) Got my picture in NYT, WSJ, WAPO. After the bug was fixed, *THOUSANDS* of applications that used libresolv had to be patched and fixed on millions of systems. Unlike when Microsoft issues a "hotfix" today where they patch a single DLL or EXE, this effected almost every internet enabled component and required recompiling everything.

Yes, sharing code between applications means the shared code becomes single point of failure. But it is also a single point of benefit. That's why today's operating systems have abstract device driver systems, shared components, processes, services, and libraries.

There are performance benefits to static linking (unless you have a runtime compiler), and some apps will resort to static link if they want a specific older version of a library (but today, most OSes support versioning, so even that is starting to decline)

I'm also the one who has actually seen and touched a few games that have been released / compiled with HLSL shaders. Still waiting for those GLSL titles...for all it's superiority....

Well, wait all you want. I'll wait for a clean API. OpenGL is falling in decline because of Microsoft's marketing muscle, so even after OGL2.0 ships, and driver support is available, don't expect a plethora of games. This has less to do with HLSL vs GLSL and more to do with general OGL vs DX developer issues, Microsoft support (Microsoft *refuses* to update the OpenGL32.dll for the new >1.2 bindings), and MS development tools and support push DX.

But I decline to get into a discussion on the merits of the Microsoft monopoly and their attempts to destroy OpenGL over the years.

I'll just note the results of the informal poll above.

 

[Joe DeFuria]

I'll just note the results of the informal poll above.

Of course,you'll note I never disputed that GL was a better programming environment.. I fully expect DEVELOPERS to prefer GL over DX in that respect.

And you'll also note, that I've said over and over, from that, it does NOT directly make GL the better environment for consumers.

 

[DemoCoder]

Neither does DX. Programming environments harm or help consumers indirectly only so far as they produce code faster with fewer bugs at a cheaper cost. For example, languages like Java, C#, PHP, Perl, Python, etc accelerate development and reduce many bugs (buffer overflows, memory leaks, null pointer derefs, etc) and thus are a big benefit to ordinary consumers. This BBS is written in such a language, since writing it in C would likely take longer, be harder to customize and maintain, and be more prone to bugs if not written by an ubercoder. It's an indirect benefit to us.

There are three issues being confused. GL vs DX, and statically linked libraries vs dynamic libraries, plus the problems with using the assembly language as an intermediate format for driver compilers to optimize.

The potential benefits of dynamic linking or holistic compilers is direct to the consumer. It allows consumers to download new drivers which can improve their existing games.

People are always talking about how AA and AF are such a good feature (vs T&L, PS3.0, etc) since you can enable them on older games without the game needing a patch, since the driver can force them on. Driver and hardware changes that provide benefits and that don't require any alterations of games from the ISVs (e.g. work "out of the box") have been seen as a universal good on this BBS by the majority. Of course, letting the driver force these features on causes bugs in some games, but I don't see you advocating this feature to be removed and patches from ISVs being required to activate AA and AF.

The benefits are unrealized as of yet. I assert they are there. I predict that Microsoft will eventually see the light as well.

 

[Rolf N]

Trivia:

1)What programming model do these demos use, and on which hardware/driver combos do they run?

2)What's the matter with Far Cry? Why does it need to be patched for NV40?

3)I've recently heard talks about DX9.0c. Why is this needed?

4)What's PS2.0b, and what's needed to take advantage of it? How does it differ from PS2.x, and why does it exist?

5)What's the point in digging this out?

 

[Evildeus]

2)What's the matter with Far Cry? Why does it need to be patched for NV40?

Actually, Farcry on a NV40:
http://www.hardware.fr/medias/photos_news/00/07/IMG0007645_1.jpg

 

[anaqer]

FFS Evildeus, do something with that picture... link it, shrink it, whatever. Having to H-scroll on 1152 is not my idea of fun. :?

 

[Joe DeFuria]

It's an indirect benefit to us.

Again, never argued the contrary.

I've said from day one that there are pros and cons to each approach.

Of course, letting the driver force these features on causes bugs in some games, but I don't see you advocating this feature to be removed and patches from ISVs being required to activate AA and AF.

I don't advocate the option for the end user to force AA / aniso to be removed. I certainly DO advocate ISVs integrate that stuff directly in their games.

The benefits are unrealized as of yet. I assert they are there. I predict that Microsoft will eventually see the light as well.

And I predict they may "see the light" at some point in the future as well.

That doesn't mean "the light" is the right way to go right now.

ATI eventually saw "the light" and went with a 0.13u process for their high end chips. Doesn't mean nVidia was right at the time (NV30) to go with 0.13u.

 

[Joe DeFuria]

Trivia:

1)What programming model do these demos use, and on which hardware/driver combos do they run?

GLSL. Runs on several ATI drivers with official support. No nVidia drivers have official support AKAIK.

Of course, demos are completely different from commercial games, so not sure of your point.

2)What's the matter with Far Cry? Why does it need to be patched for NV40?

You'll have to ask Croteam. I was not under the impression that NV40 needed a patch to run Far Cry with PS 2.0 support.

3)I've recently heard talks about DX9.0c. Why is this needed?

Why are new GL libraries needed with every GL update?

4)What's PS2.0b, and what's needed to take advantage of it? How does it differ from PS2.x, and why does it exist?

Different compile targets for different hardware, right?

5)What's the point in digging this out?[/quote]

Why not?

 

[Rolf N]

Trivia:

1)What programming model do these demos use, and on which hardware/driver combos do they run?

GLSL. Runs on several ATI drivers with official support. No nVidia drivers have official support AKAIK.

Of course, demos are completely different from commercial games, so not sure of your point.

The point was that there are drivers available that support GLSL, to a degree that allows using this model. Not sure what "official" is supposed to mean. It's not sanctioned by Microsoft, if that's what you're asking for.

2)What's the matter with Far Cry? Why does it need to be patched for NV40?

You'll have to ask Croteam. I was not under the impression that NV40 needed a patch to run Far Cry with PS 2.0 support.

And I was under the impression that there are certain precision issues on NV40 on certain, specular lit bumpy surfaces in certain indoor locations, that stem from the fact that NV40 was unreleased hardware at the time of shipping. NV40 is run on the wrong code path, or so it seems. Hmmm, code paths ...
There's also apparently a patch required for Far Cry that enables using the "PS3.0" capabilities of NV40. It's not really required to enable PS3.0, mind. But if you want that, you need a patch. Oh, and you also need a new runtime. I don't know, but I think requiring a new runtime for using new features is somewhat undesirable. You know, end users prefer a static known good environment. They don't like updating drivers'n'stuff. It spoils their experience

3)I've recently heard talks about DX9.0c. Why is this needed?

Why are new GL libraries needed with every GL update?

I can't answer that question. Noone needs new GL libraries, you just update drivers.

4)What's PS2.0b, and what's needed to take advantage of it? How does it differ from PS2.x, and why does it exist?

Different compile targets for different hardware, right?

So you mean different SDKs (implies different application patch levels) for different hardware?
A shame you didn't pick up the PS2.x red herring ...

5)What's the point in digging this out?

Why not?

Dunno. I find it somewhat disgraceful to do the "Look mommy, I was right, told you so" thing.

This is yours:

So now I'm wondering...a year later...where IS nVidia's official GLSL compiler in any decent form....for any of their chips?

I would have thought a "naive" implemention would be a snap according to some people....

Finished wondering yet? Or will you now just dwell on and redefine "decent" until it fits your purposes?

 

[Joe DeFuria]

The point was that there are drivers available that support GLSL, to a degree that allows using this model.

You mean, the support is so good that nVidia hides it from consumers? (Need to hack the registry to enable it?)

Not sure what "official" is supposed to mean. It's not sanctioned by Microsoft, if that's what you're asking for.

No, I mean that if a consumer downloads the driver, HSLS support is enabled by default.

Finished wondering yet?

Nope. Still wondering where it is.

 

[Rolf N]

The point was that there are drivers available that support GLSL, to a degree that allows using this model.

You mean, the support is so good that nVidia hides it from consumers? (Need to hack the registry to enable it?)

Not sure what "official" is supposed to mean. It's not sanctioned by Microsoft, if that's what you're asking for.

No, I mean that if a consumer downloads the driver, HSLS support is enabled by default.

Finished wondering yet?

Nope. Still wondering where it is.

The 60.72 drivers expose it without registry hacks. Damn, you were right, that's not official. My eternal apologies

 

[Joe DeFuria]

The 60.72 drivers expose it without registry hacks. Damn, you were right, that's not official.

Correct. Who's to say it will be officially supported with publically released drivers?

My eternal apologies

And beyond that, if you do want to start talking about the "quality" of the support:

http://www.beyond3d.com/forum/viewtopic.php?t=11712&highlight=140

And you might know why it's not "official".

 

[Rolf N]

The 60.72 drivers expose it without registry hacks. Damn, you were right, that's not official.

Correct. Who's to say it will be officially supported with publically released drivers?

Meh. Who says NVIDIA official release drivers will support PS3.0?

My eternal apologies

And beyond that, if you do want to start talking about the "quality" of the support:

http://www.beyond3d.com/forum/viewtopic.php?t=11712&highlight=140

And you might know why it's not "official".

NVIDIA did some "embrace and extend" aka deliberate violation of the spec. Have a look here for evidence. Related threads:
one, two and a poll on the OpenGL.org frontpage

 

[Joe DeFuria]

Meh. Who says NVIDIA official release drivers will support PS3.0?

I'm pretty sure they'll support HLSL....

NVIDIA did some "embrace and extend" aka deliberate violation of the spec.

Deliberate violations of the spec are necessarily a good thing? Or only if nVidia cards are the only ones on the planet?

What does that have to do with the 3DLabs parse test program....is that program testing nVidia specific extensions?

 

[Rolf N]

Meh. Who says NVIDIA official release drivers will support PS3.0?

I'm pretty sure they'll support HLSL....

That was a rhetorical question
I'm just as sure they will officially support HLSL as I am sure they'll officially support PS3.0.

NVIDIA did some "embrace and extend" aka deliberate violation of the spec.

Deliberate violations of the spec are necessarily a good thing? Or only if nVidia cards are the only ones on the planet?

What does that have to do with the 3DLabs parse test program....is that program testing nVidia specific extensions?

No, it's not a good thing, it's actually a bad, evilish kind of thing because it destroys cross-vendor consistency.

The GLSL test checks whether a shader should compile and compares that to what happens on the actual implementation (ie the currently installed OpenGL driver). There are some shaders included that should not compile, but do so on NVIDIA's drivers. This is a result of the embrace and extend strategy, and you'll see that most voices that have raised so far are against such practices. It's also a reason why NVIDIA's 60.72 drivers score so miserably on the test. They do not conform to GLSL standards.

All of this is explained in great detail and eloquence in the threads I've linked, so I won't repeat it here.

The crashes are a different matter, of course.

 

[Colourless]

Nvidia's extension to the GLSL spec are enabled by default which allows people to develop non standard code without even knowing they are doing it. This is VERY BAD.

 

[Evildeus]

FFS Evildeus, do something with that picture... link it, shrink it, whatever. Having to H-scroll on 1152 is not my idea of fun. :?

Done

 

[Evildeus]

zeckensack,
I didn't find any hard conclusion in those topics.

BTW on Farcry, it seems also that people don't know how to enable high quality as my SS of NV40 shows.

 

[Joe DeFuria]

Nvidia's extension to the GLSL spec are enabled by default which allows people to develop non standard code without even knowing they are doing it. This is VERY BAD.

Agreed....

Is something like this (extending) possible with HLSL? I am under the impression (due to MS front end compiler) that it isn't. And I could've sworn I made arguments about stability across platforms being one particular "pro" for the DX approach...which is lost on GLSL due to the inhernet flexibility of drivers compiling striaght from the shader language...

 

[Humus]

What's the point of bringing this thread up again? Didn't care to read through all the new posts, but it seems like we could just have copy'n'pasted a few old pages to get the same result.

Not sure what point you're trying to prove. It seems obvious to me that I was right. On the DX side we're getting, as predicted, a separate shader specification for every card out there. One for GF3, one for GF4, one for R8500, one for R9700, one for GFFX, one for NV40, one for R420. And all cards have to support all models, even those created to match the competitor's hardware. On the GL side we have stable GLSL support from ATi and nVidia. So far, to my knowledge, nVidia's GLSL support works for all my demos. Don't know the quality of 3dlabs's compiler, but I'm sure it's fine too.