Which API is better?

[KimB]

No I'm not.
I speculate that I have to install a specific driver on a specific hardware and test a specific shader to find out if it exceeds limitations or not.
There doesn't have to be driver bugs for this scenario to happen.

No, because it's guaranteed to work. If it doesn't, the driver is buggy. ATI already has experience with multipass, and it will take a monster of a shader to force multipass on nVidia hardware, so this shouldn't be an issue.

So if you have an architecture that can't support branching you can have branches removed in the HLSL or you can remove them in your own compiler.
You have to remove it anyway.
If that's easier for you, than define "easy".

All PS shader hardware supports conditional writes. So, all PS hardware can emulate branching by executing all available paths. Branching can also be emulated through multipass if necessary.

PS 3.0, 4.0, etc. will be low-level assembly languages. Just like PS 2.0, they will work best with one single hardware architecture. Anything very different will have problems.

No they will fit as good as the IHV is willing to cooperate on defining those languages.

And this is the problem! I don't want IHV's to have to have simplified instruction sets that make for a nice assembly language. I want to see advanced instruction sets that are designed to be compiled to directly from a high-level language.

 

[Humus]

So its acceptable that its very easy to produce something that when run in the field runs like a slide show on some unknown percenatge of HW?

Yes. This has always been the philosophy in OpenGL. It's guaranteed to work, but there's no guarantees about performance or whether it's run in hardware or not (which is actually irrelevant, it's performance that matters (which though it clearly affected by rendering in hardware)).

While in theory it may seem this will cause problems it has worked just fine in real world apps so far. In fact, this philosophy in practice simplifies things for developers since you get more guaranteed functionality behind every extension string exposed (as opposed to DX caps hell), and better design of the API if you can forget about some obscure hardware limitations.

 

[Humus]

No I'm not.
I speculate that I have to install a specific driver on a specific hardware and test a specific shader to find out if it exceeds limitations or not.
There doesn't have to be driver bugs for this scenario to happen.

Every kind of resource that's hard or impossible to count, such as instructions, temporaries etc. is effectively infinite. If the shader is correct, then it will compile and work, though possibly in software or by automatic multipass or any other solution.

No they will fit as good as the IHV is willing to cooperate on defining those languages.

Another problem with all those assembly language is that new hardware, even if you support everything new and shiny, ps3.0 and what not, will still not be able to use that functionality or adjust the shader to the less limited model since they will still be fed with lower versions of assembly shaders in old apps.

 

[DemoCoder]

That means some structures amenable to HW optimization may be obscured by the morphed graph.

I doubt it is all that likely. with register allocation already being deferred to the driver I doubt they will do much optimization at this stage. It is not like microsoft are out to purposely piss off IHVs, which also of course only have to deal with the single compiler of which they know exactly what it does.

Not true. MS's compiler does a host of transformations: CSE, copy-prop, block reorder, inlining, macro expansion. CSE was one factor in NV30 performance. MS's compiler also does things like replace branches with CMPs, which are a performance killer on the NV30.


It doesn't matter that the IHVs "know" what MS's compiler does. Remember, their drivers have to deal with shaders that come from both MS's compiler and from human beings that write them by hand.

 

[Rolf N]

Hyp-X,
would you please read the thread, or at least the last three or four pages before barging in? Everything you've brought up in your spray of wisdom has been extensively discussed already.

 

[JohnH]

So its acceptable that its very easy to produce something that when run in the field runs like a slide show on some unknown percenatge of HW?

Yes. This has always been the philosophy in OpenGL. It's guaranteed to work, but there's no guarantees about performance or whether it's run in hardware or not (which is actually irrelevant, it's performance that matters (which though it clearly affected by rendering in hardware)).

While in theory it may seem this will cause problems it has worked just fine in real world apps so far. In fact, this philosophy in practice simplifies things for developers since you get more guaranteed functionality behind every extension string exposed (as opposed to DX caps hell), and better design of the API if you can forget about some obscure hardware limitations.

We're talking a large step in complexity vs what traditionaly failed over to SW, the situtaion just isn't comparable anymore, and I must admit to being confused as to why some can't see this.

I think the best way to resolve this discussion is see who was correct in a couple of years time. Obviousley, as it happens, I know I'm correct or as my Grandfather used to say "I'm always right, and when I'm wrong I'm right!".

