[Bug 89580] Implement a NIR -> vec4 pass

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Eduardo Lima Mitev from comment #8)
> Hi Jason, just to keep you updated with our progress, we are done
> implementing most of the core functionality:
> 
> - Control-flow (impl, block, loop, jump, if, etc)
> - Most intrinsics that are relevant in the vertex shader; except load_ubo,
> atomic counters, and indirect versions of uniforms, input and output. We are
> deferring indirects until a later stage and a better understanding of it.
> There is a known bug in the setup of uniforms values that I'm currently
> dealing with.
> - Most ALU operations. We are currently testing them extensively, fixing
> bugs, etc; so this is ongoing work.

Good work!  I'll try and give your branch another look here soon.  It sounds
like you're making good progress!

> Texture related instructions are still missing. We will probably start
> working on them by the end of this week.
> I also have pending to revisit the way we emit constant values.
> 
> Regarding global values, we have been working on it using the code in
> brw_fs_nir as reference. But we were not able to find any example that
> requires this support. As far as we see the combination of
> nir_lower_global_vars_to_local and inlining of functions can handle all of
> them. As a test/hack, we removed the lowering, but that is needed to support
> nir_intrinsic_load_var and store_var, that were not previously supported on
> brw_fs_nir. As a final test, we removed the support for globals in
> brw_fs_nir (variable nir_globals, and
> their usage), and run piglit (all test suite), without finding any
> regression. Are you aware of any specific case in which handling globals is
> still needed?

I'm not sure what you mean by "global values".  If you're referring to
variables with type global, you'll never see them.  Before you even see the
code, the nir_lower_global_vars_to_local gets run and, since everything is
inlined, that lowers *all* the globals to locals.  The locals_to_regs pass then
turns them into registers.

> This week we will start running specific piglit/dEQP tests on our branch to
> get a better picture of where we stand. I foresee a lot of new tasks coming
> from these runs. Do you have any advice as to what (sub)set of tests we
> could try to cover first?

I'd start by just doing a full piglit run both with and without NIR and
comparing the too.  My usual method is to look at the piles of crashes/failures
and grab whatever looks like the simplest test.  Most of the shader_runner
tests need at least uniforms and two urb writes (one for vertices and one for
success/failure color) to work.  If you think those are working, I'd probably
start with the ones labled "algebraic".  Also, you probably want to avoid
generated tests as long as you can.  They tend to have very long shaders
(that's why we generate them) so they can be a real pain to debug.

> As usual, we have a snapshot of our (dirty) git tree at
> https://github.com/Igalia/mesa/commits/nir-vec4

Thanks!  I'll try and take a look!

-- 
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/20150428/1e525409/attachment.html>