[Mesa-dev] r600g plans

[Jerome Glisse]

On 07/24/2010 11:36 AM, Tom Stellard wrote:
> On Fri, Jul 23, 2010 at 08:09:46PM -0400, Jerome Glisse wrote:
>    
>> On 07/23/2010 07:11 PM, Corbin Simpson wrote:
>>      
>>> On Fri, Jul 23, 2010 at 3:49 PM, Jerome Glisse<glisse at freedesktop.org>   wrote:
>>>        
>>>> Just heads up on r600g plan, i removed the compiler stuff it was getting
>>>> messy
>>>> and kind of stopped anyone else from working on other part of r600g. So now
>>>> there
>>>> is a very simple&   dumb tgsi ->   r600 assembler that does work and can run
>>>> glxgears
>>>> and couple others non textured demos. I want to freeze r600_asm* stuff as i
>>>> plan
>>>> to reuse at latter point with a proper optimizer (thought there is a couple
>>>> of
>>>> thing missing in it like splitting alu node when reaching the 256dwords
>>>> limit).
>>>> So now if you want to add opcode the only file you need to touch is
>>>> r600_shader.c.
>>>> Also i would like to avoid any kind of work on optimizing what it spit.
>>>>
>>>> I am going to add texture support over the next few days (target being
>>>> tri-tex,
>>>> multiarb, tunnel, tunnel2 at that point i think quake engine should run).
>>>>
>>>> Todo list (kind of sorted):
>>>> - texture support
>>>> - use const buffer rather than cfile
>>>> - avoid recompiling the shader at each draw command (would improve speed a
>>>>    lot)
>>>> - stencil support
>>>> - support more states (blending, alpha, rasterization, ...)
>>>> - geometry shader
>>>> - tiling support
>>>> - color mask support
>>>> - hyperz
>>>> - a proper compiler
>>>>
>>>> Feel free to pick something and have fun.
>>>>          
>>> You're awesome as usual. Can we talk about maybe some common
>>> optimizations to r300g and r600g (and maybe others) that can be done
>>> in TGSI? Code sharing is fun, and I *really* don't want to see
>>> features fall by the wayside just because the shader compiler needs
>>> work.
>>>
>>> ~ C.
>>>
>>>        
>> When i first looked at optimization i looked at r300 compiler, but
>> thing is i want to try a different approach that would be very hard
>> to apply to r300-r500 hw. Basic idea is to do all optimization as
>> scalar, and repack the instruction after. The repacking is more or
>> less easy on r6xx and after but it's really tricky on r3xx-r5xx.
>>
>>      
> Two Questions:
>
> 1. You mentioned in another mail message that you have started working on a
> r600g compiler.  Is this working being done in its own branch somewhere?
>    

I will push to my own repo as a glsl branch, i will use the work from
intel as fronted and also because it allow to test the compiler without
backend which is nice.

> 2. Have you considered using SSA form once you've converted everything to
> scalar?
>
> -Tom
>    
Yes it's SSA straight from the ground. I will write down the layout of
the compiler as time permit. The tricky part is register + instruction
packing that somethings that was never done (at least in open academic
work) i have been banging my head on this and thought about abusing
some of the register allocation, state of the art, algorithm in weird way

Note that we don't need registers allocation as if a program need more
register than hw provide it's good to consider the shader as non runable.

There are also few challenges that i don't want to address now, like 
breaking
dot product or other similar things.

Cheers,
Jerome