<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Implement a NIR -> vec4 pass"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=89580#c4">Comment # 4</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Implement a NIR -> vec4 pass"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=89580">bug 89580</a>
              from <span class="vcard"><a class="email" href="mailto:elima@igalia.com" title="Eduardo Lima Mitev <elima@igalia.com>"> <span class="fn">Eduardo Lima Mitev</span></a>
</span></b>
        <pre>We have been making progress, a bit slowly at the beginning as we were getting
comfortable with NIR, but more steadily lately.

We have a very basic shader working, and the status roughly is:

- By now we are reusing brw_vec4_visitor class, and adding the implementation
of our NIR methods into a separate file brw_vec4_nir. It is mostly boilerplate
now, and we hook into it from brw_vec4::run().

- Intrinsics load_input and store_output partially working. Right now we have
only support for one attribute (expected at offset 0) and one output
(gl_Position). This is for simplicity and also because until a few days ago,
there was a weird bug causing const_index[0] of all inputs and outputs to be
zero instead of the driver offset. I manage to track down the problem to
nir_lower_io code, but then after checking with master, I saw it has been
fixed. So I'm currently extending load_input and store_output to handle any
number of attrs/outputs.

- ALU instructions: Antia has implemented a lot of these already.

- load_const: For this, we did the same as fs_nir, allocating a new register
and loading the constant on-demand, as part of get_nir_src(). We then realized
that this is not optimal for us, since we can emit vector instructions and save
a few movs. So we are planning to update the current implementation to have a
map with a register for each SSA variable, and pick from that table when
emitting. Thoughts on that?

This is pretty much it. I have also looked into uniforms and system values, and
after implementing the other intrinsics I feel those will be go very similar.

We have also being tracking changes upstream that affect us, more or less
regularly. And there have been quite a few :), it feels like shooting a moving
target sometimes.  

We already had in plans to put together a more or less coherent branch by the
end of this week, so I just created:

<a href="https://github.com/Igalia/mesa/commits/nir-vec4">https://github.com/Igalia/mesa/commits/nir-vec4</a>

after rebasing master and fixing a few things. Notice that many of those are
just dirty commits from our daily development, so it probably makes sense only
to look at it as a snapshot of where we stand. Notice also that there are work
we have done which is not in that branch, like a new implementation of
intrinsics load_input, store_output and partially uniforms, and likely more
ALUs.

Thank you beforehand for the feedback!</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>