DeanoC's comments about SM3.0

[GraphixViolence]

Dean,

I found your recent comments on SM3.0 in your forum concerning. You seem to indicate that investing time and money to develop SM3.0 shader technology is beneficial, while doing so for SM2.0b is not. Your rationale is that eventually all new hardware will support SM3.0, so there is no benefit in supporting subsets of that model. This seems to me to be a flawed line of reasoning.

One feature of the DirectX shader models is that higher numbered versions always have to support a superset of the features in lower numbered versions. In other words, any hardware that supports SM3.0 must also be able to support SM2.0b, 2.0a, 1.4, 1.3, etc. So it should follow that for a given graphical technique you wish to implement, you will be best off if you implement it using the lowest possible shader model that will work, since this guarantees the widest number of users will be able to take advantage of it.

There are parallels here to Nvidia's promotion of partial precision hints. Their argument has been that you should use them wherever possible because, even though they benefit only Nvidia hardware, they won't have any negative effect on other DX9-compatible hardware that doesn't support them. Similarly, if a given technique can be made to run well using SM2.0b, then why not do so rather than restricting it exclusively to SM3.0 hardware? It's not like the SM2.0b code would just get thrown away when future hardware comes along, and in the meantime it should run fine on both NV & ATI hardware, while an equivalent SM3.0 path will only run fine on the former.

Before you say that SM3.0 is clearly superior to SM2.0b and such a situation would never happen, let's look at what's happened so far. We've seen one development group (Crytek) that's actually gone down the path of implementing SM3.0 and patching support into a shipping game. Their analysis showed that compared to SM2.0, they could realize performance improvements by taking advantage of geometry instancing and flow control to handle multiple per-pixel lights in a single pass. Later they realized that both of these techniques could be implemented equally well using SM2.0b. They wanted to use dynamic branching, but performance problems with existing SM3.0 hardware (i.e. NV40) made this less useful than it seemed at first.

There are indications that other novel features of the NV40 have similar issues. Vertex texture fetch is said to be slow, and FP blending apparently carries a significant performance cost as well, besides being incompatible with anti-aliasing. Future hardware might overcome these limitations, but it seems foolish to develop an engine that counts on this happening without first exhausting all the possibilities of today's hardware.

So I think people have a perfectly valid point when they associate games with SM3.0 support today as being pro-Nvidia. In another thread you stated that you would never intentionally slow a game down on one IHV's hardware regardless of publishing/PR deals for any reason, and you believed pretty much all other developers would do the same. But if you implemented performance enhancements into your game using SM3.0 and:

a) They could also be implemented on SM2.0b hardware
b) They would provide a comparable performance improvement on SM2.0b hardware,
c) The SM2.0b implementation would still run and enhance performance on SM3.0 hardware, and
d) You didn't use SM2.0b to implement them because an IHV paid you to support SM3.0...

... then I'd say you've pretty much done what you said you wouldn't do. Yet if Crytek had taken your advice and not bothered with SM2.0b in their recent patch, they would have done exactly what I just described. And that, in my opinion, would have set a very negative precedent.

 

[DeanoC]

One feature of the DirectX shader models is that higher numbered versions always have to support a superset of the features in lower numbered versions. In other words, any hardware that supports SM3.0 must also be able to support SM2.0b, 2.0a, 1.4, 1.3, etc. So it should follow that for a given graphical technique you wish to implement, you will be best off if you implement it using the lowest possible shader model that will work, since this guarantees the widest number of users will be able to take advantage of it.

Absolutely always implement any shader for the products release in the lowest shader model you can.
Make sure any release title works on all systems as well as time/money and system allow.


But a patch isn't a product release, its a freebie. Unfortantely PC gamers have forget how much it costs for each patch and that its a requirement, that it should be the same standard as the actual release. Partly the PC games developers fault for having so many bugs but its costs REAL money to develop a patch.
Thats time and money that could be spend writing a new engine and game.

