Keith Whitwell wrote: > On Sun, 14 Oct 2001 22:39, jhartmann wrote: > > Keith Whitwell wrote: > > > Jeff, Others, > > > > > > I've been reviewing the work in the 3.5 branch for backwards > > > compatibility and to me it looks like we can do it with a lot less > > > effort. Here's what I'm proposing, in one simple sentence: > > > > > > Instigate a rule where any released ioctl will always be > > > supported, with the same semantics and interface. > > > > > > This sounds simple and has a few consequences. First and foremost is > > > that the use of the sarea for passing parameters is deprecated. Any new > > > ioctl will take all its parameters through the ioctl struct, even if that > > > means some performance issues. I don't think it will however. > > > > With the current generation of hardware (and the features in our drivers) I > > think your probably right. Unless a full t&l driver is released using the > > DRI, then perhaps this might become an issue again. I propose that the > > ability to set versioning on the interface remains in the codebase, but is > > unused in case its needed at some point. > > I'm talking specifically about the tnl work I've already done. The sarea is > a dead end and no performance gain. > > Even if we had a versioning scheme the effort of supporting multiple > different layouts of the sarea makes the concept unmentionably ugly and > unworkable. > > I'd like to support your compromise, but I don't like where it's leading - > it's tacit acknowledgement that we will want to do something in the future > which is just plain bad.
If you have demenstrated that this is the case then we should remove the version system then I guess. I do want to voice my concerns though by writing out my argument fully though. 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. I guess I'm concerned that if we ever have to move around large amounts of state these extra read and write operations will hurt us. If you don't think we should be concerned about this (you have more experience on the amount of state on modern tnl cards), then consider this entire argument flawed. I do believe that the ioctl system and our current usage of the sarea are nearly equal (if not equal if carefully implemented), but the ioctl system can never approach the more efficent per context usage of an sarea. Since we aren't using per context sareas now (and I guess the fact that its unlikely this will ever happen is valid as well), perhaps this is just a strawman argument. -Jeff _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
