From: Vladimir D. <vo...@mi...> - 2005-02-04 23:04:55
|
> >> 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 |