[Mesa-dev] [RFC 00/11] GL_ARB_gpu_shader_fp64

Mon Mar 6 17:15:06 UTC 2017

On Mon, Mar 6, 2017 at 3:26 AM, Emil Velikov <emil.l.velikov at gmail.com>
wrote:

> On 6 March 2017 at 08:34, Michel Dänzer <michel at daenzer.net> wrote:
> > On 04/03/17 05:32 AM, Jason Ekstrand wrote:
> >> On Fri, Mar 3, 2017 at 11:41 AM, Ilia Mirkin <imirkin at alum.mit.edu
> >> <mailto:imirkin at alum.mit.edu>> wrote:
> >>
> >>     On Fri, Mar 3, 2017 at 2:16 PM, Jason Ekstrand <
> jason at jlekstrand.net
> >>     <mailto:jason at jlekstrand.net>> wrote:
> >>     > Hey Elie!
> >>     >
> >>     > On Fri, Mar 3, 2017 at 8:22 AM, Elie Tournier <
> tournier.elie at gmail.com <mailto:tournier.elie at gmail.com>>
> >>     > wrote:
> >>     >>
> >>     >> From: Elie Tournier <elie.tournier at collabora.com <mailto:
> elie.tournier at collabora.com>>
> >>     >>
> >>     >> This series is based on Ian's work about GL_ARB_gpu_shader_int64
> [1].
> >>     >> The goal is to expose GL_ARB_shader_fp64 to OpenGL 3.0 GPUs.
> >>     >>
> >>     >> Each function can be independently tested using shader_runner
> from piglit.
> >>     >> The piglit files are stored on github [2].
> >>     >>
> >>     >> [1]
> >>     >> https://lists.freedesktop.org/archives/mesa-dev/2016-
> November/136718.html
> >>     <https://lists.freedesktop.org/archives/mesa-dev/2016-
> November/136718.html>
> >>     >> [2] https://github.com/Hopetech/libSoftFloat
> >>     <https://github.com/Hopetech/libSoftFloat>
> >>     >
> >>     >
> >>     > Glad to see this finally turning into code.
> >>     >
> >>     > Before, we get too far into things, I'd like to talk about the
> approach a
> >>     > bit.  First off, if we (Intel) are going to use this on any
> hardware, we
> >>     > would really like it to be in NIR.  The reason for this is that
> NIR has a
> >>     > much more powerful algebraic optimizer than GLSL IR and we would
> like to
> >>     > have as few fp64 instructions as possible before we start
> lowering them to
> >>     > piles of integer math.  I believe Ian's plan for this was that
> someone would
> >>     > write a nir_builder back-end for the stand-alone compiler.
> Unfortunately,
> >>     > he sort-of left that as "an exercise to the reader" and no code
> exists to my
> >>     > knowledge.  If we're going to write things in GLSL, we really
> need that NIR
> >>     > back-end.
> >>
> >>     I'm not sure what the impetus was for developing a softfloat library
> >>     (but I'm a big fan). but the current situation is that it will
> largely
> >>     just be useful for AMD Evergreen/Northern Islands chips, which
> consume
> >>     TGSI produced from GLSL. (Aside: [1].) As such, I'm not sure if a
> push
> >>     towards NIR is warranted -- it would cause a more convoluted path
> >>     towards the intended target.
> >>
> >>
> >> Whether or not i965 wants softfloat is an ongoing debate.  On the one
> >> hand, we have "hardware support" for it starting with ivy bridge.  On
> >> the other hand, early hardware support is sufficiently terrible that
> >> softfloat may end up being a better plan.  Also, I wouldn't be surprised
> >> if, at some point in the future, some hardware engineer decides they can
> >> save a bunch of power on low-power parts if they delete the fp64
> >> hardware.  Since we ship desktop GL on those parts, loosing 4.0 would be
> >> bad.  I don't want to paint ourselves into a corner on fp64.
> >
> > Doing it in NIR would make it useless for r600. What's your suggestion
> > for that?
>

I'm not suggesting that we go NIR-only.  I thought I was fairly clear on
that in my original e-mail. (Maybe I wasn't?) My original e-mail intended
to point out some of the issues with the current approach and open things
up for discussion about solutions.  One of those issues is no NIR support.
Lest you ask, "can't you just use the GLSL pass?", please remember that
we're shipping a driver that doesn't use GLSL IR.

As far as what we do going forward, here's what I'd like to see at least
initially:

 1) Does r600 have any vec4-based stages or are they all scalar?  If it has
vec4-based stages, it would be nice if whatever lowering we did used the
split pack/unpack opcodes so that scalarizing is optional.  That makes it
way nicer to vec4 back-ends.

 2) I'd like to see at least an example of writing the lowering directly in
builder code rather than doing GLSL code-gen.  In my experience, builder
code isn't that hard to write if you've got the GLSL handy as a reference
and the resulting C++ code is way easier to debug than something that comes
out of codegen.

Note that neither of those two things have anything to do with NIR.

> How about we allows drivers to opt-in for this ? There's already a
> bunch in gl_shader_compiler_options that we toggle.
> This will allow Elie's work to land and be [at least partially] useful
> in the interim.
>

That's entirely beside the issue.  I'm trying to avoid checking piles of
very hard-to-read autogenerated C++ code into the tree until we're sure
that it's actually a good solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170306/889ad62c/attachment-0001.html>