Ian Romanick wrote: > -----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.
It's not working for me here. But I found that I could easily disable SPU vertex processing by commenting out two lines in cell_context.c. Maybe we should add an env var to control that for now. > 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. Yes, I was tinkering with that yesterday when I prototyped SIMD Z testing. The current problem is the xmesa_display_surface_tiled() function will need some work to rearrange things at the micro-tile level. Eventually, we'll probably store colors in SOA format (RRRR, GGGG, BBBB, AAAA) too. If the color buffer needs extensive swizzle/tile transformations prior to dislay, it might be interesting to apply the SPUs to that task. > 2. Implement a real-time assembler for the SPUs. Zack was looking into LLVM support for PPU-side vertex shader codegen. It should be a relatively straight-forward task since we've had LLVM generating x86 vertex shader code and LLVM supports PPC. The next step would be to use LLVM for SPU code. > 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! Zack, have you looked into this? For the first phase of this project, codegen for arbitrary pixel shaders isn't a priority. I want to concentrate on the overall rasterization architecture in terms of SPU/tile assignment and getting max throughput on basic smooth shading and simple texture mapping. Having LLVM for that would be nice, but probably not essential. So, in the near future I'll be looking at the tiling mechanisms and SIMD-izing more of the triangle setup code. -Brian ------------------------------------------------------------------------- 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
