-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is an obvious need for some sort of data cache on the SPEs in the Cell driver. I've done some research on the subject, and I think I've got a plan. I wanted to bounce it off folks before I move too far on an implementation.
My current thinking is to use the software cache code included in the Cell SDK. It has some shortcomings, but I believe that it will fill the gap for now. There are a couple performance quirks with the SDK cache and it doesn't provide an interface to mark parts of the cache dirty (i.e., areas of memory that have been modified by the PPE. There is a workaround for the later. Ultimately, I believe that we will need to write a custom data cache manager from scratch. I'm not convinced that we know enough about how that cache will be used to effectively design it right now. Using the SDK cache should get us to the "good enough" point while we collect that data. The usual way of using the SDK cache is to instantiate a separate cache for each type of data being cached. The graphics pipeline naturally segments data usage, so we want to be able to evict data from one stage when another stage is active. In other words, we want to be able to evict vertices from the cache to fit more textures in the cache during fragment processing. Because of this, I propose using a single, large, unified cache. There would be several generic accessors and several specialized accessors. In particular, there would be a fetch_tile_from_cache accessor. The biggest hurdle is going to be marking data modified on the PPU as dirty. Even though it requires walking the internal cache data structures, marking the data dirty isn't the problem. The problem is getting the correct notification from the PPU that the data has been dirtied. It looks like most types of data have a distinct "bind" operation. I believe that we can conservatively mark an entire region as dirty each time it is bound. I'm not sure, however, that bind calls are made for all types of data or that the bind calls are always performed when the data might be dirty. I expect a lot of experimentation and debugging "fun" here. I'm going to try and knock out an initial implementation in the next day or two. I'm going to wire it into the various parts of the vertex shader infrastructure (i.e., attribute fetch, uniform fetch, and instruction fetch) that read data from main memory. At that point either I can wire it into tile fetch or someone can beat me to it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHvGfsX1gOwKyEAw8RAp9lAJ4tx8lVBkX2Cp2ZIoC7JO8S+VffcwCfZJQO WskYp88JWCISL8gKy2pbYRo= =cvuZ -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
