From: Vladimir D. <vo...@mi...> - 2005-02-04 20:52:56
|
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 > |