Announcement

Collapse
No announcement yet.

"Ask ATI" dev thread

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

  • So far the added per-chip cost and power impact of implementing separate DRM and non-DRM programming models has been too high. It's not a question of just separating blocks, unfortunately.
    Test signature

    Comment


    • Originally posted by bridgman View Post
      So far the added per-chip cost and power impact of implementing separate DRM and non-DRM programming models has been too high. It's not a question of just separating blocks, unfortunately.
      Yeah I was already afraid of such a thing =x

      Comment


      • One key question to the ATI/AMD devs:

        How can we engage the Linux community to work better with ATI/AMD to help track and report problems at http://ati.cchtml.com?

        There are many stale bug reports, and poor education about reporting bugs here, rather at the distro level. The ATI/AMD world is disconnected from the user-world by this, and we need to find a way to connect the two.

        Perhaps it's a good start that ATI/AMD does some tidying up in this bug tracking system?

        Comment


        • I think we need both. Most of the bugs we're dealing with here are system specific. We are able to catch some on our in house test systems, beta testers catch more, but some will only happen on a user system outside the beta program. That's what ati.cchtml.com is for.

          Users file bugs with detailed system info which gives us a chance of reproducing and fixing the problems. If/when the problem is fixed, the user closes the bug. If not, they either update the bug periodically or it becomes stale. It's very hard for someone not seeing the problem to keep the bug report up to date.
          Test signature

          Comment


          • Originally posted by Qaridarium
            the users needs to report the bug before release in the beta time phase not after the release!

            and then if all bugs fixed the release will come OK....
            Why not just ask them to cure cancer while they're at it? And maybe bring world peace too? It's practically impossible to hit every use case every user has in mind. Release versions are always buggy, period. Sure, you can probably stabilize it very far by doing what some enterprise distros do with their software, as in freeze the inclusion of new features for so long users get frustrated, but who would be happy if ATi announced there will be no new features for the next year, only bug fixes? (features including support for new kernels and X.org versions) The only other alternative is that each version has a bit different bugs but all have bugs. (regressions happens)

            Comment


            • Well just some bugs get never fixed like absolutely bad xv support in fglrx. For dvd res you can use the workaround and use opengl playback with vsync forced, but for vc1/h264 in fullhd it is definitely NOT working with a ATI 3450 - maybe for faster cards. xv support is critical, even when the cpu is fast enough for decoding. It worked much better with the older cards with hardware xv support.

              Comment


              • I really don't have any problems with xv, other than I like the colours of opengl better (this is using mplayer, btw). I use xv with xine too, no worries there.

                Comment


                • Maybe thats more extreme with PAL (25 Hz) content, don't know.

                  Comment


                  • I might just not notice it too much - I used to see some bad screen splits, so maybe it's just that they're not as bad now (i.e not enough to distract me from watching). Most of my dvd's are PAL.

                    Comment


                    • There are no screen splits, that's tearing which happens when vsync is off and that annoys me extremely as the radeon oss driver does it much better.

                      http://en.wikipedia.org/wiki/Screen_tearing

                      Comment

                      Working...
                      X