> I really don't know. I have some sense that some caches are virtual > address based, so they have to be flushed when you change TLB entries, > and TLB flushes are also somewhat expensive. But this is the case > with ANY CPU context switch, and I'm not sure that it's any worse when > dealing with CoW stuff.
ARM has virtually indexed/tagged caches yes, and possibly some others . x86 and ppc at least don't have that problem :) but still, mmu operations can be expensive. Well, the good thing is, this is mostly a software issue and can be easily experimented with. > > I was thinking more about context switching, while may require also > > switching textures in/out vram. > > Like I say, if we have host backing stores, the transfers are cut in > half. Also, if we have centralized memory management, we can do this > swapping in a lazy way. If an app has 10 textures but uses only two > of them during its GPU 'timeslice', there's less thrashing (or none if > we haven't run out of vram). There is a big lack of a proper memory manager currently in the open source DRI, but that is known and is something that some people have been working on recently. Iain Romanick for example (works at IBM too but in a different part of big blue) has been doing some work on that. > One approach to take is to not necessarily have backingstores as long > as there is free vram. The instant vram fills, the kernel driver > switches tactics and starts keeping them. This will make downloads > happen at the beginning and then taper off quickly. Best of both > worlds. I think this discussion should be moved to the DRI mailing lists and include the DRI and Mesa folks who have been working on those issues for some time now, but then, there is no emergency. BTW. Do you have already some ETA and idea of the price of your FPGA based prototypes ? We may get a couple here in the lab to help with drivers. (The lab is IBM ozlabs, that is mostly the ppc kernel folks) Ben. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
