AMD, open up more than code!

[damentz]

8.41 was just a noob attempt at getting your fanbase back. Seriously, just bloody open up. By open up, not necessarily code. ATI has always sucked at talking directly to its customers. Just look at the nvidia linux forum. The devs actually have these things called... errr... conversational skills.

You rely on people with nasty NDA compromises to represent the company for you. What the f*ck is that. This is not a rhetorical question, why can't you build your own forum so people can give feedback directly to you?

Try using your own hardware and bandwidth instead of piggybacking on ad sustained forums.

[Kano]

Yes a forum would really help where ATI developers are allowed to post, I guess they are not allowed to do so. nvnews is not owned by NV, but any "wellknown" board would be ok for support, it is not needed to create a new one.

[Michael]

AMD's Matthew Tippett has posted here before. Though when they are busy working on a driver, why should they spend their time just talking on forums? They still have a lot of work to do.

[thoemy]

I don't care if they talk on forums. But it would be really nice if they would say something on the unofficial bug tracker. Maybe they post comments but I've not seen one with either AMD/ATI in the name or E-Mail address.
Something like "We know about/working on this issue", "Can you please also post the output of XY", "This is not a bug in fglrx but in X", "This will be fixed for ?.??" or "We wont fix it because XY" should be enough.

[Michael]

I don't care if they talk on forums. But it would be really nice if they would say something on the unofficial bug tracker. Maybe they post comments but I've not seen one with either AMD/ATI in the name or E-Mail address.
Something like "We know about/working on this issue", "Can you please also post the output of XY", "This is not a bug in fglrx but in X", "This will be fixed for ?.??" or "We wont fix it because XY" should be enough.

Look at who is CCed on most (or all) of the bug reports: http://ati.cchtml.com/show_bug.cgi?id=123 ATI/AMD does use the BugZilla even though they don't post many replies.

[Kano]

When they are too busy then they should hire more developers. Every other enterprise would do that.

[Svartalf]

AMD's Matthew Tippett has posted here before. Though when they are busy working on a driver, why should they spend their time just talking on forums? They still have a lot of work to do.

I'll say... And it's not Matthew's fault that they still have a lot to do... :D

[Svartalf]

When they are too busy then they should hire more developers. Every other enterprise would do that.

You'd think that, but they did a global, company-wide RIF by 5% at the beginning of the year to appease the daytraders; even if they wanted to staff up the group like they needed to, they couldn't have done so because it'd have opened them up to EEOC suits (Why are you laying off here and hiring there??).

Unfortunately for AMD, they bought ATI whose upper management was chasing the set-top and DirectX space to the detriment of a lot of other things. They ended up being trapped and the acquisition of ATI gave AMD serious financial indigestion. Long term, I think the prognosis is good for things (IF they can keep jamming out the specs for an Open Sourced 3D driver and they come clean on the fact that they're in a bit of a sticky spot right now because they're way understaffed for this segment of the business...) but for now they're still just flopping about like a fish out of water.

[Svartalf]

Look at who is CCed on most (or all) of the bug reports: http://ati.cchtml.com/show_bug.cgi?id=123 ATI/AMD does use the BugZilla even though they don't post many replies.

Yes, Matthew does see this stuff. The poor man's busier than a one legged man in a butt-kicking contest- so much of this goes unfixed because they can't triage it, can't analyze what the heck is actually broken on these unofficial bug reports.

[yoshi314]

maybe if they would release some extra testing tool to accompany fglrx, life would be easier (for them).

[Svartalf]

maybe if they would release some extra testing tool to accompany fglrx, life would be easier (for them).

Unfortunately, it's not QUITE that simple.

A tool won't tell you if a game slowdown is because of a bug, a design flaw in the driver, or the studio just doing something stupid with their buffer management code (I've seen all three, actually, over the years...)- or if it's two of the aforementioned problems.

For example...

Vertex Buffer Objects.

They allow you to store the vertex information for pieces of the scene or the whole scene into memory that's resident ON the card. They allow you to pre-load this information at the beginning of a level so you're not pushing the vertex data across the bus, which slows things down. Unfortunately, it's a limited resource. There's several ways to utilize this resource. You can do the "reccomended" way of doing things, per the ARB, which is to allocate a new allocation of VBO space for any new set of vertex data and let the driver's memory management handle it. Unfortunately, this isn't terribly practical on anything with a dedicated memory space of any less than 128Mb of RAM, so most developers used a feature which allows you to manipulate the buffer object's space by mapping it temporarily into the Host's memory space. Now, how you handle this mapping action determines how well everything works- both on the driver and on the applicatrion's side of things. Typically, what you do is wait until the frame is rendered, map the VBO, flush new vertex data to it, then render with the VBO. Some card drivers have smart enough memory management to allow you to map and remap the buffer with impunity so long as the GPU isn't actively using the same. Some card drivers have, unfortunately, been written to stall the pipeline when you map the buffer as they, either because of a lack in hardware, lack of support in memory management, or both, are unable to track which VBOs are actively in use and which ones are not.

Some studios have written their code so that they map the VBO, flush the new data to the buffer, render, then recycle the buffer several times with several different VBO sizes. To get peak framerates out of anything, the GPU has to work MOSTLY asynchronously against the backdrop of the CPU's work. The CPU needs to be able to push the frame to be rendered immediately and then be able to push the next frame(s) while the other one is rendering, such that the CPU is not waiting for the GPU except at end of a frame (if that) and the GPU is never allowed to be idle. A stall of a millisecond or so can drop framerates by as much as half what they might be. With the games in question, if the driver's implementation stalls for engine idle on a mapping operation, they drag the gameplay to the slideshow framerate territory on ANY hardware you care to mention.

In the aforementioned case, it's not as good a design as it possibly could be on the driver's part (The driver should know, within reason, what VBOs, etc. are in play at any given time...) and it's very poor code on the studio's part as the spec explicitly states that a driver "may" wait until engine idle when a map call is made on a VBO.

In the aforementioned case, who's at fault? The studio. But the problem is blamed on the driver and the GPU because the other vendor's code handles the bad behavior of the game much, much better.

Who should fix it? The studio ought to, but it typically falls to the vendor to fix the problem.

That's the kind of world NVidia, Intel, and AMD live in and a testing tool won't help you- you actually need to understand the innards of the driver to be able to find out what's actually busted in many cases, believe it or not.

[damentz]

Maybe they should make smart driver releases based on need (basically what nvidia does) instead of dumb static monthly releases (ya this sucks when they release a driver RIGHT before a new version of the linux kernel or X.Org is released) and talk/respond to us.

We are human beings after all, if they need some outside help testing/supplying information to improve the driver, many of us would be willing to help.