[Mesa-dev] [RFC] i965/dbg: Expose cases hitting a presumably dead optimization

[Pohjolainen, Topi]

On Fri, Mar 11, 2016 at 05:59:37PM -0800, Jason Ekstrand wrote:
>    On Fri, Mar 11, 2016 at 4:40 AM, Topi Pohjolainen
>    <[1]topi.pohjolainen at intel.com> wrote:
> 
>      The logic iterates over param[] which contains pointers to
>      uniform storage set during linking (see
>      link_assign_uniform_locations()).
>      The pointers are unique and it should be impossible to find
>      matching entries.
>      I couldn't find any regressions with test system. In addition
>      I tried several benchmarks on HSW and none hit this.
>      I'm hoping to remove this optimization attempt. This is the only
>      bit that depends on knowing about the actual storage during
>      compilation. All the rest deal with just relative push and pull
>      locations once the actual filling of pull_param[] is moved
>      outside the compiler just as param[]. (Filling pull_param is
>      based on the pull locations and doesn't need to be inside the
>      compiler).
>      Any thoughts?
> 
>    I'm not 100% sure what you're trying to do, but I have a branch that
>    may be of interest:
>    [2]https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/i965-uniform
>    s
>    The branch enables support for pushing small uniform arrays.  Among
>    other things, it redoes the way we do push constants and gets rid of
>    some of the data tracking in the backend compiler.  The big reason why
>    I haven't tried too hard to get it merged is because it regresses Sandy
>    Bridge just a bit.  I know I've seen and fixed the bug before in an
>    alternate attempt, but I don't remember how.
>    I'm going to be refreshing it soon because we need indirect push
>    constants for the Vulkan driver.  (The branch is already merged into
>    the Vulkan branch.)

I'd like to stop filling param[] before compilation. This is really not
needed by the compiler as it deals with pull and push constant locations,
i.e., positions in the push and pull files. Actual uniform values and their
location in the uniform storage are not needed until actual pipeline upload.

My plan is to move the iteration over the core uniform storage to pipeline
upload time. We can fill push and pull buffers directly without the need of
storing pointers to param[] in the middle. Not only makes this things simpler
and more flexible in my mind, does it give us the possibility to upload
floats with 16-bit precision instead of 32-bits. Current upload logic only
gets pointers to 32-bit values without knowing if they should be represented
with 16 bits let alone whether the values are floats or integers to begin
with.

Your series is not in conflict with this - I'm sinply moving push_constant_loc
and pull_constant_loc into stage_prog_data and using them in the pipeline
upload when iterating over the core uniform storage. You are just changing
the contents of push_constant_loc/pull_constant_loc.