[Mesa-dev] [PATCH 00/19] i965/fs: load_payload on Gen7+.

[Connor Abbott]

On Tue, May 27, 2014 at 9:47 PM, Matt Turner <mattst88 at gmail.com> wrote:
> Here's a respin of my load_payload series from mid-April with some
> feedback from Ken addressed and some bugs fixed.
>
> This series is available in my tree (with a few unrelated patches
> before it)
>
>    git://people.freedesktop.org/~mattst88/mesa tex-sources
>
> This is a prep series for implementing SSA in the i965 fragment
> shader backend.

I wonder how SSA in the i965 backend will interact with my SSA in GLSL
IR series? I've recently re-started work on this after my school work
started winding down, and as of now here are work items remaining I
can think of:

1) Add unit tests for the conversion to SSA
2) Make the conversion out of SSA not suck as much, esp. with respect
to writemasked operations (this is pretty difficult, as apparently
it's still an unsolved problem that to my knowledge no one from
academia has tried to tackle...)
3) Add some trivial SSA-based optimizations (dead code elimination,
copy propagation)
4) Add more complicated optimizations like CSE, constant propagation,
GVN-GCM... I believe some of these, especially value numbering, depend
on a flat IR to work, so this might be a lot harder to do.

I propose that I just do #1, post a new patch series with Paul's
comments on the original one addressed (that would probably take less
than a week), and then you can use the opt_to_ssa pass to avoid having
to duplicate that logic that in the backend since it's pretty
complicated. So it would look like:

GLSL IR -> opt_to_ssa -> SSA-ified GLSL IR -> i965 fragment shader backend

We would have to modify the pass that scalarizes the GLSL IR to work
with phi nodes and ir_quadop_vector expressions, but that wouldn't be
too difficult. That way we would have an immediate user of the SSA
stuff while being able to make it useful for everyone else in the long
term.

>
> I haven't done any testing on Gen < 7, but I think everything
> should still work afterward on those platforms. While we won't
> generate load_payload instructions from the texture visitor, we
> may generate them from the cubemap fixup and from CSE. Both should
> be safe since their destinations are generate purpose registers,
> not MRFs.
>
> I'd be nice to extend this to MRFs, since as I've planned it this
> work will be necessary for SSA in the fs backend.
>
> total instructions in shared programs: 1686122 -> 1677922 (-0.49%)
> instructions in affected programs:     635490 -> 627290 (-1.29%)
> GAINED:                                20
> LOST:                                  0
>
> A small handful of shaders gain an extra instruction or two.
>
> I'd really like to get some R-b tags this time around, since this
> series is necessary for the SSA work I've been anxious to get back to
> for a while.
>
> i965/fs: Add and use an fs_inst copy constructor.
> i965/fs: Disable fs_inst assignment operator.
> i965/fs: ralloc fs_inst's fs_reg sources.
> i965/fs: Store the number of sources an fs_inst has.
> i965/fs: Loop from 0 to inst->sources, not 0 to 3.
> i965/fs: Clean up fs_inst constructors.
> i965/fs: Add a function to resize fs_inst's sources
> i965/fs: Add fs_inst constructor that takes a list of
>
>    Preparatory work and infrastructure for instructions with
>    variable numbers of sources.
>
> i965/fs: Add SHADER_OPCODE_LOAD_PAYLOAD.
> i965/fs: Lower LOAD_PAYLOAD and clean up.
> i965/fs: Use LOAD_PAYLOAD in emit_texture_gen7().
> i965/fs: Apply cube map array fixup and restore the
>
>    The main implementation of load_payload on Gen7.
>
> i965/fs: Only consider real sources when comparing
> i965/fs: Emit load_payload instead of multiple MOVs for
> i965/fs: Support register coalescing on LOAD_PAYLOAD
> i965/fs: Perform CSE on load_payload instructions if
> i965/fs: Copy propagate from load_payload.
>
>    A series of patches to teach our optimization passes
>    about the new virtual instruction.
>
> i965/fs: Perform CSE on texture operations.
> i965/fs: Optimize SEL with the same sources into a MOV.
>
>    A couple more optimizations enabled by this series.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev