So you might be able to unify them, but I'd bet it won't look pretty. Of course, it depends on how dissimilar the chips actually are. IMHO the differences between radeon and r200 are too big to make unifying worthwile, I have only looked at the r300 driver briefly but the differences to r200 seem to be quite large too.
Documentation would be a large help here of course. Have any of the r300 developers asked ATI for the 3d docs? Or even unbowdlerised r200 docs. That would help greatly in seeing whether, for example, some of the r300 registers are also present on r200 and we just don't know it, per Vladimir's example earlier in the thread.
I asked ATI for 3d documentation early of summer 2004, as far as I know they have not decided yet. They did provide 2d documentation for R300 chips.
As a side note, last time I checked ATI had 3 Direct3d drivers for the chips too. They have a unified package to install, and they may (no idea) share large parts of source code, but there are 3 distinct dlls in the end.
Direct3D drivers are not really an apples-to-apples comparison since they'll try to factor out as many conditionals as possible for that last 0.03fps in 3dmark. fglrx is probably a more fair comparison, and fglrx covers r200 through r400 no problem. If we assume that that's the more maintainable solution from ATI's perspective, I have trouble seeing how distinct drivers would be more maintainable for us.
The thing is, it could very well be that one could port R300 driver to R200 cards, but I am somewhat certain that one cannot do the opposite.
And R200 driver works already, so this is clearly a task for later.
On the other hand, AFAIK, the tulip driver in Linux kernel was rewritten about 7 times (please correct me), so it would be a good idea to make the attempt.
There are many reasons:
* benefits of unification ajax has mentioned
* optimization - we are certainly not bothering with it too much
* having fun reachitecturing Mesa driver
* perhaps some improvements in ease of developing
+ perhaps some non-C code generation (I see python is being
used already, perhaps some ML or Lisp fans can contribute
as well) + facility for runtime generation of machine code -
for example have "slow switch variables" which, when
changed, write a "goto" instruction at the appropriate
place.* unexpected stuff that always shows up
best
Vladimir Dergachev
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
