I'm not so convinced that r200 and r300 driver (and radeon, for that matter) really should be only one driver. Why is it that bad to have 3 drivers? Those chips just ARE different. Sure, the 2d parts are more or less identical and certainly should be only one driver, but that's already the case. DRM should probably be the same too, since the differences needed are pretty much limited to what packets it accepts. But I'm not exactly sure how you'd unify the dri code. While you cannot deny that the drivers indeed look very similar, there are still a lot of differences. You will inevitably end up with lots of "if Radeon do that, else" code (or did you have #ifdef's in mind, so you would share the same source files, but would compile it to 3 targets in the end?).
No, definitely not #ifdef hell, down that road lies madness.
Definitely agree here :-).
We have this already though, in several drivers. Savage3D and Savage4, Intel 830/855/915, Voodoo3 and Voodoo4/5 even. And I would expect that the differences in features between chips corresponds well to GL features for the most part, so they're natural boundaries for conditionals anyway.True. I think though savage3D and Savage4 are quite similar, so are
Voodoo3 and Voodoo4. The intel driver is a good argument however, i830
and i915 are quite different. It still manages to share quite some
files. I'm not so sure though a unified radeon/r200/r300 driver would
actually share a lot of code. Some stuff is certainly identical for all
of them (things like lock code, parts of cmdbuf/ioctl code, texmem,
sanity, maybe vertex submission (maos_arrays), and probably other stuff
as well). That's actually more than I initially thought, so maybe it
would be worth it.
Though if r200 and r300 are going to be unified, I'd definitely suggest
that radeon gets unified too. The code which can be shared between r200
and r300 is likely going to be pretty much the same as the code which
can be shared between radeon and r200, I think. In fact, if one would now unify radeon and r200 driver, this might allow the r300 driver to be more easily added a bit later. Any volunteers ;-).
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.
That's a good point.
As an example of what the non-unified road looks like, look at the glide source. Despite successive chips being pretty much strict supersets in terms of functionality, they clone the entire tree for each chip. I suspect the effort required to keep drivers unified is worth it in the long run.I think glide is a very good example when you really should unify the code, since really pretty much all code could be shared for all chips. I would suspect r100/r200/r300 are quite a bit more different, and less of the code will be the same. But maybe you're right, and in the long run it would really be beneficiary. As Ian said, the intel driver seems to be a useful model. It shares the common code, and still nicely separates the code when the implemenentation needs to be different.
Roland
------------------------------------------------------- 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
