There are many more readers than members

[monraaf]

I have to disagree. Frankly most Ubuntu users don't have the slightest idea how to file good bug reports, and I'm saying this as an Ubuntu user myself. There is only a handful of developers. The last thing you want is them wasting time holding hands of clueless users. Those who do have a clue will find their way to the freedesktop bugzilla, the git repos and the mailing lists themselves.

[darkphoenix22]

I have to disagree. Frankly most Ubuntu users don't have the slightest idea how to file good bug reports, and I'm saying this as an Ubuntu user myself. There is only a handful of developers. The last thing you want is them wasting time holding hands of clueless users. Those who do have a clue will find their way to the freedesktop bugzilla, the git repos and the mailing lists themselves.

Eh. It takes 10 sec to mark a bug as "Won't fix" and make it disappear from your bug list.

[Ex-Cyber]

I'm actually wondering if a GPU simulator might be the biggest single contributor to lowering the entry threshold for driver development.

Is that something that AMD could realistically contemplate releasing, or would it need to be an outside effort? If the latter, do you think that the released docs are good enough to at least get a good start on it?

[bridgman]

I believe there is enough documentation and support available to write one as an outside effort (heck, I would work on that one), but my first step would be to see if there was something internal we could release to at least kickstart the effort.

We can't release the simulators we use for pre-silicon development because those rely on the actual GPU logic design files (and you can understand how we might be a bit touchy about publishing those), but I think there was some work on a functional simulator written against the programming model rather than the logic design. One more thing to add to my to-do list ;(

[bridgman]

Eh. It takes 10 sec to mark a bug as "Won't fix" and make it disappear from your bug list.

You can't really "won't fix" low quality bug reports. That sends the wrong message - that there *is* a bug but for some reason users are stuck with it. Again, the challenge here is the domain complexity - a problem in one driver might manifest itself as a problem in a different driver as a result of compositing, for example - and the high learning curve before someone can even file good bug reports.

Seriously, we need more developers and really knowledgeable testers who can sort through user issues and distill them to something the devs can sink their teeth into, not a fatter pipe from end users to the few devs we have today.

[bridgman]

... but I think there was some work on a functional simulator written against the programming model rather than the logic design.

I think this is it :

http://developer.amd.com/cpu/simnow/Pages/default.aspx

[Kano]

Can you explain why not even the most basic things like xv work with fglrx? Even oss drivers adopted that relatively early without tearing. The OpenGL workaround with forced vsync does not work for all tools, especially not commerical dvd players which only support xv like LinDVD. As thats one of those players which can handle copyprotected dvds (i do not mean css!) it should really work with fglrx - those dvds do not play with mplayer. Even when your main target are professional users take a look at nvidia, there xv always worked and vdpau is much more improved that the xvba+vaapi hack.

[darkphoenix22]

Seriously, we need more developers and really knowledgeable testers who can sort through user issues and distill them to something the devs can sink their teeth into, not a fatter pipe from end users to the few devs we have today.

You could set some rules to what exactly the user/tester needs to file a bug report, and tell people that if they do not provide all this information, the bug will be automatically marked as won't fix.

These systems also search for existing bugs and FAQs when filling a bug or questions to deter users from filling existing bugs and questions that have already been answered.

Additionally, you could set up some forums, similar to these ones, for the end-users. In my experience, even if you make it easy, most people still won't bother filling bugs, because they are too lazy to make an account and are daunted by all the info provided in the bug reports.

The only reason why Ubuntu has a bit of a problem with this stuff is cuz they are the first source of info for many of these users. People will still have to seek out the Radeon drivers bug database. Their forums are also pretty vague and crowded. If you give the users forums, really only the testers will bother to file bugs.

[bridgman]

Again, there are dozens of forums already. What we lack is enough devs to interact with all the forums, or they fill up with bad info and make things worse.

Many (but not all) of the driver problems users experience are distro specific so simply replacing the distro forums with a radeon forum doesn't seem like a win.

What we are doing is building up relationships with the different distro communities to get a cleaner interface between the L1 distro-specific support community and the L2 driver-specific support, ie so things only get to the driver community once most of the distro-specific issues have been handled locally.

I know we discussed your desire to have the driver community take on more of the support effort, but the direction we are moving right now is the other way, trying to make sure that the driver community delivers timely, solid functionality that the distro communities can pick up, integrate and support themselves, escalating to the driver community when a problem seems to be driver specific rather than being a user or distro-specific issue.

[bridgman]

Can you explain why not even the most basic things like xv work with fglrx? Even oss drivers adopted that relatively early without tearing. The OpenGL workaround with forced vsync does not work for all tools, especially not commerical dvd players which only support xv like LinDVD. As thats one of those players which can handle copyprotected dvds (i do not mean css!) it should really work with fglrx - those dvds do not play with mplayer. Even when your main target are professional users take a look at nvidia, there xv always worked and vdpau is much more improved that the xvba+vaapi hack.

The nvidia driver has been around for what, 15 years ? The fglrx driver has been ramping up consumer support for 2-3 years, and most of the rest of the time we were focused on open source drivers. We're catching up fast on the proprietary side but not entirely there yet. Why do you keep asking the same question - do you just like hearing me answer it or something ?