Later,
John

 

[JohnH]

I did say I wasn't going to post anymore... but ....arrr...

Chalnoth, I think this is fine if you ignore the fact that GLSL requires you to be able to run _any_ code that is valid to the specification if you expose the extensions.

IHV's have always released documents pertaining to getting good performance on their products. This will be no different. The paths that can't be used on current-generation hardware in realtime just won't get optimized, and docs will be released telling developers what not to do.

I really don't see how this presents a problem.

Its not a matter of them not gettign optimised, its a matter of them either not working at all, or rediculously slowly.

The performance recomendations from IHV's have, for the most part, all been the same. These recommendation will however get much more complex when everyone is messing with very different shader architectures with an arbitrary target like GLSL on top. D3D's profiles help prevent this from being an issue, there is no equivalent, currently, in GLSL.

Stop bating me will you so that I can leave this thread alone

John.

 

[DemoCoder]

. D3D's profiles help prevent this from being an issue, there is no equivalent, currently, in GLSL.

Stop bating me will you so that I can leave this thread alone

John.

Oh really, so since the NV30 and R300 both support PS2.0, you can happily target that profile without caring about stuff running too slowly, despite the fact that in some situations, the NV30 runs 1000% slower than the R300, and in other situations, it has precision problems which severely affect image quality?

