Announcement

Collapse
No announcement yet.

Cleaning Up The Linux Graphics Driver Stack

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

  • #31
    Originally posted by airlied View Post
    So a fork by any other name is? oh its a fork. I'm not sure the X.org split changed the XFree86 development model at all, I don't remember seeing XFree86 bugs with patches to their VIA driver bringing it up to speed with the unichrome changes.
    Of course you do not remember, you were nowhere near xfree86 at the time. At the time you just were the only volunteer for becoming the drm maintainer, there is little other traffic from you on xfree86.

    We had our driver build and run outside of both during the war. And when the dust settled, we were porting back released versions to the Xorg tree.

    And there was no way you could work with anyone else in the same tree?
    even though the featureset was othogonal, now let me guess the problem was with the people trying to contribute not with you? We've somehow managed in every other driver developed to do both modesetting and acceleration work at the same time in the same codebase. Now what makes unichrome special?
    You should ask the forkers that. I just refused to take in VBE based modesetting, with a lot of solid reasons as to why it should be refused. Remember, this was 2005, when even keithp was shooting everything modesetting down. And a year before you gave me crap over the too complicated output abstraction, and reinventing it for i2c based output chip driver modules, showing that you clearly missed the point already.

    Code reuse to save time was necessary, later review revealed most of that code was pointless, we still haven't gotten around to removing it all, but there was a number of pointless abstraction layers. The KMS code pretty much removes all of them, so I don't see the need to destabilise or cleanup the dead end that is DDX modesetting at this point.
    KMS happened a year later. You did fork.

    Well avivo was pretty much that, and supported more hw at the time than your first release. It actually helped us reorganise a lot of the -ati code and it really helped with getting r4xx stable as we only have reverse engineered atombios support up to that point.
    Avivo was not supporting more hardware at the time of our driver release. It just was not dealing with wiring up connectors much, while we were. Until we finally managed to write up the code to parse the atombios data tables, we had to go and maintain a board layout table of our own.

    you haven't really got the point, which is where are the communities that you are meant to build up around open source projects to stop them dying when companies pull people out because of their questionable reasons for being involved in the first place.
    With RadeonHD we did just that, from the very moment that we were allowed to do so by AMD/ATI. We immediately created the #radeonhd channel and the mailinglist (we needed a mailinglist for this immediately, which upon first asking was blatantly refused by daniels), we worked with phoronix from that point on too. You copied that in the next few weeks, to little initial success.

    Our community ended up producing a few very good results. Great example: You would not have had HDMI code at all today, if Christian Koenig hadn't done so for RadeonHD. Plus, he did so in a way that fully fused with the RadeonHD blockwise modularity concept, a concept even Alex couldn't grasp at the time according to Mr Bridgman.

    So please, stop throwing useless crap that can be proven wrong immediately.

    Unichrome stopped dead when you moved to work on RHD, and RHD has pretty much stopped dead since you went the other way and Novell people got re-routed.
    If this logical shortcut had any real value, it would just tell people how important and crucial a developer i am :P

    But it is not this logically simple.

    Unichrome "died" in the same way openchrome "died". Nobody cares about this hw much anymore. Difference between me and openchrome is that the openchrome people don't do much in the way of active development even when they are around.

    I don't think -ati or KMS would stop because I decided to do something different and similar for Alex or Jerome or Corbin or anyone else. The thing is to create a sustainable open source driver you need to create a community of developers and testers around it and for some reasons projects involving you this doesn't seem to happen.
    You never understood this community thing either. You copied this from radeonhd in september/oktober and beyond, and had a hard time coping after that too.

    Now, if both you and alex would give up right now, the activity levels on ati related topics would die down to radeonhds (which still sees some activity) straight away.

    Nobody else is doing the boring stuff.

    This is actually exacerbated by the fact that Mr Bridgman is not making real hw information available anymore. Nobody could fix up current code if this source of information dries up, let alone continue work.

    We specifically demanded that when we wrote our proposal to AMD, one of many reasons for providing documentation is that companies and people could continue, when for whatever reason, the information stream died out. This also benefitted AMD, as it would help give people confidence in the long term usability of their hardware.

    Actually I was just trolling because it was raining outside, Red Hat has a business model apparently that works, I'm not sure of the details but money seems to come out at the end.

    Dave.
    This i will never deny. Novell is a bank, and it tries to squeeze blood from the diamond that once was SUSE. That's not SUSE's fault, and a lot of SUSE people try to do the best they can under these circumstances.

    But redhat is not trying to sell the linux desktop at all. It is just using its money to make big statements and then forces the others to make a working product out of the proof of concepts and pipedreams, wasting a lot of resources in the process. I must admit, it's a very clever tactic.

    Comment


    • #32
      Originally posted by nwnk View Post
      That's a nice theory, but it's, uh, divorced from reality.

      The thread, for those who didn't read it, was here. I'm not sure where in that you're inferring anything like a "huge blowup" or "extreme reaction". It's a verbose response, but I figured it was worth giving the long form answer for posterity.
      I later learned that you had blown up over this via-via. Similarly i learned that you made one of your blown-up statements when the layoffs at SUSE Nue happened.

      I'd been fighting vm86 bugs intermittently at Red Hat since even before RHEL5 came out, starting with:

      * Fri Nov 3 2006 Adam Jackson <[email protected]> 1.1.1-48.2.el5
      - Build both x86emu and vm86 backends on x86. Prefer x86emu when running
      in Xen dom0. Add "Int10Backend" option to the ServerLayout section to
      allow runtime configuration. (#213151)


      ... a trick I am not especially proud of. The only reason we didn't switch to x86emu completely in RHEL5 was because vm86 was the tested path from the dawn of time, so it was at least a known quantity; switching could have introduced new bugs, and this is RHEL, so we're paranoid. But Fedora switched to x86emu everywhere literally five days later. Three, if you don't count the weekend.

      Now, having shipped that for twenty-four months, I felt pretty confident it was correct, so I committed the default switch upstream so I could drop a configure option from the spec file. You rightly called me out for not justifying it fully in the commit, though at that point I didn't really think "do the obviously correct thing" needed a lot of justification. But claiming the change (or the explanatory email) was the result of some internal strife is just fiction. The reality is that for two years I was the only person at Red Hat even remotely looking at the vm86 problem, let alone caring about it.

      I do find it amusing how you interpret everything as a conspiracy with backroom dealings and dirty secrets though. It's like every time you see hoofprints you think Illuminati unicorns instead of horses.
      The fact that you had issues with vm86 and therefor wanted to disable this are all good reasons, and i am sure that you would've had people agree with you soon when you proposed it somewhere public.

      My question was: "Where was this discussed?". Egbert had just spent some time fixing up vm86 with NX kernel support, and here that code was just labeled deprecated out of the blue. So, my very honest, direct, and perfectly reasonable question was: "where was this discussed?".

      We, and a lot of people with us, both know you made a big stink about me asking you this. And the reason for that is purely that this question exposed the wrong mode of working. A mode of working that is supposedly no longer possible today.

      Comment


      • #33
        Originally posted by libv View Post
        I knew that people would be spewing a lot of useless flack over this, and i also knew that you would be one of the more reasonable people. You do not have to outright believe me, i do not expect that, but i think that, in time, you will agree on many things stated/proposed in this talk.
        I suppose that's possible. But I used to be in your camp on this; when X was split I thought splitting Mesa would be a good idea too. Now that I've worked with things for awhile though, I've come to the conclusion that we've gone too far. Drivers should be more tightly coupled with the core they interact with, since updating driver APIs is often necessary to increase performance, add features and sometimes even fix bugs. If the drivers are separate, that means keeping around a lot of compat code, increasing the number of combinations we need to support and generally making things less stable.

        But that's just my opinion right now, in time maybe other approaches will become more feasible.

        Comment


        • #34
          Originally posted by libv View Post
          With a few changes in mostly the mesa repo, [...]
          Are you going to propose such changes on the mesa3d-dev list?

          Comment


          • #35
            Originally posted by MrCooper View Post
            Are you going to propose such changes on the mesa3d-dev list?
            Yes, i am working out some further details and a further proof of concept right now, and hope to have something presentable by the end of the week.

            Comment


            • #36
              Originally posted by spiritofreason View Post
              I beg to differ, Luc! I just did a couple days ago... but it was a pain. Is there a document somewhere that tracks which versions of modules are compatible?

              The autoconf scripts tend to take care of minimum versions, but when you want to build an older xorg-server so you can use the catalyst drivers, it's useful to know the maximums...
              If you want an Xorg that is easy to build then the JHBuild is fairly awesome: http://www.x.org/wiki/JhBuildInstructions. I do a full git head checkout and build every couple of days without much issue other than an occasional bad patch.

              Comment


              • #37
                Originally posted by Firebird347 View Post
                If you want an Xorg that is easy to build then the JHBuild is fairly awesome: http://www.x.org/wiki/JhBuildInstructions. I do a full git head checkout and build every couple of days without much issue other than an occasional bad patch.
                Daniel said during Luc's talk that the JHBuild should be broken and not used.
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #38
                  Will the video of this be freely available? (as opposed to just premium members - I am not sure how the videos work on here as there does not seem to be any tab on the site)

                  and if so, any idea how long it would take?

                  Either way, keep up with the good work with this site - it keeps me and many others well informed.

                  Thanks.

                  Comment


                  • #39
                    Originally posted by Michael View Post
                    Daniel said during Luc's talk that the JHBuild should be broken and not used.
                    I'd go with 'should be fixed' rather than 'should not be used'.

                    Comment


                    • #40
                      Originally posted by libv View Post
                      Unichrome "died" in the same way openchrome "died". Nobody cares about this hw much anymore. Difference between me and openchrome is that the openchrome people don't do much in the way of active development even when they are around.
                      Strange that, I'm pretty sure openChrome fixed a couple of fairly nasty bugs which hit the HP Mini 2133. I could be wrong, but my little netbook is working much nicer for the fixes. However, I was clearly mistaken, as there is no active development going on there.

                      Also, isn't OLPC using a VIA graphics chip? Not that it counts, no one cares about OLPC anymore...

                      Originally posted by libv View Post
                      But redhat is not trying to sell the linux desktop at all. It is just using its money to make big statements and then forces the others to make a working product out of the proof of concepts and pipedreams, wasting a lot of resources in the process. I must admit, it's a very clever tactic.
                      This sounds a little strange given that Bruker specifically list RHEL as the only supported Linux distro for their Topspin Software. No mention of SUSE, nor Ubuntu. Varians MestRecNova software also only seems to mention RHEL as a supported Linux distro. Now I will freely conceded these are both A) specialized apps, and B) expensive, but they are also the only two apps worth mentioning in their field, so strange they bother supporting a distro that doesn't do desktops.

                      It seems to me that Red Hat aren't very interested in pushing Linux desktops for home users, which isn't very surprising as their is no money there. Let us note which distro needed to do major layoffs...

                      Ok, that's only one application, but it's the only field I really have the experience to point at that clearly and say "See, RH, no one else".

                      Comment

                      Working...
                      X