Re: [Mesa-dev] r600g plans
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 Glissegli...@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
[Mesa-dev] r600g plans
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. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g plans
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 the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g plans
Sounds very much like what nv50 needs/does. I sense opportunity. :3 Posting from a mobile, pardon my terseness. ~ C. On Jul 23, 2010 5:09 PM, Jerome Glisse gli...@freedesktop.org wrote: On 07/23/2010 07:11 PM, Corbin Simpson wrote: On Fri, Jul 23, 2010 at 3:49 PM, Jerome Glissegli... 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. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
