Reaction to inherited driver errors?

[euan]

I read somewhere that "the market leader" has several serious errors in their drivers that they cannot rectify because of the number of games, and applications it would effect.

How do competitors to "the market leader" react to such application anomalies that are then inheriently built into applications? Does one have to follow suit, and break ones own drivers, or does one do it right? Then how does one explain why an application works on a competitors card/drivers, and not ones own?

Is some sort of application database created to track broken applications, or is it just a case of taking the hit?

ps I'm pretty sure this is the right forum for this question.

 

[Jeff Royle]

This question refers to a partial role of the Developer Relations team actually. As I'm part of this group I have a certain knowledge of how we handle many of these cases.

There are a high number of games that were developed on non-ATI boards which means any driver bugs they have may be worked around in code. If the game is not tested on ATI boards before release and these bugs found, the game goes gold and ships that way. When the bug is eventually found and determined to be a game bug, we contact the developers of the game and let them know. We can then request a patch if they are willing and even offer advice on how to fix it. ATI will not knowingly break a driver to make a game work.

In rare cases, developers will not create a patch and then we can only take note of the title and try to remember the bug for future reference. The state of the development community seems to be shifting for the better these days and many bugs are hammered out well in advance of shipping, some later on. We do our best to get all titles tested and bugs found.

The biggest problem we encounter is that end users don't always realize it's not a driver issue that causes the problems. When the game is written as above, on different graphics hardware and bugs are just accepted and worked around in code then it's hard for us to say "But the problem is in the game" because end users see it works for other people on different graphics hardware. ATI already has a bad rap for drivers and yet we won't intentionally leave a bug in a driver. Competitors occasionally will leave a known bug in the driver maybe because they are afraid of what everyone will think when they actually fix it.

Recently I've seen a trend where developers let us know of bugs in the competitor drivers which acts as a heads up for us. Then when other developers come across a problem we can offer the advice that it may not be a bug on our side.

This has gotten too long winded and poorly worded I'm sure so that's it for now.

Jeff

 

[Humus]

One example of this that was discussed heavily on opengl.org for some time ago is that NVidia's drivers have an inherited bug that will cause an app that requests GL_CLAMP texture clamping behaviour will get GL_CLAMP_TO_EDGE_EXT behaviour. Everyone else is doing it the right way but nVidia refuses to fix their drivers since it according to them would let all hell loose if fixed because of the loads of broken apps out there. The truth on the other hand is that no nVidia hardware before GF3 supports the GL_CLAMP behaviour, which is how the bug came into the world in the first place, but even the GF3 will still get incorrect behaviour unless you do a reg hack. Interesting to note was that one of the nVidia guys that contributed in that thread was unaware of the correct behaviour of GL_CLAMP before the GF3.

 

[Sharkfood]

The most insidious bugs are those that are worked around at the game deveoper level for a period of time and are imbedded in a number of applications.

This makes these kinds of bugs like a disease- with driver developers given the choice to either be broken and do things "right" or simply kludge for "compatibility"- at which point the disease spreads. Often times, the only solution that holds any value is to add a third, new method at the API level, enforce usage of the new method, and declare the old methods as "obsolete" and not be used for any new titles going forward. This allows keeping the kludges intact for older titles, a new/correct method for future titles, but also grows the API complexity as now you have multiple (old kludged, new correct) items to support. Not to mention API's become cluttered with lists of "obsolete- for backwards compatibility only" or "unsupported" options/methods.

The only real answer is to nail these things early so they dont have a chance to become widespread. This limits damage control to a small handful. It's just pathetic that some developer relations people are so easily able to schmooze coders to stick to the broken functionality and implement this in their final product when behavior is quite obviously incorrect.

 

[Jeff Royle]

Hmmm are you referring to another companies DevRel or are you saying I'm a schmoozer?? hahaha j/k We do our best to get things sorted out and most developers these days are willing to listen so long as the title isn't closed by the publishers or whoever else down the line. Once they move on to a new title it's hard to convince them to patch a game.


Jeff

 

[Sharkfood]

haha. No, not you Jeff. Although I'm sure if the need ever arose, you could probably schmooze every bit as good as the rest of 'em, I'm sure that need will likely not come around.

It's understandable the many decisions that have to be made when deciding how to implement a certain bug in drivers. You have end user satisfaction weighed with doing the right thing. It's a tough call when you have existing software to worry about and new developers you dont want to inherit the incorrect method.

As far as going back to patch an older product... the costs for this cannot be over exaggerated. In a dynamic development environment, your whole process and systems complex is generally in a state of constant forward motion. Hell, many shops are already putting tough to reverse changes into place the moment the first gold of previous product ships out the door for the next project. To drag around a full dev/qa/qc/ship infrastructure around for each old product would raise the costs and slow down windows which are already pretty tough the way it is. For now, most companies create partial transitions and slowly migrate to a full transition within a month or two into a new product. This way you have like 30% capacity to "revisit" if needed, but this quickly falls to 0% as the new project gains steam... and it's initial milestones are missed.