Re: [Mesa3d-dev] Shader VM on Cell SPU

[Keith W. <ke...@tu...>]

Brian Paul wrote:
> 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.

Actually, I think I'd argue against this last bit (SOA color surfaces), 
suggesting instead that it be done if necessary on tile up/download from 
the SPE.

With proper care, it should only be necessary to do one download per 
tile per frame and no uploads, so this would work out more efficient 
than emitting SOA colors to memory and then later pulling them back in, 
unswizzling and re-emitting.

Keith