So lets say I know what next-gen consoles and PC cards two years for now we be like. I can either spend my resources working towards that or I can spend my resources supporting extra features for extra cards and combination for a patch that will earn my company nothing except some good will.

Now because NV40 allows both to happen at the same time, thats a bad thing? Because I can do some research and give a little back to the community who have already bought my last game?
You bought a SM2.0 game, the fact that the patch makes it a little better for SM3.0 system is a BONUS not something you can shout shenanigans on.

There are parallels here to Nvidia's promotion of partial precision hints. Their argument has been that you should use them wherever possible because, even though they benefit only Nvidia hardware, they won't have any negative effect on other DX9-compatible hardware that doesn't support them. Similarly, if a given technique can be made to run well using SM2.0b, then why not do so rather than restricting it exclusively to SM3.0 hardware? It's not like the SM2.0b code would just get thrown away when future hardware comes along, and in the meantime it should run fine on both NV & ATI hardware, while an equivalent SM3.0 path will only run fine on the former.

I've made PC games (but not at the moment), you can only chose a limited number of configurations to support well. At the moment thats
SM1.1 : Legacy support going back to GF3
SM2.0 : Main stream supported most ATI and NVIDIA cards (Lets leave the GFFX arguements out of it)
SM3.0 : Next generation support

If there are a few things I can back port from PS3.0 to PS2.0b sure why not? But there will be a delay because I'd develop PS3.0 first and then back port. Say the delay between patch 1.2 and 1.3...

"]
Before you say that SM3.0 is clearly superior to SM2.0b and such a situation would never happen, let's look at what's happened so far. We've seen one development group (Crytek) that's actually gone down the path of implementing SM3.0 and patching support into a shipping game. Their analysis showed that compared to SM2.0, they could realize performance improvements by taking advantage of geometry instancing and flow control to handle multiple per-pixel lights in a single pass. Later they realized that both of these techniques could be implemented equally well using SM2.0b. They wanted to use dynamic branching, but performance problems with existing SM3.0 hardware (i.e. NV40) made this less useful than it seemed at first.

SM2.0b included no geometry instancing. The hack ATI have managed is an excellent idea (geometry instancing is an excellent feature) and as the hack will be supported right back to SM2.0 devices (R3x00) its clearly worth implementing.
The dynamic branching speed wasn't the problem on SM3.0, the lack of indexed constants in a pixel shader was. Also the extensive use of stencil shadows in there engine, things that only get found out with RESEARCH. Thats what your getting when a patch with SM3.0 is released. Some attempts at figuring out what the high end in 2-3 years time will be like.

The lack of index constants is a problem... Which makes PS3.0 much less useful than it should be but that mean more research to figure ways around it (textures as constants etc.)

There are indications that other novel features of the NV40 have similar issues. Vertex texture fetch is said to be slow, and FP blending apparently carries a significant performance cost as well, besides being incompatible with anti-aliasing. Future hardware might overcome these limitations, but it seems foolish to develop an engine that counts on this happening without first exhausting all the possibilities of today's hardware.

Why is it foolish to rely on fast vertex texture fetch? In fact (close to breaking NDA) rely on fast vertex texture fetch, ignore NV40 crappy implementation of it. Its a blip that will quickly be forgotten about.


FP Blending don't rely on its got nothing to do with SM3.0.

Do you get the feeling I might know something you don't?

So I think people have a perfectly valid point when they associate games with SM3.0 support today as being pro-Nvidia. In another thread you stated that you would never intentionally slow a game down on one IHV's hardware regardless of publishing/PR deals for any reason, and you believed pretty much all other developers would do the same. But if you implemented performance enhancements into your game using SM3.0 and:

a) They could also be implemented on SM2.0b hardware
b) They would provide a comparable performance improvement on SM2.0b hardware,
c) The SM2.0b implementation would still run and enhance performance on SM3.0 hardware, and
d) You didn't use SM2.0b to implement them because an IHV paid you to support SM3.0...

