On 12.09.2017 06:25, Ian Romanick wrote:
On 09/07/2017 04:26 PM, Jordan Justen wrote:
On 2017-09-06 14:12:41, Daniel Schürmann wrote:
Hello together!
Recently, we had a small discussion (off the list) about the NIR
serialization, which was previously discussed in [RFC] ARB_gl_spirv and
NIR backend for radeonsi.
As this topic could be interesting to more people, I would like to
share, what was talked about so far (You might want to read from bottom up).
TL;DR:
- NIR serialization is in demand for shader cache
- could be done either directly (NIR binary form) or via SPIR-V
- Ian et al. are working on GLSL IR -> SPIR-V transformation, which
could be adapted for a NIR -> SPIR-V pass
- in NIR representation, some type information is lost
- thus, a serialization via SPIR-V could NOT be a glslang alternative
(otoh, the GLSL IR->SPIR-V pass could), but only for spirv-opt (if the
output is valid SPIR-V)
Ian,
Tim was suggesting that we might look at serializing nir for the i965
shader cache. Based on this email, it sounds like serialized nir would
not be enough for the shader cache as some GLSL type info would be
lost. It sounds like GLSL IR => SPIR-V would be good enough. Is that
right?
I don't think we have a strict requirement for the GLSL IR => SPIR-V
path for GL 4.6, right? So, this is more of a 'nice-to-have'?
I think it's basically a requirement if we want to adequately test
SPIR-V in OpenGL. The volume of tests for SPIR-V in the CTS is going to
be small compared to the number of tests for GLSL in the CTS and piglit.
The idea being a stand-alone linker & compiler that supports everything
Mesa does, but also writes out cross-stage valid locations for uniforms
and I/O?
The latter is really the biggest pain when working with glslang...
Cheers,
Nicolai
I'm not sure we'd want to make i965 shader cache depend on a
nice-to-have feature. (Unless we're pretty sure it'll be available
soon.)
But, it would be nice to not have to fallback to compiling the GLSL
for i965 shader cache, so it would be worth waiting a little bit to be
able to rely on a SPIR-V serialization of the GLSL IR.
What do you suggest?
-Jordan
- now, the question is if this is worth the additional effort
Kind regards,
Daniel
-------- Forwarded Message --------
Subject: Re: NIR serialization
Date: Tue, 5 Sep 2017 11:00:31 -0700
From: Ian Romanick <i...@freedesktop.org>
To: Daniel Schürmann <daniel.schuerm...@campus.tu-berlin.de>, Nicolai
Hähnle <nhaeh...@gmail.com>, Timothy Arceri <tarc...@itsqueeze.com>
Sorry for taking so long to reply. It was a long holiday weekend in the
US, and I was away.
On 09/01/2017 05:03 AM, Daniel Schürmann wrote:
A direct NIR binary serialization would also do the job (vc4/freedreno
was mentioned as well).
I only thought that SPIRV is preferable because
- deserialization for free
- cached shader size
- spirv-opt and glslang alternative
The term lossy doesn't make much sense to me with regard to
optimizations: aren't all optimizations lossy?
By lossy I mean there is a significant semantic change. As soon as
GLSL IR is converted to NIR, Boolean types completely cease to exist.
They are replaced with integers that are either 0 or -1. Similarly, all
matrix types cease to exist. They are replaced by a set of vectors.
For the purpose of the on-disk cache, this probably doesn't matter. It
does mean that additional information about, for example, types of
uniforms has to be tracked. In a direct GLSL IR to SPIR-V translation,
type information is maintained, so the SPIR-V has all the necessary
information.
As a glslang replacement, maintaining type information is an absolute
requirement. Users will use other tools to introspect the SPIR-V shader
to find locations of uniforms, shader inputs, offsets of values in UBOs,
etc. If the types are changed in the SPIR-V shader that we emit, none
of that will work. I plan to enable retrieval of portable SPIR-V both
from a Mesa driver and the standalone GLSL compiler.
Right now SPIR-V binaries will be quite large. I have several ideas
that I plan to implement once we have OpenGL 4.6 done that should
dramatically reduce the size of SPIR-V... I'm actually hoping to present
that at FOSDEM.
The primary goal would be the lossless NIR-SPIRV-NIR round-trip.
Secondary, it would be desirable if we achieve valid SPIRV binaries
which preserve the semantics of the original shader.
And here is the question if this is possible with the type information
that are available...
Ian: can you hint me to your repository? I couldn't find it.
https://cgit.freedesktop.org/~idr/mesa/log/?h=emit-spirv
Kind regards,
Daniel
On 09/01/2017 12:16 PM, Nicolai Hähnle wrote:
In addition to using NIR-based optimizations, I believe Timothy
mentioned that a method for serializing NIR would help the shader disk
cache of i965. It would certainly help radeonsi if/when we switch to
the NIR backend, because we could compile new shader variants without
falling back all the way to GLSL. For that, a lossless NIR-SPIRV-NIR
path would do the job.
Not that falling back all the way to GLSL from radeonsi is impossible,
but it would also require a whole bunch of new groundwork to be done
-- basically, we would need multi-threaded GLSL compilation and linking.
Cheers,
Nicolai
On 01.09.2017 02:41, Ian Romanick wrote:
I have been working on GLSL IR to SPIR-V. I have a bunch of stuff in
the emit-spirv branch of my freedesktop.org tree. Once that is done, it
should be pretty trivial to adapt it to NIR to SPIR-V, but I don't know
how useful that would be for Mesa. Part of the problem is NIR loses a
lot of information about types (bool and matrix types), so a
SPIRV-NIR-SPIRV path would necessarily be lossy.
On the flip side, GLSL IR lacks a huge number of optimizations that
exist in NIR, so it's probably not a huge improvement over spirv-opt.
On 08/26/2017 02:33 PM, Nicolai Hähnle wrote:
Hey Ian,
Have you done any more concrete work on NIR serialization? See below...
Cheers,
Nicolai
On 26.08.2017 23:17, Daniel Schürmann wrote:
Hello Nicolai,
I'm a Master student (CS) from TU Berlin and currently writing an
OpenMP backend for clang using SPIR-V/OpenCL for my thesis. As I'm
interested in mesa and graphics driver development since long time, I
would like to get involved a little bit.
Recently, I read your [RFC] ARB_gl_spirv and NIR backend for radeonsi.
You propose a serialization of NIR either directly or by using SPIR-V
as binary format.
I wanted to ask if you (or someone else) already started implementing
this because it seems to be a nice task for me to get into mesa and
NIR.
I would rather try to use SPIR-V as binary format for two (not yet
mentioned) reasons:
- it could be used as a replacement for spirv-opt and draw some
attention
- I expect SPIR-V to be smaller than a raw (unoptimized) serialization
of NIR.
The round-trip NIR -> SPIRV -> NIR should preserve all information
while SPIRV -> NIR -> SPIRV must preserve the semantic meaning. Please
tell me, if your know about some hindering obstacles or if someone is
already working on this.
[snip]
Thank you for your time,
kind regards,
Daniel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
