NVIDIA Moves to Monthly Driver Release Schedule

Actually I'm currently using an X800. Not bleeding edge at all. If you're getting geometry errors after a while, it sounds like a cooling issue - do you have a hot case or are you overclocking your card? If you are having real bug releated issues, then would you rather wait a month for the next drivers that might fix your problems, or would you rather wait six months?

Personally I like the monthly release schedule because you can choose to use each version or not as you see fit. Would you have wanted ATI to make you wait four months before getting the chuck patch or the D3 improvements if you'd just bought those games?

I don't see that making more releases is more work if your dev team is working on one branch whilst your testing/release team is taking another frozen and regression tested branch and using that for each release. The window from release and what the devs are currently working on could easily be 1-3 months.

Otherwise you have a situation like Nvidia where you are either waiting the best part of a year for a new driver, or you're mixing and matching various unsupported "leaks" depending what you want to play.


BTW, please don't attribute things to me that I didn't say. I never said you weren't using Catalysts, or that you weren't having any problems with them.

 

I`d prefer having it fixed/improved ASAP, and thats how the driver should be sheduled - get something importent done - release it. And not "Oh wait, stop whatever you are working on and ducttape together a release from this and our previous codebase for this month". I dont care if sometimes there would be 2 releases a week if issues made them necessary. The way it is today is that I can choose from 12 Drivers a Years and nearly all of them feel halfway done.

I havend said those thing cant run in parralell. But given a fixed manpower, each release takes time for branching, fixing, backporting, etc. Same with testing - spend time on 1 release or the same time on 4 releases.

Regular releases dont help 1 bit if I cant use them right? Because thats what happened eg. for 6.7 - 6.11. if 6.12 shows problems I can try reverting to 6.7 or hope ATI releases another driver that will work for me. I can assure you tough that 7.1 aint existing for me and I dont know how long I have to wait for it. Its an issue of Quality, not Quantity.

That wasnt directed to you, shoulve used a quote, sorry

 

A release cycle a month. How hiddeous from a software engineering standpoint. You spend so much time releasing, you have no time to implement.

 

Yes, as shown by the way ATI Catalysts have not been able to implement anything over the last five years.

People like Mozilla that issue nightly builds must actually be removing functionality from their products every month!

 

OK, happy to stand corrected on that one--it's just that I haven't used a nVidia 3d-card for so long that all I can remember is the period when nVidia wasn't talking about its bug fixes and and unresolved bugs, but ATi was. That's the period that saw people writing the "nVidia drivers don't have bugs" posts... Glad to see that nVidia itself has now stepped up to the plate to set things straight.

 

It seems to me that that's when you hire more people...

Really, what good does it do you to "implement" if you cannot (a) expose your current hardware capabilities in your drivers, and (b) fix your current slew of bugs...? If you want to witness the folly of that, just look at the old ATi driver program that existed prior to the Catalyst program. Heh... Ati drivers way back then had I think a justifiable reputation for being awful because they spent so much time "implementing" buggy feature support and almost no time fixing those bugs...

 

What I meant there is that sometimes developers "optimize" for one architecture over another to the extent that their games/engines don't operate as expected on the other guy's hardware. A classic example of that was the original NWN with its "shiny water" effect. In the beginning, Bioware itself said that ATi hardware was just incapable of supporting the effect--which was later corrected and amended when Bioware, with ATi's help, discovered how to support the effect on ATi hardware through the NWN engine, and the game was accordingly patched--as were ATi's drivers.

But, I'm not pointing fingers here at all. Years ago, developers were so used to supporting the dominant hardware standards that to them it seemed that there was only "one way" to support something--the way that the dominant IHV supported it. Back when 3dfx was dominant, many developers were only capable of GLIDE support, etc. Developers have grown with the industry, as indeed have we all.

It just seems to me that with 3d games coming out monthly these days, and the market for them being enormously larger than it was nearly a decade ago, that a monthly driver update release schedule makes a great deal of common sense--if, that is, your goal as an IHV is to please your customers and to keep them coming back for more. On such things are reputations won and lost, imo.

 

Hardee har har.

It depends on your team (and the size of it), of course, but in general, its hard to release something with new features, and productized completely, on a monthly basis.

If its staged right (i.e. new features every 6 months, and point releases every month), then its not bad. I've just seen it turn into a mess as new features that get added each month end up destroying stability, and you never get a chance to get the stability set.

 

I have seen it work, but basically you need a dev team to do development, and another one to do bugfixing and release stabilization, with regression testing thrown in there too, with it all being fed back into both the dev and release branches. I'm sure a lot depends on your development methodology too.

Still, ATI have managed it spectacularly well for quite an extended period of time. They've rarely put a foot wrong as far as my experiences with Catalysts are concerned and they've rarely released a dud driver. It would be interesting to know what their release schedule and methodology is for doing this.

 

I have to disagree wholeheartedly with that approach.

It means your implementers get to make whatever shite they want and not have to deal with fixing it. I fully believe in the the "whomever dealt it, smells it" paradigm (i.e. code ownership).

It also fails because "good" programmers don't want to clean up other's messes, so your mess cleaners end up being your lesser programmers, and they generally make things worse trying to meet the release schedule.

 

Yup, but some companies seem to manage to somehow...why is that?

 

And their job satisfaction is in the toilet, so they don't stick around long enough to become good programmers.

 

Ahh, this is quite funny, but so very true. However, the problem is that many programmers are basically prima donnas, who write their code and then get all offended when you criticise it, and the last thing they want to have to do is have to go back and fix the broken code they should have got right in the first place.

So what an old company I worked for did was this: The dev team was the bunch of prima donnas writing interesting new stuff and doing true software engineering development. Then, under the one programmer that believed that code that worked and was tested was a "good thing", they brought in a load of cheap but good coders in from India. This release team fixed all the bugs both before release (in concert with the testing team), and any customer reported bug. Basically there was a dev team that made the mess, and a maintenence/release team that picked up all the mess.

 

Finally a topic on which I can speak from a little knowledge! So I can break my cover as a long term lurker.

This kind of release cycle is an effect of a more agile development process. I'd guess that it would go something like:

• Week 0 - Draw up a list of content for the next cycle - including bugs to be fixed and new features. Prioritise the content.
• Week 1 - Start design and development of the content list- writing tests as you go.
• Week 2 - continue.
• Week 3 - decide what content can be completed by end of week - shelve what you can't for next cycle.
• Week 4 - create release candidates, test, fix. Do Week 0 activity.
• Release new version, repeat from Week 1.

This will need to be backed up with automated builds (preferably continuous - more likely nightly) and automated regression tests.

The development team may have a long term 'major feature' branch going on in the background. A few development team members will be focussed on this at a time.

I've worked in this kind of environment before (not graphics software) and it can be extremely effective.

 

Has Nvidia gone to monthly updates yet?

 

Yes absolutely, one in November 2006.

 

I heard their next monthly release will be in May...

 

The monthly updates applies only to Vista. And since they're spending all their time on the monthly Vista drivers, those of us still using XP will be lucky to get an updated driver once a year.

 

It seems to me the whole monthly update is more PR than anything. In this case it clearly is. They did it for PR reasons.

Yes it would be nice if they fixed bugs, but just releasing something every given period doesn't make me excited. I have not felt in any way more loved by ATI since the 9500 I bought years ago when they were new. I have owned a decent ATI card ever since and no I haven't been particularly impressed in any way. They work, they have bugs, they seem adequate for my needs and have been less expensive to purchase for the performance.