why would you throw away stuff in scenario 1? I don't see that. I fact, I think this scenario is the best reflection of reality: r800 differs only (mainly) in register offsets. it actually exploits the major similarities in the chips.
Originally Posted by smitty3268
If you loose stuff in 1 then you'll also loose the same stuff in 2...
beside, if classic mesa driver can be unified for r300-evergreen then a gallium driver can probably also be unified!
there is no future? there's always a future: maintenance of the driver! I have learned to never underestimate that effort: every project stage increases software effort 10-fold... Any reuse will pay itself back very quickly...
Originally Posted by bridgman
Even now I have very strange and unreproduceable weirdness in my T60 laptop with X1400: sometimes the gfx get into a state where the whole system goes into major stutter mode: work for .1 second, hang for 1 second, repeat. Switching to text mode (KMS enabled) and switching back to gfx mode usually fixes it. Once someone fixes this bug it must be applied over multiple drivers in your copy scenario. wouldn't it be better if it were only 1 driver? :-)
if classic mesa driver can be unified for r300-evergreen then a gallium driver can probably also be unified!
anyway, I really appreciate the work you and the rest of the guys are doing. you're interaction with the community is wonderful, keep up the good work!
But... but... the classic mesa driver is *not* unified that way today. The r300 driver covers 3xx, 4xx, 5xx and the r600 driver covers 6xx, 7xx and (maybe) Evergreen. There are no plans to merge the r300 and r600, either in classic or Gallium3d form.
Again, all we're saying here is that burning cycles to keep Evergreen in the same "classic" driver as 6xx/7xx only makes sense if we do *not* move to a Gallium3D driver, since the G3D driver would be structured differently anyways. The only thing that's different now is that we separated out the "get Evergreen support running" work from the "make a merged driver" step, which lets Evergreen support get out faster and avoids investing time in a maintainable classic driver if we're going to jump across to Gallium3D immediately anyways.
Sure, but the point is that we may not be maintaining *that* driver. I agree completely that investing in improving maintainability of the driver we are going to maintain is a Good Thing, but it's not decided yet whether the driver we maintain is going to be the "classic" one we use to deliver initial support or the Gallium3D one.
Originally Posted by fhuberts
Personally, I think doing solid ground and then building there is better, than maintaining both "houses" half-alive. Time passes, new generations come out...
I would vote for getting the code out in the open as soon as possible. I guess that probably means a separate dri driver for Evergreen.
Originally Posted by crazycheese
Wow, it's amazing how many armchair coders we have here at phoronix. Everyone seems to think the driver developers are really stupid...
I'm not saying whether it's the best plan or not, I really am not in any position to know. But I do trust the actual developers to make the right decision. This isn't rocket science, code duplication and the tradeoffs involved here are pretty basic stuff when it comes to software management.
Anyway, to the people talking about keeping both houses alive, or maintaining this in the future, you're completely missing the point. Which is that this copied driver will be deleted in a month, that it's a private experimental driver that will never be supported by anyone. You guys would never have even heard of this if bridgman hadn't announced it, it just would have been another branch of code that came and went silently.