[Bug 89580] Implement a NIR -> vec4 pass

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89580

--- Comment #5 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Eduardo Lima Mitev from comment #4)
> 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?

Yes, it's much better to use a VF immediate for the cases where the constant is
a float and each component is representable in 8 bits.  This should cover a lot
of the common constants.  The reason why I did it that way in the FS backend is
that a) we scalarize already so it doesn't much matter and b) we don't actually
have a concept of vectors most of the time.

The reason for re-allocating and re-eimitting every time is that the constant
can be anywhere in the program (such as at the top) and we want the
copy-propagation pass to be able to propagate them.  Having them in different
control flow can cause problems for this.

> 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:
> 
> https://github.com/Igalia/mesa/commits/nir-vec4

Thanks for putting that together.  I just took a quick look through and it
looks like you're making decent progress.  I do have a couple of comments:

1) There are two places so far, brw_type_for_nir_type and
brw_conditional_for_nir_comparison, where we would like to put things in a
common place.  Recently, I added a brw_nir.h file and I believe Ken added a
brw_nir.c file which would be a perfect place to put those.  In fact, we could
probably simplify some of the current FS NIR code with your conditionals
function.

2) We probably want to have emit_intrinsic be one big switch that does
everything like we do in the FS.  I know that one big switch can be annoying at
times, but so is having a pile of little 3-line helpers that we have to declare
in the C++ class.  Not a big deal either way.

> 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!

Thank you for the extremely prompt (given that it was the middle of the night
there) reply!  Keep up the good work!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150417/9dc8c697/attachment.html>