Brian Paul wrote: > Ian Romanick wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> [EMAIL PROTECTED] wrote: >> >>> Looking in Internet about mesa3d optimization for Cell (PS3), I found your >>> mesa plan for cell gallium driver. What's is the status? exists some >>> public git repository? >> No code has been written yet. It has taken me a lot longer to get going >> than I had expected. Sigh. >> >> I've been digging through the gallium code a lot lately, and I think I >> have a plan to get things going. I'm curious to hear what Brian and the >> other TG folks think. >> >> Basically, there's a little bit of a chicken and egg problem. I don't >> see a clean way to carve off a chunk of the pipeline functionality to >> put on SPEs without either re-writing a big chunk of the pipeline code >> or getting it all on the SPEs. For example, I don't see a good way to >> break off TNL, triangle setup, or fragment shaders to put on an SPE. >> Each part of the pipeline seems very tightly integrated with the next. >> Unless I'm missing something? > > I haven't started on this yet either, but the basic plan I have in the > back of my head is > > 1. Basically, create/run a softpipe renderer on each SPE. Specifically, > it would be the sp_prim_setup code and all the quad processing code. > > 2. Everthing else (core Mesa, state tracker, T&L (draw module)) would be > running on the PPE. > > 3. A new piece would bridge the PPE/SPE parts. Basically, when the draw > module has some number of triangles buffered up for drawing, assign the > SPEs to screen tiles and tell them where the triangle buffer is. The > SPEs would grab a copy of the triangle data (with DMA) and use the > prim_setup/quad code to render the tris for the given screen tile.
Yes, with the necessary tweak to the rasterizer to restrict itself to the tile in question. > 4. The get_tile() interface would be used by the SPEs to get > framebuffer/texture tiles from main memory (with DMA). put_tile() would > send finished tiles back to main memory. > > 5. When an SPE is done rendering the triangles into its current tile, it > would move onto another screen tile. > > So for the initial version, only rasterization would be done on the SPEs. Before or in parallel with this, it would make a lot of sense to investigate the Cell SPE backend to llvm which has been produced elsewhere and evaluate its suitability for executing the shader programs Zack is building in LLVM. Sooner or later, generating texture samplers through llvm will also be necessary, and then you get to decide whether the texture sampler (and texture cache) lives on the same SPE as the rasterization pipe (and active tile) or a different one (larger texture cache, but communication costs and extra complexity). Presumably we'd do the local version first. Ongoing, it is my thought that the entire fragment pipeline should be passed through llvm and optimized for a particular state - but it can be a step-by-step process. Keith ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
