Announcement

Collapse
No announcement yet.

Open ATI Driver More Popular Than Catalyst

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

  • #41
    Well ATI likes to fix only rendering issues with well known apps. When a small app like gl2benchmark clearly shows an error it can take 11 month to fix. But idtech 5 should be a too major engine to ignore errors.

    Comment


    • #42
      Originally posted by Kano View Post
      Well ATI likes to fix only rendering issues with well known apps. When a small app like gl2benchmark clearly shows an error it can take 11 month to fix. But idtech 5 should be a too major engine to ignore errors.
      Just curious, but what bug was it? And it was really a fault of ATI, or was it gl2benchmark not behaving to spec?
      And as people love to bash ati so much, how about pointing out something from nvidia that was fixed? Why are ati far outpacing nvidia in the open source driver segment? Why do vbo's traditionally run an awful lot better on ati cards?
      And in response to people saying they can only see ati - that goes both ways, there's quite a few who can only see nvidia and don't seem to want to believe that their drivers have issues too.

      Comment


      • #43
        gl2benchmark did not show test 3+4 when another test was run before, directly executed test 3 or 4 worked. The error was not fglrx specific but a generic opengl error (gl2benchmark is multiplatform anyway as it uses openscenegraph - there is just no win installer for it). It was broken since the introduction of the new fglrx opengl stack till including 9-1 driver. With kernel .28 and older Xserver you can still verify this issue.

        Comment


        • #44
          I'd rather like to know what GFX cards ppl are using, and how they got it

          (ie. I'm a die-hard linux user, and selected the card specifically for linux. but maybe someone else just buys a PC and then it's an ATI, Or they dual-boot into windoze, etc...)

          I personally got a 8800GT for my desktop (as I do gaming there) and i965gm on my notebook.

          Generally speaking the OS drivers are easy to use, and everything works, but they could be faster. Than the NV drivers are FAST, but fancy things (Suspend2disk + resume) won't work.

          IMHO AMD needs the OS drivers, so somebody like me would by the next notebook with AMD CPU+(int. GPU) next time. They also need to update Catalyst to catch up to NV (I understand the performance is up to NV right now, but the driver is still a nightmare).

          Comment


          • #45
            Originally posted by Kano View Post
            gl2benchmark did not show test 3+4 when another test was run before, directly executed test 3 or 4 worked. The error was not fglrx specific but a generic opengl error (gl2benchmark is multiplatform anyway as it uses openscenegraph - there is just no win installer for it). It was broken since the introduction of the new fglrx opengl stack till including 9-1 driver. With kernel .28 and older Xserver you can still verify this issue.
            The gl2benchmark problem has long been talked about here and the upstream maintainer admitted to no longer even maintaining that program nor was/is it really even popular in terms of usage, hence it was not a priority or focus at all for AMD until indirect work happened to fix the issue.
            Michael Larabel
            https://www.michaellarabel.com/

            Comment


            • #46
              It was never a program error. Nvidia never had issues with it. Even when a tool is not often used but it exposes a problem it should be fixed - which was fixed but really late. But it shows definitely the wrong attitude of ATI by fixing primary problems that affect heavyly used apps. Basically 1 rendering problem is already 1 too much.

              Comment


              • #47
                Originally posted by Kano View Post
                It was never a program error. Nvidia never had issues with it. Even when a tool is not often used but it exposes a problem it should be fixed - which was fixed but really late. But it shows definitely the wrong attitude of ATI by fixing primary problems that affect heavyly used apps. Basically 1 rendering problem is already 1 too much.
                All chipsets have known rendering errata. It's already too late to hope that there's no rendering problems.

                Comment


                • #48
                  But it was not chipset error when it rendered before correctly. The problem was in the shared code opengl part. But what i wanted to say is that ATI just ignores errors as long as possible. Some fix the time like currently nobody cares anymore if fglrx supports modelines or not for driving a crt with 100 hz @ 1152x864 by default or not just because tft are much more common. Now a good example is xvba, sure it was done for the extra famous embedded market. Not really hard to guess that these most liked were based on hd3200 chipset (even i know samsung tvs with amd cpu+hd3200 onboard), but everybody tries to claim that those devices are so much different and that support for it was never planned for endusers. The fact is that there is a partially working xvba-video wrapper which shows LOTS of problems. But new drivers do not really fix issues with xvba, no they even render it completely unusable like from 9-10 to 9-11. Then look at Nvidia changelogs - usually there are vdpau improvements listed as they care about problems. fglrx can not even do xv correctly since the hardware solution was removed which was on older chips. Really interesting is that radeon oss can handle it. I think you asked a bit before who will most likely use vesa driver. That's very easy to answer too: Xserver 1.7+ users with ATI HD 5 cards are definitely among em. It's like ATI's Fglrx team is sleeping all the day, playing games on Win or whatever, putting the least possible effort into Linux. It is highly unlikely that they really use the driver they create in their free time. The oss devs however seem to actually care more about end users which i really conside a good move. But there is too much still missing and those who buy ATI hardware now to use it with oss drivers in the future basically lost already. The UVD(2) parts will be most likely never possible to program, the generic way to use shaders to do a similar job will never work on lowend cards. Even a ATI 3450 had problems to use opengl output with fglrx for hd movies - too slow it seems. So will the target be use a highend card to emulate a part which can do the same with very low energy requirements otherwise. Sorry, but something is completely wrong here.
                  Last edited by Kano; 05 December 2009, 11:05 PM.

                  Comment


                  • #49
                    Originally posted by Kano View Post
                    But it was not chipset error when it rendered before correctly. The problem was in the shared code opengl part. But what i wanted to say is that ATI just ignores errors as long as possible. Some fix the time like currently nobody cares anymore if fglrx supports modelines or not for driving a crt with 100 hz @ 1152x864 by default or not just because tft are much more common. Now a good example is xvba, sure it was done for the extra famous embedded market. Not really hard to guess that these most liked were based on hd3200 chipset (even i know samsung tvs with amd cpu+hd3200 onboard), but everybody tries to claim that those devices are so much different and that support for it was never planned for endusers. The fact is that there is a partially working xvba-video wrapper which shows LOTS of problems. But new drivers do not really fix issues with xvba, no they even render it completely unusable like from 9-10 to 9-11. Then look at Nvidia changelogs - usually there are vdpau improvements listed as they care about problems. fglrx can not even do xv correctly since the hardware solution was removed which was on older chips. Really interesting is that radeon oss can handle it. I think you asked a bit before who will most likely use vesa driver. That's very easy to answer too: Xserver 1.7+ users with ATI HD 5 cards are definitely among em. It's like ATI's Fglrx team is sleeping all the day, playing games on Win or whatever, putting the least possible effort into Linux. It is highly unlikely that they really use the driver they create in their free time. The oss devs however seem to actually care more about end users which i really conside a good move. But there is too much still missing and those who buy ATI hardware now to use it with oss drivers in the future basically lost already. The UVD(2) parts will be most likely never possible to program, the generic way to use shaders to do a similar job will never work on lowend cards. Even a ATI 3450 had problems to use opengl output with fglrx for hd movies - too slow it seems. So will the target be use a highend card to emulate a part which can do the same with very low energy requirements otherwise. Sorry, but something is completely wrong here.
                    Kano, every driver has its problems and bugs that go unresolved for long periods of time... Hell, I still have a NVIDIA driver bug that's been open now for about four years or so concerning CoolBits and Xinerama.
                    Michael Larabel
                    https://www.michaellarabel.com/

                    Comment


                    • #50
                      Originally posted by mirv View Post
                      Hopefully the increased development of drivers (and I'll refer mainly to the 3D stack here) will benefit game development under linux.
                      I'm hoping for that too, but currently shaders are not looking great in mesa3d. Somebody needs to raise the bar and break the glsl 1.20 barrier and provide llvm backend for shader compilation. Speaking of 3d foss, we are still in the stone age and time is running out . Another scary thing is that there was no proper memory manager for long time, it's good to see stable TTM and GEM nowadays.
                      Last edited by hax0r; 06 December 2009, 12:38 AM.

                      Comment

                      Working...
                      X