... then I'd say you've pretty much done what you said you wouldn't do. Yet if Crytek had taken your advice and not bothered with SM2.0b in their recent patch, they would have done exactly what I just described. And that, in my opinion, would have set a very negative precedent.

Crytek didn't release FarCry supporting NV40, they patched it, free to the customers. Say thank you rather than bitching.


I think the thing your missing is the difference between a patch and the actual games release. I'm 100% with you, that any game release should support all cards to the best extent possible. But what your saying is that if I do some research that could benefit only some customers I shouldn't release it because of 'fairness'.

Prehaps if we change vendor you will see my point better. I'd claim that supporting 3DC/DXN normal compression is a good thing, its a good future proof technique that my next engine will definately use. I'd do the research, write the compressor, get the art updated as this is a technique that going into the next DX standard (I think...). I'd happily release a patch so that ATI owners get the benefit of the research. But what about NVIDIA? In theory I could modify the compressor to do DXT5 version (slightly lower quality but still better than no normal compression), I'm I going to get scheduled time for that? My publisher/boss would say I've used my normal map compression research time and now I'm on a completely unrelated area so no I can't have time.
I'd personally probably do it on my own time and try and convince them that another patch for non ATI owners would be worth it from 'good will' but the cost of regression testing may make it so even it the code is written that we couldn't get an official patch release.

Look at the problems Crytek have had with the SM3.0 patch, its already been pulled due to issues on some cards.

People are so sure that its all a big conspiracy, whereas in actual fact it may not be. The future is SM3.0, by that fact alone there will plenty of SM3.0 patches, just as there will be plenty of 3DC support because thats is also the future.

I've given my honest opnion, I'm not biased (I think, I've slagged NVIDIA off in public over NV30...) or paid off by NVIDIA. I'm not even working on a PC title at the moment. Hopefully I've shown the arguement isn't as simple as "Patch supports NV40 therefore developers are paid NVIDIA bitches", its just not that simple in the real world of budgets, etc.

Edit: Minor stuff

 

[digitalwanderer]

Thanks for taking the time to explain your thoughts on it Deano, it is appreciated. It's interesting to me as you strike me as a straight-shooter who actually uses this stuff so your perspective is very valuable to me.

Thanks.

 

[nelg]

Hopefully I've explained myself better this time. Reading the post I originally made back, it wasn't exactly what I won't to say but it is at the same time. The header sums its up really.

Reading between the lines of your posts, it seems that ATI is skipping SM3.0 altogether. So, regardless of the Graphic Violence’s concerns about the quality of Nvidia’s implementation of SM3.0 and how its use now will benefit those who purchase SM3.0 capable hardware from another IHV, you seem to be suggesting that, since there will be no SM3.0 hardware from ATI, this work will not be in vain. I think you may have spilled to many beans here.

 

[Joe DeFuria]

Anybody who thinks SM3.0 is a NVIDIA only thing, is wrong. Your just have to trust me on that for the moment."

I'm not sure anyone is saying or thinking that.

From my perspective, it's "if you can get 95% of real-world SM 3.0 benefits by using the SM 2b (that is available on more more hardware)...why push 3.0?"

If there is more hardware coming that supports 3.0...they will also support 2.0b correct?

 

[Reverend]

Can opens, worms come out. Be prepared Dean!

I think it's a matter of priorities for different developers, that's all. A big part of the decision making (to support 3.0 or not, to exclude 2.0 or not, etc, within the engine) has got to do with the next gen consoles (maybe in particular the next XBOX).

 

[nelg]

Can opens, worms come out. Be prepared Dean!

Yes all we need now is an ETA

 

[LeStoffer]

From my perspective, it's "if you can get 95% of real-world SM 3.0 benefits by using the SM 2b (that is available on more more hardware)...why push 3.0?"

Well, I think I'm with Deano C. on this one. If game developers only learned and coded for features that was already widespread on the cards in use, I'm not sure we would see much shader implementation in games coming out even now. Maybe PS 1.1 though?

You have the put the features you want to see in games i two years time in the hands of developers today. And it wont be feasible for any IHV to implement these features today if isn't done on a chip made for a fairly broad market. On top of this simple fact, Deano C adds that developers wont be allowed to spend time to learn these new features for no apparent reason or because they 'just would like to play with it'. Please re-read his part about the research in the problems with SM 3.0.

Over all I just disagree with the idea that you should only buy a new card if all of its new features can be used right away. I have said before, so here goes again: somebody have to invest for progress to happen.

 

[LeStoffer]

Anybody who thinks SM3.0 is a NVIDIA only thing, is wrong. Your just have to trust me on that for the moment."

Just to add a bit: ATI have already published papers about SM 3.0. Like the infamous Save the Nanosecond, where this semi-secret note got from:

Blend etc will be on NV40 and on our own SM3.0 parts

I suspect that the Xbox 2 chip will be very close to that part.

Edit: Changed focus.

 

[digitalwanderer]

Well I heard it's going to be supported in DX9.1 which teamDX is putting out soon.....

 

[Reverend]

Let's stop bugging Dean by trying to squeeze NDA info out of him and instead ask him more about the decisions behind the business of making games, which is what this is about.

 

[Joe DeFuria]

Well, I think I'm with Deano C. on this one. If game developers only learned and coded for features that was already widespread on the cards in use, I'm not sure we would see much shader implementation in games coming out even now. Maybe PS 1.1 though?

I do want to make myself clear.

I certainly do not fault (and in fact applaud) companies coming out with more feature support, such as SM 3.0.

That being said, I thought we were talking about the practical applications here. In this case, there are lots of things to weigh against each other, including installed base, development time, what "return" (in terms of pwerformance and/or quality) you get from implementing new features, etc.

Again, based on Far Cry (which of course is a limited data point), I don't see that much in the way of a practical return on implementing SM 3.0 vs. SM 2.0b. On the other hand, there does seem to be a significant return based on either of these models over standard SM 2.0.

So, the choice to me seems to be from a developer perspective

1) Implement SM 3.0 only
2) Implement SM 2.0b only
3) Implement both.

