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. 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. > There's a fair amount of infrastructure (e.g., tile cache, program > loaders, etc.) that are needed too. > > My thinking is to slightly modify the existing code and run the gallium > shader VM on an SPE. I believe this is the fastest route to get > "everything" on the SPEs. This will provide a good test bed for the > tile cache and other SPE-specific infrastructure components. > > Then as an SPE backend for the shader compiler becomes available we can > convert each part to use native generated code instead of the VM. Yeah, I'd initially just use the tgsi_exec interpreter on the SPEs until we can generate native code through LLVM. -Brian ------------------------------------------------------------------------- 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
