[Mesa-dev] [PATCH 00/59] Initial arb_gpu_shader_fp64 support to the i965 scalar backend

Kenneth Graunke kenneth at whitecape.org
Tue May 3 18:23:00 UTC 2016


On Tuesday, May 3, 2016 12:09:33 PM PDT Samuel Iglesias Gonsálvez wrote:
> 
> On 02/05/16 23:50, Mark Janes wrote:
> > Samuel Iglesias Gonsálvez <siglesias at igalia.com> writes:
> >
> >> Hello,
> >>
> >> This patch series continues adding arb_gpu_shader_fp64 support to
> >> the Intel driver. Specifically, this targets the  i965 scalar
> >> backend for BDW+ hardware (vec4 is still under research and gen7
> >> has its own issues which we intend tackle after gen8).
> >>
> >> This adds most of the fp64 scalar implementation, it starts by
> >> enabling the various lowering passes in NIR for doubles and then
> >> adds all the infrastructure required in the backend to operate
> >> with 64-bit floating point data.
> >>
> >> For reference, this series fixes 1009 fp64 piglit tests in BDW.
> >> Fp64 totals look like this:
> >>
> >> pass:                  2523 fail:                    46 crash:
> >> 447 skip:                    16 total:                 3032
> >>
> >> There are a few missing things in this series to achieve a
> >> perfect fp64 pass rate:
> >>
> >> 1. Fixes to copy propagation. The fp64 code creates new code
> >> patterns that copy-propagation isn't really ready to handle yet
> >> leading to incorrect results in some cases. We have 9 patches to
> >> fix copy propagation for fp64 that we intend to send separately
> >> after the main fp64 infrastructure has been reviewed.
> >>
> >> 2. ubo/ssbo/shared-variables. We will also send the patches for
> >> this in a separate series after this one.
> >>
> >> 3. A fix for the SIMD lowering pass to properly handle
> >> execmasking when transposing the results of split instructions
> >> back together. We have a local fix for this, but Curro hit the
> >> same problem while working on SIMD32 and has a better solution
> >> for it so we intend to use his solution when it is ready.
> >>
> >> 4. Spilling. We don't support spilling of DF registers yet and
> >> some piglit tests need this to compile. Jason had plans to work
> >> on the spilling code and address the needs of fp64 along the
> >> way.
> >>
> >> The series does not introduce any regressions in piglit on ILK,
> >> SNB, HSW, BDW and SKL.
> >
> > In addition to the fp64 failures and assertions described above, I
> > see the following regressions when I run piglit:
> >
> > piglit.spec.arb_tessellation_shader.execution (5 tests, SKL, IVB,
> > HSW, BYT, BSW, BDW)
> >
> 
> This is weird for gen < 8... Were you running them with the
> MESA_EXTENSION_OVERRIDE? Because this is not supported in gen < 8.
> 
> About gen8+, see below.
> 
> > These tests give the same assertion as most of the fp64 tests:
> > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp:626: int
> > brw::type_size_vec4(const glsl_type*): Assertion `!"not reached"'
> > failed.
> >
> 
> This is expected because there is no fp64 support for vec4 backend in
> this patch series.
> 
> > piglit.shaders.shadersource-no-compile (all platforms)
> >
> > Fails with "Failed to link: error: linking with uncompiled shader"
> >
> 
> Comparing with the master HEAD used for part1 (c750029) this is not a
> regression because it is failing there too. It seems this was fixed
> recently.
> 
> > Sam, are you able to reproduce my results?
> >
> 
> About this:
> 
> piglit.spec.glsl-1_10.compiler.vector-dereference-in-dereference.frag
> 
>   asserts with "glslparsertest:
>   src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp:422: virtual
>   ir_visitor_status
>   ir_channel_expressions_visitor::visit_leave(ir_assignment*): Assertion
>   `!"should have been lowered"' failed."
> 
> This is not a regression with the reference we used (c750029) because it
> fails there too.
> 
> Can you compare piglit results with c750029 as reference?
> 
> Thanks a lot!
> 
> Sam

Sam is right - these last two are new tests Jamey and I recently added
that were fixed by commits on master after this.  They should be fixed
by a rebase.

The tessellation and geometry shader type_size assertions would be fixed
by switching to scalar mode.  I'll try and land scalar TCS soon and make
it the default.  Then I just need to figure out geometry shaders.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160503/efeae675/attachment.sig>


More information about the mesa-dev mailing list