<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c5">Comment # 5</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 <a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>(In reply to Eduardo Lima Mitev from <a href="show_bug.cgi?id=89580#c4">comment #4</a>) > 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: > > <a href="https://github.com/Igalia/mesa/commits/nir-vec4">https://github.com/Igalia/mesa/commits/nir-vec4</a> 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!</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>