Keith Whitwell wrote: > > I suppose I'm basing my assumptions on sarea usage that is not there right > > now (a private sarea per context system rather than the temporary copies > > which we have now), and assuming a full featured t&l card will have > > somewhere around 4-16k of possible state. (WARNING: The following is > > slightly simplified.) The private sarea version only has 1 read and 1 > > write involved (one read from the sarea in the kernel, and one write to the > > dma buffer in the kernel), the current sarea version has 2 reads and 2 > > writes involved while I would assume an ioctl version has 2 reads and 3 > > writes (one read from the temporary state, one write to the sarea or ioctl > > argument structure, one read in the kernel of the sarea or one read and > > write for the ioctl, one write to the dma buffer.) All things considered I > > believe the current sarea usage and the ioctl version are pretty much > > equal. Perhaps even with careful implementation the ioctl version can be > > done with 2 reads and 2 writes as well. > > It's possible to consider a scheme that stuffs ioctl numbers and ioctl > structs into a shared memory area between the 3d client and the kernel. That > gets away from the current bad situation of having a fixed but different > sarea layout for each version of the kernel module, but allows any benefits > of a reduced-number-of-copy scheme. > > I don't propose implementing this, but it could be a future addon to a > pure-ioctl interface if performance ever turned out to be a problem. > > Note that we will get much better performance gains simply by getting 3.5 > into the kernel and xfree (and bringing those drivers that haven't > implemented all the 3.5 goodies up to speed).
I do agree with you here, and I can invision some interesting things that using a shared memory area for command passing could do for performance. This addresses my concern and no longer see a reason why we need a versioning scheme. I personally think that having a backup plan is always a good idea, however it might be a better idea to remove the versioning ability since it could incourage bad behavior. I'll back either way you decide. -Jeff _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
