Announcement

Collapse
No announcement yet.

"Ask ATI" dev thread

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

  • On the fglrx side, we started the transition to common code a few years ago, even before joining up with AMD. The primary goal was to better address the workstation business but the work also made it possible to start bringing high-end features and performance to consumer users.

    On the open source side, a couple of things happened at the same time. As a result of joining up with AMD we picked up an additional set of customers (buying CPUs rather than GPUs) and those customers generally had a significant interest in out-of-the-box Linux support. AMD CPUs have been strong in the server space for a while but those same customers are also targeting enterprise client users with Linux and so open source driver support for our GPUs was identified as a top priority for a number of the larger CPU buyers.

    To a certain extent open source GPU driver support is a "cost of doing business" on the CPU side, but it benefits both enterprise and consumer users in the process.

    There have been super-charismatic Linux advocates on both the ATI and AMD side for a while, but until the last couple of years it was tough to provide any business justification for investing in Linux support. We are probably still spending more on Linux support than the market share today justifies, but I think we can justify the investment with the potential of greater workstation and enterprise client sales in the future.
    Last edited by bridgman; 08-20-2008, 08:48 PM.

    Comment


    • Originally posted by mitch074 View Post
      on HD48xx cards, enabling this mode may trigger the 'checkerboard of doom' bug, if only when switching from/to full screen.

      Is this bug known, and a fix underway? Thanks!
      I have been on vacation and largely "off the grid" for the last couple of weeks, but will ask around on Monday when I get back in the office.

      Comment


      • My question regards the "resolved issues" and "known issues" sections in the release notes.

        From looking at these sections for the last 10 or so fglrx releases, it seems to me that it represents only problems discovered by QA folks through limited tests, using scenarios not very common (or, indeed, important) for the average user. See, for example, the resolved issue on last release concerning flashes upon launching Catalyst control centre on a CRT screen attached to a X1600. The main issues, stirring the community up (like the infamous WINE checkerboard of doom), fail to appear at the list of known issues, and when (and if) they are fixed it is a sort of nice surprise mixed with a sigh of relief.

        Is it possible to fortify the connection between your bug fixing priorities, as affected by both QA and users reports, and your release notes? It seems to me that some parts in the release notes represent a legacy of community-ignoring beurocracy, which actually no longer dominates the AMD linux team. Currently the main communication channel of the community to you is through this website; I believe everybody will feel better if the official messages of AMD to its linux users, i.e. driver release notes, will also reflect a recognition of the community's problems and needs.

        Comment


        • Another name for the "community-ignoring bureaucracy" is "the workstation market", which *does* still dominate the AMD Linux team. It also represents most of the directly measurable Linux-related graphics business, which is why it gets the attention. If you see bugs being fixed which are not a priority to the consumer user community there's a pretty good chance they either *were* an issue for workstation or were a cross-OS issue which had been flagged as occuring on Linux as well as a "non-Linux OS".

          We are also taking steps to have our QA groups try to reproduce problems reported here on our internal systems, making it possible for developers to do something about them, so you should start to see more alignment between community input and release note content over time.
          Last edited by bridgman; 08-20-2008, 10:22 PM.

          Comment


          • Bridgeman, this isn't a question, more so as perhaps a summary of the common ground for us consumer clients. Right now you have 3 'teams', as I understand, working on rolling releases for fglrx and while I can't speak for your enterprise or other business clients, it seems that most of the consumer clients feel left out in this setup.

            What I would like to suggest, is perhaps a different way of going at this. Could it perhaps be worked that one team instead works on new features - such as the more complete crossfire support being worked on - while the other 2 teams be regrouped where 2/3 of them work on workstation level bugs and the other 1/3 on bugs that affect the consumer market?

            I seems as though for the majority of us linux users, looking for better support on our home computers and laptops, there aren't all that many new features we desire, but we would love for the known bugs to be fixed. For example, when I read that crossfire support and adaptive anti-aliasing has been added I thought 'that's kinda neat. Doesn't do anything for me, but neat.' then saw that video tearing and the wine corruption still exists, I was suddenly rather meh about this release.

            I know you guys are working hard, and that some of us tend to get really frustrated over some minor things, but it seems that we are presently more interested in bug fixes than fancy new features or minor performance enhancements.

            Comment


            • Originally posted by wfeltmate View Post
              but it seems that we are presently more interested in bug fixes than fancy new features or minor performance enhancements.
              I totally agree and really prefer nothing new for 6 let's say months and the fix of driver's major bugs such as those that segfault 3d apps and much needed those that hang completely the computer!
              I mean we can crash hard disks with that bug that freezes everything when a video file ends! Imagine trasferring data the same time!...
              and all the bugs that freeze the systems which are quite a few!

              Comment


              • Originally posted by wfeltmate View Post
                Could it perhaps be worked that one team instead works on new features - such as the more complete crossfire support being worked on - while the other 2 teams be regrouped where 2/3 of them work on workstation level bugs and the other 1/3 on bugs that affect the consumer market?
                I don't think you're taking into account the testing/packaging/release management stuff that goes with each release, the possible aims the teams already have, or even things like the dynamics of the teams as they're set up now. It sorta sounds like you're falling into the trap that many managers do, of assigning "man-hours" to various tasks like cash, and expecting linear results.

                I know I sound like a hippy, but as a gamer/general consumer, the best thing I think we can do is continue making noise, pointing out the fact that keeping us happy can influence the confidence of businesspeople architecting workstation rollouts, or vendors who sell solutions.

                Either that or license the id Tech 5 engine to build a CAD program

                Comment


                • Originally posted by djdoo View Post
                  I totally agree and really prefer nothing new for 6 let's say months and the fix of driver's major bugs such as those that segfault 3d apps and much needed those that hang completely the computer!
                  I mean we can crash hard disks with that bug that freezes everything when a video file ends! Imagine trasferring data the same time!...
                  and all the bugs that freeze the systems which are quite a few!
                  You can always "ignore" the releases and go by your own update schedule.

                  Comment


                  • Some example of bug reporting

                    Originally posted by bridgman View Post
                    We are also taking steps to have our QA groups try to reproduce problems reported here on our internal systems, making it possible for developers to do something about them, so you should start to see more alignment between community input and release note content over time.
                    I think that's actually what's missing: a way to report and follow reported bugs for the fglrx driver; maybe not as complete as Bugzilla, but the following should be more useful than a 'mere' forum.

                    Please note that I haven't tried Catalyst 8.8 yet (the bug may have been solved).

                    The 'checkerboard of doom' bug, for example, could be filed as:

                    OS: GNU/Linux (any)
                    Platform: x86, x86-64

                    Affected hardware: HD2xxx, HD3xxx, HD4xxx

                    Affected driver revisions: Catalyst 8.6, 8.7

                    Summary: some OpenGL applications trigger a display bug in fglrx that makes display unreadable.

                    Description:
                    Several 3D-intensive applications, usually ones that make use of a full-screen mode, may trigger a rendering bug which divides the screen in approx. 16px squares and scrambles them.
                    Affected applications are:
                    - Wine 0.9.58 to 1.1.2 (both D3D and WGL wrappers)
                    - Nexuiz (triggers bug at boot, but driver 8.7 restores itself)
                    - mplayer (with -vo gl2 used to make use of multitexture OpenGL renderer, switching back and forth may trigger the bug)

                    The bug is fatal with Catalyst 8.6 (system lockup), but 8.7 can restore itself after either a little while or when closing the trigger application.

                    Interestingly, when the bug is triggered, making a screen capture with e.g. GNOME's screen capture utility displays no corruption in the captured snapshot.

                    Steps to reproduce:
                    1 - connect affected card (here, HD 4850) to 1680x1050 screen through DVI
                    2 - start affected application
                    3 - stare at the screen dumbly :P

                    Reproducible: on affected systems, always.

                    Description of bug reporter's platform:
                    - Nvidia 6150 chipset-based motherboard (Asus A8N-VM CSM)
                    - Athlon X2 3800+, socket 939 version
                    - 2 Gb of DDR400 in dual channel
                    - Mandriva 2008.1 Free x86-64 with all updates and backports applied
                    - distribution-provided 8.6 driver, manually installed 8.7 driver

                    Other platforms displayed the bug as well.

                    Comment


                    • Originally posted by wfeltmate View Post
                      Bridgeman, this isn't a question, more so as perhaps a summary of the common ground for us consumer clients. Right now you have 3 'teams', as I understand, working on rolling releases for fglrx and while I can't speak for your enterprise or other business clients, it seems that most of the consumer clients feel left out in this setup.
                      Let's get this out of the way first. We do not have multiple teams rotating through releases. It may appear that way because we have a mainline and release branches where we freeze code for QA test and final bug fixing, but we do not rotate teams or releases. It's all one group.

                      Originally posted by wfeltmate View Post
                      What I would like to suggest, is perhaps a different way of going at this. Could it perhaps be worked that one team instead works on new features - such as the more complete crossfire support being worked on - while the other 2 teams be regrouped where 2/3 of them work on workstation level bugs and the other 1/3 on bugs that affect the consumer market?

                      I seems as though for the majority of us linux users, looking for better support on our home computers and laptops, there aren't all that many new features we desire, but we would love for the known bugs to be fixed. For example, when I read that crossfire support and adaptive anti-aliasing has been added I thought 'that's kinda neat. Doesn't do anything for me, but neat.' then saw that video tearing and the wine corruption still exists, I was suddenly rather meh about this release.
                      One of the problems here is that a lot of the things you think of as "bugs" (eg video tearing) are actually "lack of features". Syncing video playback to vblank is one of the areas where the current X/DRI stack has always had problems (and is in the process of being re-written again), while Windows and MacOS have had a framework to support this for years.

                      Video tearing will be fixed by adding new features to the drivers, not by "fixing a bug" -- if it was just a question of fixing bugs we probably would have done that already.

                      I see some posts about "why are you adding features like overclocking ?" but overdrive, powerplay and thermal management are all different aspects of the same code. As we finish integrating power management into the Linux drivers things like Overdrive more-or-less come along for free. I guess we could leave them completely hidden but I don't think that would save much time or eliminate any bugs because we need to set everything up properly anyways.

                      I'm actually surprised that nobody is talking about the improved multi-head support we added in 8.8. That is by far the most disruptive change but it is also one of the most requested features we hear about.

                      Originally posted by wfeltmate View Post
                      I know you guys are working hard, and that some of us tend to get really frustrated over some minor things, but it seems that we are presently more interested in bug fixes than fancy new features or minor performance enhancements.
                      We do understand your needs (and your frustration) and that was one of the reasons we kicked off the open source driver initiative last year. I expect that over time most consumer users will gravitate to the open source driver, since it is targeted precisely at those requirements -- simple driver, core functionality, and able to be tweaked to match your specific distribution so things like suspend/resume work reliably for relatively more users.

                      Right now there are two remaining things which need to be addressed in order to make the open source driver viable for general consumer use -- addition of a decent memory manager in the kernel (which allows the implementation of GL 2.0 functionality), and support for the 6xx/7xx 3d engine (which allows more acceleration to be added to the HD2xxx-HD4xxx drivers than the shadowfb acceleration we have today). The first task is being worked on by the community, with Dave Airlie taking the lead, and the second task is being worked on by AMD and Novell developers.

                      The proprietary driver will be the vehicle for delivering maximum performance and functionality, but I see it as an "upgrade path" for consumer users if they are looking for something more than the open source driver can provide.
                      Last edited by bridgman; 08-21-2008, 10:57 AM.

                      Comment


                      • Originally posted by bridgman View Post
                        One of the problems here is that a lot of the things you think of as "bugs" (eg video tearing) are actually "lack of features". Syncing video playback to vblank is one of the areas where the current X/DRI stack has always had problems (and is in the process of being re-written again), while Windows and MacOS have had a framework to support this for years.

                        Video tearing will be fixed by adding new features to the drivers, not by "fixing a bug" -- if it was just a question of fixing bugs we probably would have done that already.
                        Right, this one is a missing feature in xorg. But what about the rest. The main issues here being the OpenGL windowed/fullscreen app, known as "checkboard of hell" or "wine problem" (it happens in other apps that are not wine, too) and is a problem of the OpenGL implementation since switching to the xorg opengl implementation magically makes this problem not to appear.

                        Another really bad problem is the instability with xv/textured video. It must not happen that those freezes are reproducible and happening for now 4 releases already (or even more?). I think it is really bad if playing video is able to freeze all of the system and this one was already mentioned very often by now.

                        I think those two problems are very common and already in the driver for a long time. As such they do deserve some attention since IMO new features like overdrive and crossfire are basically worthless when the driver is not stable in "general mixed usage". IMO in this case stability is more important than new features.

                        In the case of textured video: yes, it is/was basically a new feature. But I expect new features to be stabilized in more recent version, not having them stay unstable.

                        [/rant]

                        I really appreciate you being here and the forums and looking at things. And I *love* the open source efforts of amd/ati which was the sole reason why I bought my hd3850. If there would not have been this effort, I would probably still be on a agp system with my good old 9800pro and (rock solid) open source drivers.

                        Comment


                        • I haven't looked much at either of the issues but the OpenGL windowed/fullscreen issue does sound like a regression we should have caught. We changed a lot of things in that area over the last few months in order to improve multi-head support so I'm not surprised something broke, but I am surprised we didn't catch it (I know how our QA folks love to twiddle between windowed and fullscreen until something breaks ). My guess is that the problem did not happen on our test systems, which should be a useful clue for finding and fixing it if nothing else.

                          I thought I saw a mention in the release notes for 8.8 that we had fixed the Xv "fail on termination" issue, at least the one we were able to repro in-house. There may be other issues which we have not been able to repro in house yet, not sure but will ask around when I get back in the office next week.
                          Last edited by bridgman; 08-21-2008, 11:09 AM.

                          Comment


                          • Originally posted by bridgman View Post
                            I thought I saw a mention in the release notes for 8.8 that we had fixed the Xv "fail on termination" issue, at least the one we were able to repro in-house. There may be other issues which we have not been able to repro in house yet, not sure but will ask around when I get back in the office next week.
                            One 100% reproducible issue I have over here with textured video (already reported it several times before):

                            Needed "utilities":
                            kaffine with xine backend and dvb support
                            dvb card (using a mantis based Terratec Cinergy C over here with the driver from the mantis git plus some extra patches, crashes happen without patches, too)

                            When setting the video backend in xine to 'Xv' (or auto, then it will be using Xv if available) and starting to view dvb the whole system will freeze with one of the typical "strange video" windows that always happen with textured video when it freezes.

                            To provide you with some extra data, my system specs:

                            Gentoo unstable based system (no matter if 32bit or 64bit)
                            Vanilla kernel 2.6.25.15 (older ones affected, too)
                            ATI HD3850 512MB
                            Gigabyte GA-P35-DS3
                            C2Q9300
                            4GB Ram
                            Kaffeine 0.8.7 (older versions like 0.8.6 affected as well)
                            xine-lib 1.1.14 / 1.1.15 (no idea about older, I think .13 is affected as well)

                            I think I saw others reporting those problems with kaffeine (xine backend) and textured video, too. When using OpenGL as render interface for xine dvb does not crash.


                            EDIT:
                            For the case it helps (I don't think so since the driver is missing the debug info), a backtrace from the crash as described above. This is the end of Xorg.log:
                            Code:
                            Backtrace:
                            0: X(xf86SigHandler+0x6a) [0x48dc2a]
                            1: /lib/libc.so.6 [0x7f91f16e32c0]
                            2: /lib/libc.so.6(memcpy+0xd2) [0x7f91f172fe42]
                            3: /usr/lib64/xorg/modules//glesx.so [0x7f91ec6697b7]
                            4: /usr/lib64/xorg/modules//glesx.so [0x7f91ec6c8c4f]
                            5: /usr/lib64/xorg/modules//glesx.so [0x7f91ec69c406]
                            6: /usr/lib64/xorg/modules//glesx.so [0x7f91ec69cb34]
                            7: /usr/lib64/xorg/modules//glesx.so [0x7f91ec61ac77]
                            8: /usr/lib64/xorg/modules//amdxmm.so [0x7f91ec4464e9]
                            9: X [0x479306]
                            10: /usr/lib64/xorg/modules/extensions//libextmod.so [0x7f91f0dbad5f]
                            11: X(Dispatch+0x340) [0x44cc30]
                            12: X(main+0x4a5) [0x434165]
                            13: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f91f16cf486]
                            14: X(FontFileCompleteXLFD+0x281) [0x433429]
                            
                            Fatal server error:
                            Caught signal 11.  Server aborting
                            Last edited by ivanovic; 08-21-2008, 11:36 AM.

                            Comment


                            • pbo problem

                              In fglrx ver. 8.8's release note, they said "OpenGL PBOs no longer fail to work with GL_RGB texture format". But I still got a problem when try to update (part of) texture using glTextSubImage2D and pbo.

                              thanks

                              Comment


                              • @bridgman:

                                Any idea when fglrx will support EXA or a custom accaleration achritecture, accalerating XRender properly?
                                I am currently developing a XRender based pipeline for Java, and fglrx is the only driver (intel, and now also nvidia does) which is not able to accalerate XRender.

                                Thank you in advance, Clemens

                                Comment

                                Working...
                                X