You're the one selling us a bill of goods. You say OpenGL doesn't solve a problem which you claim DirectX has (e.g. as a developer, I just think "oh, I target PS2.0 profile, and shader X is guaranteed to run, and at acceptable performance levels), but DirectX didn't solve the problem.

As Valve showed with HL2, ability to "run" PS2.0 doesn't mean jack if performance differs wildly.

In the end, on both DirectX and OGL, you will still have to benchmark and test your game on every platform, and tweak it, e.g. switch off some PS2.0 effects for some cards.

 

[KimB]

I'll expand upon DemoCoder's above post, JohnH.

The result of standardized assembly is that a given program tends to run very well on one architecture, but very poorly on a different architcture.

One of the main benefits of standardizing at a higher level is that performance is more evened-out, as each IHV has as much information as possible to do the proper optimization for their specific architecture.

In other words, GLSlang offers more opportunities for similar performance across different architctures, not less. There will be situations that must be avoided on various hardware, but other than that, GLSlang will be much less restrictive on programmers.

Bait set. Muhahaha.

 

[MfA]

Sorry, was talking about the DX-Next stuff.

 

[JohnH]

Snap. Damn caught....

Oh really, so since the NV30 and R300 both support PS2.0, you can happily target that profile without caring about stuff running too slowly, despite the fact that in some situations, the NV30 runs 1000% slower than the R300, and in other situations, it has precision problems which severely affect image quality?

You're the one selling us a bill of goods. You say OpenGL doesn't solve a problem which you claim DirectX has (e.g. as a developer, I just think "oh, I target PS2.0 profile, and shader X is guaranteed to run, and at acceptable performance levels), but DirectX didn't solve the problem.

As Valve showed with HL2, ability to "run" PS2.0 doesn't mean jack if performance differs wildly.

In the end, on both DirectX and OGL, you will still have to benchmark and test your game on every platform, and tweak it, e.g. switch off some PS2.0 effects for some cards.

I'll expand upon DemoCoder's above post, JohnH.

The result of standardized assembly is that a given program tends to run very well on one architecture, but very poorly on a different architcture.

One of the main benefits of standardizing at a higher level is that performance is more evened-out, as each IHV has as much information as possible to do the proper optimization for their specific architecture.

In other words, GLSlang offers more opportunities for similar performance across different architctures, not less. There will be situations that must be avoided on various hardware, but other than that, GLSlang will be much less restrictive on programmers.

Sorry, but this is wrong. You're obviously using current ATi vs NV issues as an example. This has nothing to do with an inappropriate intermediate format, it has everything to do with broken architectures and an inexplicable inability to include a compiler that works within a driver. Basically there is nothing wrong with the ps2.0 profile, whats wrong is someone trying claim high end perf on a future proof feature set when the reality is something different.

Bait set. Muhahaha.

Meep.

[Edit just pasting DemoCoder's post in as well]

John.

 

[Humus]

No, the problem is the intermediate language. You can't optimize for both architectures with a common profile. Yes, the GFFX hardware is slow too, but that's just another problem. Both vendor's hardware could be faster had they had the opportunity to compile the code themselves, though the difference would probably be larger on the GFFX side.

 

[Humus]

despite the fact that in some situations, the NV30 runs 1000% slower than the R300

Heh, didn't see this at first, but 1000% slower would be interesting ... when R300 runs at 60fps the GFFX runs at -540fps ... guess that should be 0.1x the performance, or 90% slower.

 

[Joe DeFuria]

Both vendor's hardware could be faster had they had the opportunity to compile the code themselves, though the difference would probably be larger on the GFFX side.

But how long (and how much resources) would it take each of them to independently develop a full compiler from scratch?

I agree that ultimately each vendor's hardware could be faster. But I stress again, that "faster" is not the singluar interest of conusmers. Time to market is, as well as consistency / stability.

And no, you'll never convince me that having a more flexibility / leeway with the compiler, does not also inherently have a greater possibility of being inconsistent across revisions or platforms.

 

[KimB]

But how long (and how much resources) would it take each of them to independently develop a full compiler from scratch?

They typically wouldn't have to. I'll use Cg as an example here:

Cg was divided into a couple of sections, basically a front-end (parser) and a back-end (compiler). nVidia kept the back-ends closed, but made the front-end open source. They also produced an example back-end to aid others to begin development.

I would expect a similar thing from GLSlang or Microsoft (if MS finally goes this route...).

 

[Joe DeFuria]

Cg was divided into a couple of sections, basically a front-end (parser) and a back-end (compiler). nVidia kept the back-ends closed, but made the front-end open source.

??

Well then, you have the same problems....if no one has access to the back-end compiler, then they aren't getting as good compilers as they could.

I would expect a similar thing from GLSlang or Microsoft (if MS finally goes this route...).

MS is already going a similar route with profiles. MS isn't opening them up to open source, of course, but obviously, the relevant IHVs work closely with MS to ensure "their profile" is good for their hardware. (Like PS2_X for nVidia.)

 

[DemoCoder]

Both vendor's hardware could be faster had they had the opportunity to compile the code themselves, though the difference would probably be larger on the GFFX side.

But how long (and how much resources) would it take each of them to independently develop a full compiler from scratch?

I agree that ultimately each vendor's hardware could be faster. But I stress again, that "faster" is not the singluar interest of conusmers. Time to market is, as well as consistency / stability.

And I'll stress again that NVidia demonstrated that DirectX9 drivers already need to have full compilers. Their architecture is only partially at fault. Wait till VS3.0/PS3.0 come out, the DX9 optimization issues will be much larger at that time, because architectures that support dynamic branching and procedure calls will be way more complex. I predicted over a year ago that NVidia's problem was they needed a compiler in the device driver while naysayers claimed that "translating and scheduling DX9 assembly is trivial". Let's see if I'm correct in spades when VS/PS3.0+ HW starts rolling out.



Your assumption that DX9 drivers allow you a faster time to market with stability and consistency is just wrong. What you'll get instead is a stupid DX9 driver released first, which has awful perforrmance characteristcs, and then months later, after the compiler is integrated into the DirectX9 driver, a huge performance boost.

How is having a card that is delivered with 90% of its performance crippled and then waiting 1 year for a compiler to be delivered in DX9 "consistent" from a user point of view? Why is it any different than having an OGL ICD with compiler integrated.

Perhaps your point all along is that DX9 allows you to write STUPID DRIVERS that do almost nothing. Well, people could also write STUPID ICD COMPILERs that do almost nothing as well. It's pretty trivial to generate code from a grammar generated AST by using tree rewriting.

But I don't see that as a consistent user experience. Hey, just bought by new Radeon11000, but my first DX9 driver runs shaders slower than the R300. Oops, 3 months later, it's on par. Ooops, another 3 months later and it's 300% better.


Both DirectX9 and OpenGL require compilers to be integrated into the drivers. This is patently clear to me, so I don't get where your supposed benefits arrive. Maybe after the PS3.0 HW starts shipping, we'll revisit this thread, and you'll admit you were wrong.

 

[DemoCoder]

MS is already going a similar route with profiles. MS isn't opening them up to open source, of course, but obviously, the relevant IHVs work closely with MS to ensure "their profile" is good for their hardware. (Like PS2_X for nVidia.)

Irrelevent. MS's compiler is equivalent to the front end part of a compiler. It generates intermediate code that isn't runnable on HW. Most of the work is in the backend, and therefore NVidia STILL had to implement YET ANOTHER COMPILER to RECOMPILE PS_2_X/A code from MS's compiler.

Go read NVidia's unified compiler paper and then tell me that Microsoft's compiler saved them work in the driver.

 

[Joe DeFuria]

And I'll stress again that NVidia demonstrated that DirectX9 drivers already need to have full compilers.

....or that nVidia has demonstrated that their architecture is not particularly suited to the DX9 standard.

The FX series also had major performance problmes with standard GL ARB shader code. Compiling isn't an issue here...it's the specification.

I predicted over a year ago that NVidia's problem was they needed a compiler in the device driver while naysayers claimed that "translating and scheduling DX9 assembly is trivial".

Hmmm...I don't recall anyone saying that translating and scheduling DX9 assembly is trivial.

I predicted a year ago that nVidia's problem is that their hardware essentially requires hand tuning on an application by application basis.

Let's see if I'm correct in spades when VS/PS3.0+ HW starts rolling out.

And we'll also see how long it takes for the competing IHVs to release GLSLang compilers....

Your assumption that DX9 drivers allow you a faster time to market with stability and consistency is just wrong.

Other than the fact that the DX9 model (entire development model) has allowed products to actually ship with HLSL compiler support, whereas it's nowhere to be seen in GL, you mean.

What you'll get instead is a stupid DX9 driver released first, which has awful perforrmance characteristcs,

On all architectures, or just one?

How is having a card that is delivered with 90% of its performance crippled and then waiting 1 year for a compiler to be delivered in DX9 "consistent" from a user point of view? Why is it any different than having an OGL ICD with compiler integrated.

Again, you seem to be talking only about a single vendor here having such performance issues.

And if we remove your exaggeration....about 50% of it's performance was crippled in the worst case, and now with the new profile and nvidia's "new compiler", it's STILL out before GLSLang support...the perofmrnace and stability of which is still just a big question mark.

Perhaps your point all along is that DX9 allows you to write STUPID DRIVERS that do almost nothing.

My, my, DC. Can you converse like a normal person, just this once?

Those ATI'S STUPID DRIVERS seem to be doing QUITE REMARKABLE THINGS on their hardware...almost from day 1. I don't see ATI's shader performance increasing any more out of the ordinary than we ususally see drivers improve performance.

This is patently clear to me, so I don't get where your supposed benefits arrive.

Hint: HLSL and DX9 has been available and supported for quite some time now....GLSL...not.

Maybe after the PS3.0 HW starts shipping, we'll revisit this thread, and you'll admit you were wrong.

Anything's possible. And maybe when PS 3.0 HW starts shipping, and there are drivers that support those profiles almost immediately, and that functionality is still not exposed in GL, perhaps you will admit that you were wrong?

 

[Humus]

I agree that ultimately each vendor's hardware could be faster. But I stress again, that "faster" is not the singluar interest of conusmers. Time to market is, as well as consistency / stability.

You're talking about an industry where 5% advantage over your competitor can be the difference between a sale and no sale. Performance matters a lot. Time to market is important for the hardware, and much less for driver support for various features. Having feature X available in the first driver revision is of course nice, but it's only going to matter to at most 1% of the market, guy's like me. For the rest of the people it's mostly a non-issue since it's not going to show up in any games in a year or two after the chip is released.

And no, you'll never convince me that having a more flexibility / leeway with the compiler, does not also inherently have a greater possibility of being inconsistent across revisions or platforms.

Well, if you're going with that attitude it's probably wasted time to provide arguments, but I firmly believe you're wrong. Adding profile upon profile to the API will cause way more problems. With a HLSL then for each new hardware you need to map that language to the hardware. 1 language to take care of. With new profiles being added the API with every revision, then you will need to be able to map every current and former profiles to your hardware, and write optimizers for each of them. Mapping ps1.4 to the R8500 is very different to mapping ps1.4 to R9700. Instead of one language to take care of you got ps1.1, ps1.2, ps1.3, ps1.4, ps2.0, ps2.0a etc. and that list is just going to increase.