Announcement

Collapse
No announcement yet.

Future of ATI Linux drivers

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

  • #51
    If NV would to buy AMD then ATI could be closed and the drama has an end

    Comment


    • #52
      Kano: If NV would to buy AMD then ATI could be closed and the drama has an end
      Uhm...a much easier, cheaper, and definitely more realistic solution would be if YOU bought NV.

      Comment


      • #53
        But I do a Linux distro (KANOTIX) and I can not force the users to buy only NV cards, so I have to know what errors ATI is currently making to give best hints what to do.

        Comment


        • #54
          Well, I know I'm ignorant as to how things work. But I just want to know when I can expect the fglrx bug to be fixed where OpenGL apps flicker when Compiz is running. Because of this, I either have to not run Compiz, or switch it off every time I do OpenGL stuff.

          I will say I am impressed with the advances in version 8.2.

          Comment


          • #55
            I don't *think* this is a bug -- it's one of the open issues in the Linux graphics framework. Any app that does direct rendering under a compositing window manager is going to flicker unless the compositor is told to "stop redrawing the screen while my app is also drawing there". I have been told that there are Compiz options to do this without actually switching it off but I don't know the details yet.

            It may be possible for the driver to force apps to use indirect rendering rather than direct -- that's essentially what the "Redirected Direct Rendering" initiative underway now is all about.

            I posted some links in other threads -- worth a read.
            Last edited by bridgman; 20 February 2008, 01:55 PM.
            Test signature

            Comment


            • #56
              Originally posted by bridgman View Post
              I posted some links in other threads -- worth a read.
              I have already unchecked the 'Undirect Fullscreen Windows' option in Compiz, and OpenGL apps still flicker. Thanks for the quick response, though.

              Comment


              • #57
                Originally posted by Kano View Post
                But I do a Linux distro (KANOTIX) and I can not force the users to buy only NV cards, so I have to know what errors ATI is currently making to give best hints what to do.
                Heh... NVidia buying AMD... Riiight. You're such a kidder, Kano.

                As for the situation; I'm not holding my breath any old way. IF AMD gets it's act together in short term, they'll have the edge on things, esp. if they get us enough info to start really learning how to optimize shader compilations (which is a good part of the reason they're faster than we are- everything is shaders in 3D these days and has been for the large part with R300 forward...). IF Intel gets a reasonably high performing part with Larabee and keeps to their policy that they have with the X3000+ GPUs and what AMD's working towards...

                I'm wondering what NVidia's thinking right now. They WERE the one that had all the programming details available without NDA, etc. It's just it was almost impossible to get ahold of one when they made that data available. Otherwise it'd been supported in Utah-GLX. They COULD be the winner in all of this if they move quick enough. But, will they?

                Comment


                • #58
                  Originally posted by forrestcupp View Post
                  I have already unchecked the 'Undirect Fullscreen Windows' option in Compiz, and OpenGL apps still flicker. Thanks for the quick response, though.
                  Enable the 'Extra WM Actions' plugin in the CompizConfig Settings Manager, and assign a keyboard shortcut for 'Toggle Fullscreen' - use that shortcut to get apps fullscreen and the flickering goes away (though you may have to toggle it fullscreen a couple of times if it appears corrupted).

                  Comment


                  • #59
                    Software independent hardware support?

                    Originally posted by bridgman View Post
                    Cleric;

                    The biggest part of our Linux market is workstation, which realistically needs closed drivers today and in the future.
                    CLOSED as in "proprietary, secret, undisclosed, moonless night under a tree in the desert" CLOSED, or CLOSED as in "ATI" supported?

                    From what I can see there is no reason at all the "driver" can't be installed ON THE CARD making it "autonomous" and therefore usable to any "operating" system. A simple translation stub could then be written to support various operating environments.

                    At the moment the biggest impediment to fully autonomous hardware isn't the technology, it's MICROSOFT and it's "marketing" influence. Once hardware moves to a serial bus design (no more PCI, AGP PCIe, ATA, IDE, EIDE etc) there is no reason at all for a main processor to even have access to video RAM. Processors are inexpensive. It's the coordination of all the differing views of the people trying to use the computer as a vehicle for profit that causes this mess, not technology.

                    How about an "autonomous" serial bus processor, driving data across an open standard serial bus using a hardware based data format on an open standard system board. Make, or LET, the hardware manufacturers compete based on value, not software support. It's unrealistic to expect any hardware manufacturer to support every possible use for their device in the current business environment. Then the manufacturer can supply a fully autonomous subsystem with ON CARD software to interface with the open standard serial bus which then interfaces with every other device using an open standard protocol. How they implement the card is their business. A programmer then has no worries whether his video code will work. If it compiles and loads, it will run...in any hardware supported environment.

                    Add an autonomous code translator (for each specific processor instruction set installed on the open standard system board) to the mix and software becomes independent of hardware and hardware independent of software... All doable with current technology. It's the social issues that get in the way. When nobody controls the entire market and everybody can compete for a piece of the action without unfair advantage or unsavory, "moonless night in the desert under a tree" business practices, we all benefit.


                    There is a fundamental problem when an "operating system" is trying to support a specific manufacturers hardware, especially when they are competitors in the marketplace. The end result is that it will never work the way it COULD work. How many good hardware designs were never implemented because of proprietary business practices. Are we a society of individuals working towards a developmental goal or are we a mass of individuals all trying to steal what we can from those few doing all the work?

                    How's that for a suggestion, and a response?


                    BTW, I'm still unable to get mplayer to play using AVIVO under linux and there seems to be no real information about when or even if it ever will work.

                    Comment


                    • #60
                      Originally posted by siggma View Post
                      BTW, I'm still unable to get mplayer to play using AVIVO under linux and there seems to be no real information about when or even if it ever will work.
                      I can't seem to get a clear answer on that either.

                      Comment

                      Working...
                      X