> 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). Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
