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<gli...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
