[Bug 89580] Implement a NIR -> vec4 pass

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri May 1 02:28:04 PDT 2015


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

--- Comment #10 from Eduardo Lima Mitev <elima at igalia.com> ---
(In reply to Jason Ekstrand from comment #9)
> (In reply to Eduardo Lima Mitev from comment #8)
> > 
> > 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.
> 

Ok, that explains it. Indeed I was talking about global variables, and we also
suspected that all those get lowered to locales. Apparently we just got
confused with global variables vs. the global register handling in fs_nir. It
is clarified now.

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

Great, we will take this into account. Thanks!

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

I found out that my implementation of uniforms setup and load is completely
buggy, so I'm fixing it now. Just so you know.

-- 
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/20150501/722e3984/attachment.html>


More information about the intel-3d-bugs mailing list