There are going to be pros and cons to each approach. Number 1 will probably be the least costly, but reach the smallest number of users.

Number 3 will be the most costly, and reach the most users.

Seems to me that Number 2 will reach the same number of users as number 1, (SM 3.0 cards much support SM 2.0b) with a cost that's in between 1 and 3.

Which is the "best" approach? Probably, it depends on the specific application.

 

[Evildeus]

Wouldn't the best approach be implement SM2.0, 3.0 and others if cost effective?

 

[GraphixViolence]

Dean,

Thanks for your reply. I don't think you addressed my main point though, which was that releasing a patch that implements improvements only on SM3.0 hardware doesn't make sense if the same benefits could be achieved using a lower shader model. If you absolutely need SM3.0 to do something then by all means, use it. But using it just because it's there, because it sounds cool, or worse because you have financial incentive from one IHV to do so, just seems like a bad idea.

It seems like one positive effect the introduction of SM3.0 hardware is having is that it's encouraging developers to think about solving graphics problems in innovative ways. For example, consider Humus' stencil pass technique for emulating the benefits of "early out" on hardware that doesn't support dynamic branching. Back in 2002 when the Radeon 9700 Pro launched this optimization was already possible, yet it wasn't really explored until now because SM3.0 got people thinking about new ways to optimize their lighting algorithms. It would be terribly unfortunate if all the millions of current owners of SM2.0 hardware, not to mention the millions more who will join this club in the coming months, ended up being unable to take advantage of things like this because developers start becoming fixated on SM3.0 before first fully exploring what they can do with earlier models.

I understand the time constraints that developers are under, but I think the problem is that developers like yourself are focusing more on supporting a particular shader model than on solving a particular problem. The shader model is just the tool set, and although the fancy 200-piece toolbox might look sexy and desirable, the simple 50-piece set might really be all you need. Either way, just by working to understand the problem and its solution, you're still doing valuable research that will lead to a beneficial result for you, your company, and your customers.

