Announcement

Collapse
No announcement yet.

There are many more readers than members

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    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

    Comment


    • #92
      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.

      Comment


      • #93
        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.

        Comment


        • #94
          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.

          Comment


          • #95
            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 ?

            Comment


            • #96
              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.

              Comment


              • #97
                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.

                Comment


                • #98
                  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 ?

                  Comment


                  • #99
                    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).

                    Comment


                    • 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 ?

                      Comment


                      • Originally posted by bridgman View Post
                        Wow; I had heard of SimNow before, but for some reason I thought that it only simulated core platform components (CPU/Northbridge/Southbridge). The manual makes it pretty clear that there's quite a lot of stuff in there. I get the impression that it's not all AMD's to release, though (a Matrox G400 model? ).

                        Comment


                        • I think we added an r600-family simulator to the model set, and the web page talks about HD3850 which lines up. I don't know where all the IP comes from, but a quick web search didn't turn up any obvious third party owners.

                          What I don't remember is whether the simulator model responds to driver code (register writes, command packets etc..) or whether it simulates at some higher level. Need to find out.

                          Comment


                          • Mindshare really at this point. For every person, who bitches about you're drivers, you lose about 2 customers. Because people who bitch spread their anger. When someone is satisfied with something, they sadly usually aren't motivated to make their opinions known as there is no incentive to express them.

                            The Linux community is filled with the most hard-blooded and outspoken people as I'm sure you have realized. When we don't like something, we bitch, bitch again, and bitch some more. We are almost as bad as Mac users (except without the denialism).

                            You guys need a hard plan and a roadmap, cause that is the only way you can get things done, especially with limited resources.

                            ----

                            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 ?
                            Have distros ever really performed their primary function well? That is the reason of the semi-rolling release system. Because we are HORRIBLE at maintaining our packages unless 1. we don't ever change anything (a.k.a Debian Stable or Red Hat Enterprise) or 2. barely check our packages for bugs and never customize them (a.k.a Gentoo, Arch or Debian Unstable) or 3. are special purpose distros with a minimal feature set (a.k.a XBMC Live).

                            The best examples of distributions that have tried what you have suggested, are frankly the worst of all worlds (ie. Fedora, Ubuntu, Mandriva, OpenSuSE). They are buggy, have outdated packages and without a shitton of customization, are completely incapable of performing specialized tasks.

                            With infinityOS I have tried to take a little of all three successful models, while avoiding the pitfalls of the unsuccessful forth model. I have a stable core OS (as Ubuntu is basically Debian at its core. Try installing Ubuntu with the minimal install. It is EXACTLY the same as the Debian net-installer). I have update to date package for end user packages that really don't need much testing as the devs have a direct incentive to make sure their packages work. And lastly I have a core feature set that I make sure worked to the T. My Bittorrenting and media features are guaranteed to work out of the box.

                            ----

                            The philosophy behind infinityOS is that the best people to do the packaging are the developers themselves. This is essentially because Ubuntu has *zero* reason to care whether Texmaker works out of the box and figures if there are any problems, the people will go directly to the developers anyways. infinityOS' release system cuts out that step, as the developers provide the packages. The developers have every incentive to make sure their packages work, as if they don't, they _directly_ will have to deal with their users.

                            In a way, the release system of infinityOS is much more similar to the release system of Windows or Mac OS X, in that the distribution maintainer only maintains the core distribution and leaves the maintaining of the individual packages to the developers. The only exception is that it has the integration of the package system, making it easier for users to install and update their programs.

                            Comment


                            • Originally posted by bridgman
                              I think we added an r600-family simulator to the model set, and the web page talks about HD3850 which lines up. I don't know where all the IP comes from, but a quick web search didn't turn up any obvious third party owners.

                              What I don't remember is whether the simulator model responds to driver code (register writes, command packets etc..) or whether it simulates at some higher level. Need to find out.
                              Yes, the manual mentions a model for HD 3870. It says:

                              The ATI Radeon HD 3870 device model is a faithful simulation of the software-visible portion of an ATI Radeon HD 3870 adapter; it is not a model of the specific ATI Radeon HD 3870 hardware. Because of this, the graphics device model is not equivalent in certain areas. Any issues related to timing, such as the vertical retrace time, DAC, CRTC and GPU clock timing, will be different. Any software that depends on exact timing behavior may not function correctly.

                              The following features are not supported in this version of the ATI Radeon HD 3870 device model. Any software that depends on these features may not function correctly.

                              Unsupported Feature List
                              • DirectX 10+ (shader constant buffer, geometry processing, shader
                              • import/export from memory, DirectX 10 shader instructions)
                              • Flow control and conditional shader instructions
                              • Texture Filtering, mip mapping, LOD, anti-aliasing, blending weight
                              • generation, depth filtering
                              • Line color gradients, wireframe fill mode, Fog
                              • UVD
                              • Dual screen configurations and display hotplug detection
                              • ATI CrossFire™

                              Comment


                              • I don't disagree with your summary of the current distro challenges, but dumping the support work on an even smaller community obviously won't work, and expecting HW vendors to lose big chunks of money on Linux isn't really a great strategy either.

                                At some point you really need to think about building some kind of business model rather than giving stuff away for free and expecting that somebody else will pay the bills. Ubuntu, Red Hat and Novell (among others) have all built successful business models around Linux, all different but all allowing them to finance a certain amount of ongoing development and to support their users. You may not like the way they do it, but that is a function of the amount of money their business model contributes for paid staff and their ability to attract volunteers for the bulk of the community.

                                There is a certain amount of business opportunity in Linux, and that drives the amount we can reasonably invest in supporting it. With maybe 1/50th of the PC market (most numbers say closer to 1/100th) we are already investing as much as or more than the current Linux market can support, assuming we already have the same market share in Linux as Windows. We don't mind sustaining that for a while but I don't think it's realistic to ask us (or any of the other HW vendors) to provide funding for OS vendor support costs, which we don't do on any other OS.

                                Basically you're saying "you need to pour money into Linux than you make from it, so that it can become more popular and then cost you even *more* to support. This is good for you and one day I'll explain how".

                                Seriously. I really like what you are doing with the distro but you aren't offering a captivating business opportunity yet

                                Comment

                                Working...
                                X