-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: | Ian Romanick wrote: |> |> 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. | | I wasn't planning on this sort of thing for a while since we weren't | planning on doing vertex transformation on the SPUs for a while. But | you're already there so I can see the need. | | BTW, it would be interesting to see a "memory budget" for SPU memory. | I'm really not sure how much of the 256KB is being used for code so far | and how much we'll have left over for bulk data (vertex/texture/fb tiles). | | From reading the Cell devel forums, it seems like a bit of a black art | to determine memory usage on the SPUs.
And it's only going to get worse, I expect, as we start uploading dynamically generated code / compiled shaders. |> 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. | | Coincidentally, I found a bug like that today involving texture updates | not getting noticed by drivers. There probably aren't too many lurking | bugs like that though. | |> 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. I have an initial implementation in now. I'm trying to adapt it for texture use (as outlined above), but I'm having trouble finding suitable tests. Are there any tests in Mesa that are known to work? The *only* one that I can find that works even without my changes is trivial/quad-tex-2d. Many of the tests in progs/demos, such as tunnel, ~ fail with "cmd_render(): assertion total_vertex_bytes % 16 == 0 failed.", and others, such as texobj just produce incorrect results. Suggestions? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHvfwjX1gOwKyEAw8RAi2PAKCIrWk1Kk5bkkKnHfKaJK9CuarjoACgkb/2 FkA3eKieq6Wxx1rI7NsQVPk= =LMCW -----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