I think these observations hold true regardless of whatever you know or don't know about upcoming hardware. Granted, if you're working exclusively in the console space and have no plans for a PC port, your situation would be different because you won't have to worry about install bases at all. But I think cross-platform development is becoming more the standard these days, which makes it hard to ignore all those PC customers running less-than-cutting edge graphics hardware.

 

[LeStoffer]

Wouldn't the best approach be implement SM2.0, 3.0 and others if cost effective?

I would prefer this approach. Developers already has to code for non-shader hardware, PS 1.1, SM 2.0 and now SM 3.0. On top of this they have to spend a lot of time to get good performance on NV3x, so 2.a and 2.b would probably distract to much.

I'm a bit of a purist so I would have preferred that we never saw 2.a with NV3x (and just pure SM 2.0) like I would have preferred SM 3.0 on R420 and no 2.b. But that is just me.

 

[DeanoC]

Dean,

Thanks for your reply. I don't think you addressed my main point though, which was that releasing a patch that implements improvements only on SM3.0 hardware doesn't make sense if the same benefits could be achieved using a lower shader model. If you absolutely need SM3.0 to do something then by all means, use it. But using it just because it's there, because it sounds cool, or worse because you have financial incentive from one IHV to do so, just seems like a bad idea.

Fair enough, can't exactly disagree. HLSL have made it fairly easy to retro fit a SM3.0 shader that fits into SM2.0B (and 2.0A for that matter). There aren't any real technical issues why you won't do it but there are other reasons. Haveing another path (the same shader in 2.0B and 3.0 do produce different code so you would want multiple code paths) does increase the test matrix, this is a big thing in the PC space. Most publisher will support only a finite number of code paths for graphics cards (so they can do extensive testing on just those).

I understand the time constraints that developers are under, but I think the problem is that developers like yourself are focusing more on supporting a particular shader model than on solving a particular problem. The shader model is just the tool set, and although the fancy 200-piece toolbox might look sexy and desirable, the simple 50-piece set might really be all you need. Either way, just by working to understand the problem and its solution, you're still doing valuable research that will lead to a beneficial result for you, your company, and your customers.

I'm not working towards a shader model itself but to the programming model implied by it. Often you have to spend longer with you 50 peice set than the 200 peice set, making a tool do a job it wasn't designed for. The analogy holds for SM2.0B and SM3.0, its usually easier to work on a problem in SM3.0 and it will usually take more time to make it work on SM2.0B.
Now of course this isn't true if the tool does the job (i.e. the SM3.0 can run on SM2.0B cards without any major changes) and as I mentioned above there isn't really a good technical reason why you only choose SM3.0 in this situation.

I think these observations hold true regardless of whatever you know or don't know about upcoming hardware. Granted, if you're working exclusively in the console space and have no plans for a PC port, your situation would be different because you won't have to worry about install bases at all. But I think cross-platform development is becoming more the standard these days, which makes it hard to ignore all those PC customers running less-than-cutting edge graphics hardware.

Even in the PC space there are only a finite number of hardware configurations publishers will support. I just don't see enough of a market for SM2.0B specific pipes. In the same way nobody is really support SM2.0A thats just isn't a compelling advantage.

Hopefully PC devs will decide differently for R4x0 owners but I'm not hopeful. I personally expect the code paths in PC game for the next couple of years to be SM1.1, SM2.0 and SM3.0 and no others.

 

[DeanoC]

Let's stop bugging Dean by trying to squeeze NDA info out of him and instead ask him more about the decisions behind the business of making games, which is what this is about.

There is 3 letters in the first post that probably shouldn't be there

Business wise, the next-gen engines/consoles are dominating all decisions at the moment. The PC market isn't really big enough to support many PC only titles, which leaves the console market a real important sector.

