On Fri, 4 Feb 2005, Adam Jackson wrote:
On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:maybe it makes sense to start including r300 in mesa. You guys have made a lot of progress. It doesn't have to be built by default, and the development can still happen in r300 cvs (just sync them from time to time), but it might help with the testing since snapshots would be made nightly. OTOH, it's still fairly experimental.
Sorry did not reply earlier, I had to take some time to think about this.
The biggest reason at the moment against including R300 driver in Mesa CVS is that the code is a mess. There are r200 files that are not being used in any way and large sections of code simply cut'n'pasted from R200 driver with pieces commented out to allow everything to compile.
I would really like to see the r300 code not get its own driver. Unified drivers are a good thing, and radeon/r200 is bad enough. Unfortunately I don't know a good way to make sure they don't diverge more than they already have. I think the current development method is working fine for now, but that the end goal should be to fold the r300 code back into r200.
The second big reason is that we cannot simply include Mesa driver alone - it would have to be accompanied by changes to the DRM driver. R300 DRM driver is stabilized as far as experimental development is concerned, but it is far from perfect from security standpoint (we basically allow almost arbitrary commands as we did not know what we would need when we started).
Here again, ideally this would get folded upstream too, once it's at least secure.
I can't really mandate a policy since I haven't been contributing much to r300, but I would like to hear how people think this should progress.
Folding DRM driver is not difficult, in fact currently there is just one extra file with r300-specific code.
As for folding R300 driver, we'll see how things turn out. It is hard for me to imagine how this folding could take place - albeit it might turn out to be not too bad.
An incomplete list of issues:
* shaders are different from R200 hardware
* the hardware state is different with registers in different
locations.So R200 code like
rmesa->hw.ctx.cmd[CTX_RB3D_CNTL] & ~R200_PLANE_MASK_ENABLE;
won't work as there is no RB3D_CNTL that we know of.
It is really quite bad - there are numerous R300 registers with
offsets above 0x4000 while the largest R200 register I see used in
Mesa driver is R200_RB3D_CBLENDCNTL at offset 0x3220. * I don't think we need software TCL code to be separate - as I
understand this code is in R200 driver because initial driver
did not support hardware TCL. (We do not support it either, yet)So unifying would require thorough understanding of both hardware platforms and Mesa drivers in general, and will likely imply a rewrite of
large portions of both drivers.
On the other hand, the texture allocation code can be shared almost entirely. Vertex processing can also be shared with small effort - albeit it would be nicer to use one of the templates, if any are available for that purpose.
best
Vladimir Dergachev
- aajx
------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
