-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just finished pushing a ton of commits that get the shader VM running on the Cell's SPUs. Right now it is only used for vertex processing...and gears runs! :) Since various other folks are busy making changes to the fragment processing side of things, I don't intend to implement fragment shaders.
My next Cell related work items are: 1. Implement a software cache for non-tile data. The way that uniforms, attributes, and program instructions are currently fetched from main memory is not good. A caching / prefetching mechanism would do wonders for its performance. Look at the existing fragment code, it seems like we should enhance the tile cache to "microtile" as well. That is, rearrange the data on upload / download so that the SPUs can access 2x2 quads linearly within a tile. That would *greatly* simplify all the code that operates directly on the framebuffer. 2. Implement a real-time assembler for the SPUs. 3. Start dynamically generating code for the post-fragment processing part of the pipeline. At some point someone needs to take a look at the SPU support in LLVM. I know that some code was committed, but there was a long list of caveats. It would be nice to know if the existing support there will suit our needs. If not, it should be pretty easy to convert the VM opcodes directly to SPU code. The SPUs have enough registers that we wouldn't even need a register allocator! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHoVABX1gOwKyEAw8RAndZAJ9z4TyStCaaNkaUaUyBan7kz/iwTACgiWqy ssI/sWOzkADLHgbZIfHLQQs= =Vj5Q -----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 [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