Given it takes 2-3 years to write an engine, its obvious that PC are going to be test beds for next-gen consoles. Except for maybe the nice Mr Carmack, I expect every high-end PC title is just a test bed for the consoles.

Currently shaders have just been for implementing light models, this is something that fairly scalable with shader version. You can easily drop in a better/worse light model to work around shader limitations. Those times are over, from now on shaders will become a fundemental part of the rendering pipeline. Water, sky, foliage, HDR, compression, AI and physics, maybe even geometry itself will become intertwained with shader model. This makes it vital to select the shader model that will see the most use, content costs are stupidly high, and procedural stuff will start to be used to reduce this.

I suspect most games targetting 2-3 years are aiming at the next-gen consoles capability and if there doing a PC version, they won't have resources to redo content to cope with the lower cards. If there is place for a viable PC gaming solution, its going to have to be fairly cheap to develop on. Only a few titles make money on PC, even fewer of these are highend stuff. I won't be surprised that the business model behind multiple shader models will die away, it makes no sense for ATI or NVIDIA to implement a new shader model if the developers can't afford to use it profitable.

One thing I expect this to do though is PC dev to maybe shift to GLSL a bit to help get rid of these problems. GLSL does a much better job of hiding the hardware restrictions from the developer. I also expect DX10 (or Windows Graphics Foundation as its to come) to do a similar thing and remove the whole shader model thing. In hindsight it was a mistake and the GLSL model was the right one.
I have to admit to getting that one wrong. I wasn't a fan of the GLSL model to start with thinking the shader models wouldn't be a problem but considering we have effectively had 11 in about 3 years, its clearly been a bad idea!

I'm hopefully GLSL and to certain extend proper use of D3DX auto shader model selection will remove this problem. In theory I shouldn't care what shader model that card supports, just wether is can compile and use the shader I provide.

Unless Doom3 see a massive and long term growth in PC gaming, then the business of consoles will have far more effect on the PC gamer than any neat cards that appear. Currenly supporting clever shader models has been a complete waste of money for both IHV's and consumer.
The business model doesn't work, you can't rely on the developers to implement new features cause there cool. I had this exact problem with Silent Hill 2 PC, it supports no features higher than SM1.1, the reason isn't bias but simple economics the game was designed for PS2 and XBox and we didn't have the budget to do anything that could use the newer shader models. The best we could do was make sure it ran really well on decent cards (1600x1200 was the only way to play that game ;-) )

The full enumerated list of DX shader model would be PS1.1,PS1.2,PS1.3,PS1.4,PS2.0,PS2.0A, PS2.0B, PS3.0,VS1.1, VS2.0, VS3.0. Even with this lot there are probably a few missing...

Of course this is just my humble opnion, I'm just a programmer with obviously my own biases, interests etc. I could very easily be wrong (wouldn't be the first time )

 

[LeStoffer]

Except for maybe the nice Mr Carmack, I expect every high-end PC title is just a test bed for the consoles.

I didn't know PC games was such a poor business nowadays?

 

[Reverend]

Except for maybe the nice Mr Carmack, I expect every high-end PC title is just a test bed for the consoles.

I didn't know PC games was such a poor business nowadays?

It just takes far more resources (time, effort, staff, money) than the consoles. With consoles, you don't really have to worry about stuff like compatibility, patches, etc. all of which consumes such resources (Dean touched on this above).

[edit/addition]Dany Lepage had told me that the engine behind the next Splinter Cell has been designed with the next-gen consoles in mind. Tim Sweeney has said pretty much the same thing. Console games are more profitable than PC games, simple as that. Devs just need to make certain decisions that ensure their game engines are good for both platforms. Surely this is obvious.

 

[ERP]

Except for maybe the nice Mr Carmack, I expect every high-end PC title is just a test bed for the consoles.

I didn't know PC games was such a poor business nowadays?

PC game sales have been in a slow decline for several years, and it doesn't show any signs of the trend reversing.

:/