Page 10 of 12 FirstFirst ... 89101112 LastLast
Results 91 to 100 of 115

Thread: There are many more readers than members

  1. #91
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    Quote Originally Posted by bridgman View Post
    ... 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

  2. #92
    Join Date
    Aug 2007
    Posts
    6,598

    Default

    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.

  3. #93
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Quote Originally Posted by bridgman View Post
    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.

  4. #94
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    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.

  5. #95
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    Quote Originally Posted by Kano View Post
    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 ?

  6. #96
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Unfortunately, that model will never work because the distribution maintainers have a lot of work to do as well and are in limited supply.

    You're relying on a subset of a subset of users to make documentation and to file bugs. Ubuntu, as example, honestly will do the bare minimum to test you drivers and see if they work as they have to deal with Intel and Nvidia drivers as well and provide documentation for those drivers.

    Ubuntu/Generic distro does not have a major financial incentive to make sure your drivers work and document them. They will always do the bare minimum as that is all that they can do. This is why the Radeon drivers in Karmic don't support 3D. The Ubuntu devs did not want to put in the considerable amount of time needed to test the drivers and make sure all the components are up to date enough to support your drivers' full functionality. Hell it's almost impossible when you guys can't even tell us what code and versions of libraries your drivers need without diving into the configure file and the git repo. I'm sorry but I just don't have the time to do that and it's likely the same for the Ubuntu/other distribution devs.

    The distribution maintainers are only going to put as much effort into the distribution and documentation of your drivers as you guys. This is mostly because we will NOT make up our own documentation from scratch and the little documentation we have will be based on yours.

    Being a distribution maintainer is hard and a lot of work. If you want full support, you have to make our lives easier.

  7. #97
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    And having a complete rolling release system is not the answer, as many of our users will not be capable of updating the kernel or updating X.org by themselves.

    Hell, updating the existing kernel to a new major revision in many cases requires that you update all your kernel modules and drivers for everything to the latest versions. This is not acceptable for general purpose distros, as we do not have the time to continually test core libraries and to see if upgrading breaks anything.

    The best you will get with a pure rolling release system is something like Gentoo, Arch or Debian Unstable. Minimal testing and frequent breakages.

  8. #98
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    Quote Originally Posted by darkphoenix22 View Post
    Unfortunately, that model will never work because the distribution maintainers have a lot of work to do as well and are in limited supply.

    You're relying on a subset of a subset of users to make documentation and to file bugs. Ubuntu, as example, honestly will do the bare minimum to test you drivers and see if they work as they have to deal with Intel and Nvidia drivers as well and provide documentation for those drivers.

    Ubuntu/Generic distro does not have a major financial incentive to make sure your drivers work and document them. They will always do the bare minimum as that is all that they can do. This is why the Radeon drivers in Karmic don't support 3D. The Ubuntu devs did not want to put in the considerable amount of time needed to test the drivers and make sure all the components are up to date enough to support your drivers' full functionality. Hell it's almost impossible when you guys can't even tell us what code and versions of libraries your drivers need without diving into the configure file and the git repo. I'm sorry but I just don't have the time to do that and it's likely the same for the Ubuntu/other distribution devs.

    The distribution maintainers are only going to put as much effort into the distribution and documentation of your drivers as you guys. This is mostly because we will NOT make up our own documentation from scratch and the little documentation we have will be based on yours.

    Being a distribution maintainer is hard and a lot of work. If you want full support, you have to make our lives easier.
    Sure, I understand that producing a distro is hard work as well, but with respect just saying "I think it would be better if the driver community took over a lot of the work that is done by distro communities today" doesn't work very well unless there is also a substantial increase in the actual contributors to the driver community (not just end user bug reports).

    There are a certain number of contributors out there. Every year the effort to properly handle each end-user issue goes up as the systems become more complex. The driver code size and complexity has more than doubled in the last two years and will probably do that at least one more time before it settles down. This requires an ever-growing pool of real contributors for the number of active distros and users we had two years ago, and every addition to both the distro count and user base requires more active contributors.

    In most industries growth is a good thing because it brings more revenues and in turn supports more resources dedicated to making it work. We don't have that mechanism here unless we can find ways to turn more existing experienced users into developers and supporters - tools can help a bit but they won't deal with the kind of complexity that we keep introducing in the form of new features, higher expectations and ever-more-customized distributions.

    Where do you think the resources will come from ?

  9. #99
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    AMD is a multi-billion dollar company. Hire on a few more devs. Get some of those devs collaborating with the distributions (like the relationship you guys have with Red Hat). As Linux increases in popularity, your workload will just become larger and larger.

    My suggestion is to look through who is contributing the most to the Radeon drivers and hire them to directly work for ATi. You guys are barely getting by and it's obvious. Demand more personel. Hell strike if you need to (seriously, people with your experience can get hired anywhere).

  10. #100
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,285

    Default

    Gee, anyone not see that one coming ?



    I realize you're coming in a few years after the announcements, but in case it's not clear there has never been a plan for us to fund the bulk of the open source driver development/support effort ourselves, and I don't see that changing any time soon.

    We do supply documentation, direct developer support, co-funded the initial driver development and hired a small team to work with the community and contribute directly to the driver projects, but the primary direct development is still on the proprietary driver since that allows us to deliver features and performance which are a hard requirement for some of the important markets.

    With respect, why do you think AMD (and Intel, and NVidia) should provide funding so distros can stop performing *their* primary function and hand the work over to (highly specialized) driver developers ? What do the hardware vendors gain from getting into the distro business ?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •