Announcement

Collapse
No announcement yet.

Another New KMS Graphics Driver Tips Up

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

  • #11
    Originally posted by mattst88 View Post
    Poor journalism.

    .

    Dave wrote the AST driver as well. The G200 driver is based on the Matthew Garret's Cirrus KMS driver for QEMU. The Cirrus driver is based on my GLINT KMS driver, so the G200 driver is as well.

    Well its bits of both really.

    I wrote AST, then took the MGA and next cirrus code from mjg based on your code, I then transmuted them and caluclated their load bearing tangents. (Sorry watching peppa pig), I then remodeled the mga/cirrus code to look like my AST code and used the same memory management scheme as my AST code, so all 3 drivers nearly look the same apart from the crtc mode setting and gpu init functions :-)

    Comment


    • #12
      Originally posted by AJenbo View Post
      Is there any docs for the desktop cards? Might be fun to try and get the driver working with some of those.
      In addition to the docs, there is the UMS code and matroxfb kernel drivers available for reference.

      Comment


      • #13
        Wow, so in a few years I might be able to dust off my matrox G400 and have KMS for that card?

        Comment


        • #14
          Originally posted by uid313 View Post
          Wow, the G200 is a 14-year-old graphics card and its seeing new device driver development work in the open source community.
          I wish we could say that for all these chips around... I wonder what that driver actually does and if Matrox ever published enough docs to do more than modesetting. Anyway, havin KMS-drivers is always a good thing.
          Stop TCPA, stupid software patents and corrupt politicians!

          Comment


          • #15
            @agd5f

            is it good to copy that much code? maybe combine em into one driver?

            Comment


            • #16
              Originally posted by mattst88 View Post
              Because you don't care about accelerating an old chip embedded in a server, while you get the benefits of KMS.
              - flicker free boot
              - faster VT switch
              - kernel errors visible if X hangs

              Now, which of these is important in a server?

              Comment


              • #17
                Originally posted by curaga View Post
                - flicker free boot
                - faster VT switch
                - kernel errors visible if X hangs

                Now, which of these is important in a server?
                RH/Fedora actually plans to ship no UMS drivers in the future, so they're writing KMS drivers for the hardware they care about. Without xf86-video-mga (say, if you're not running X), the only other option is matroxfb which doesn't support the G200.

                Also, you can do things like power down the graphics chip during DPMS to save energy. And since it's a server that's not typically attached to a monitor, that's basically always.

                Comment


                • #18
                  ZzzzzzzZZzzzzz.... if only RadeonSI got as much love as 14 year old hardware...

                  Comment


                  • #19
                    I could point out that HD7xxx has had KMS support for a while (ie a whole pile more love already) but I imagine what you really mean is "if only radeonsi got 1000x more love than 14 year old hardware instead of the 100x or so it gets today" so that the high level of functionality expected for the new card could be implemented as quickly as the modesetting-only expectations for 14 year old hardware" ?
                    Last edited by bridgman; 27 April 2012, 07:18 PM.
                    Test signature

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      I could point out that HD7xxx has had KMS support for a while (ie a whole pile more love already) but I imagine what you really mean is "if only radeonsi got 1000x more love than 14 year old hardware instead of the 100x or so it gets today" so that the high level of functionality expected for the new card could be implemented as quickly as the modesetting-only expectations for 14 year old hardware" ?
                      Yep. You read my mind. I'm so demanding, aren't I?! Wanting things that aren't there and not having the means to contribute more than bug reports, and continually complaining about it on these here forums. Well right now there's not very much to test, so I get to contribute zippo.

                      I'm sure some of the open source guys sometimes ask themselves why they work so hard for such an ungrateful user base that is perennially dissatisfied with the underperforming, buggy and feature-deprived effort (in the discerning opinion of the users, of course) that they roll out. Hey, it's a valid sentiment. I sometimes ask myself why I spend $550 and up on video cards every 2 years for a company that will probably not decently support my purchases with 100% working Linux graphics drivers on release day until 20 or more years from now, if indeed they ever get there. And who knows, by the time the driver support is there, hardware accelerated graphics might be obsoleted, either by advances in internet connectivity leading to everything being run by services similar to OnLive, or maybe we'll go back into a few decades of CPU-based rendering... it's hard to see where the tech is going. But in the here and now, I don't feel confident that I can get what I need to run this hardware the way I want to, and that is seriously making me reconsider my choice of brand.

                      I guess someday the volunteer developers will figure it's not worth their effort and pack up, and the open source division at AMD will get shut down, and I'll stop buying AMD video cards and just use Intel because it bloody works... everything comes to an end. I mean, that is, unless true excellence can actually be obtained with the open drivers? Excellence is extremely hard to define, but there's a certain point of quality after which adding more doesn't really make it any better; you've already completely satisfied your users. Proprietary-ness exempted, the best example I can think of is the Windows Nvidia binary driver. On the open source side, the closest I can think of is the Apache web server. Mesa is nowhere near sniffing the quality of either of those products though.

                      I wish I didn't have to be so demanding, but AMD imposes it upon themselves by releasing such good cards. You put it out there like a bait, and like a fool fish I bite the bait. What do you expect? That said, this fish is getting a little smarter after being caught and released a few times.

                      I want my card to do what it's capable of, on Linux, with open source drivers that mostly work, but for which I can contribute to if I have a pet peeve bug -- either with a patch or a good bug report (I've got a few actual bug reports under my belt that have been fixed, so thankfully my day job in QA is paying off for the community ). Unfortunately I can't really make much out of a KMS driver and drawing triangles in EGL, so until I can run some actual applications on RadeonSI, you won't see any bug reports from me.

                      Comment

                      Working...
                      X