[Mesa-dev] [RFC] NIR serialization
Timothy Arceri
tarceri at itsqueeze.com
Mon Sep 11 00:15:48 UTC 2017
Ccing list.
On 11/09/17 09:50, Timothy Arceri wrote:
> Hi Daniel,
>
> Here is the code that does the caching of tgsi in Gallium.
>
> https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_shader_cache.c
>
>
> Basically we just use the blob helpers to do the writing/reading.
>
> https://cgit.freedesktop.org/mesa/mesa/tree/src/compiler/glsl/blob.c
>
> For gallium you will want to create an equivalent for nir. Something
> like st_shader_cache_nir.c
>
> Once we have created the blob we simply pass it along with the sha we
> will use as the cache key off to the disk cache utils for
> compression/writing etc. e.g
>
> disk_cache_put(st->ctx->Cache, sha1, blob->data, blob->size, NULL);
>
> If you are doing development on radeonsi you could try using the env var
> R600_DEBUG=nir to enable the experimental nir path Nicolai added. This
> has OpenGL support up to 3.1 I believe.
>
> To load the nir for example you would change the st_link_shader()
> function in st_glsl_to_tgsi.cpp to do something like this:
>
> /* Return early if we are loading the shader from on-disk cache */
> if (preferred_ir == PIPE_SHADER_IR_NIR) {
> if (st_load_nir_from_disk_cache(ctx,
> pdisk_cache_put(st->ctx->Cache, sha1, blob->data, blob->size, NULL);rog)) {
> return GL_TRUE;
> }
> } else {
> if (st_load_tgsi_from_disk_cache(ctx, prog)) {
> return GL_TRUE;
> }
> }
>
> And to store you need to update the various functions in st_program.c:
>
> To call a st_store_nir_in_disk_cache() in the nir return paths. See the
> calls to st_store_tgsi_in_disk_cache() for reference.
>
> Hope this helps getting you started.
>
> Tim
>
> On 10/09/17 20:22, Daniel Schürmann wrote:
>> Hello Jordan,
>>
>> I wanted to ask you, if you could provide me with an interface /
>> function header for nir_(de)serialize, e.g. void nir_serialize(const
>> nir_shader *s, FILE f), because I am not sure how the shader cache
>> starts the serialization. Does it work on file directly or some
>> buffer? What about compression?
>>
>> If cached shader size is not too important (I was told its not), I
>> have an idea for a quick approach which uses nir_clone for
>> deserialization I would like to test.
>>
>> Thanks in advance
>> Daniel
>>
>>
>> On 09/08/2017 03:10 AM, Jordan Justen wrote:
>>> On 2017-09-07 16:26:04, 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.
>>> Daniel,
>>>
>>> It seems that I've been corrected on this point. (On irc and email. :)
>>> Point being, that nir serialization should be enough for i965 shader
>>> cache.
>>>
>>> Re-reading the thread, it seems like you are more interested in SPIR-V
>>> than nir? But, Tim mentioned on irc, that he thought you might have
>>> been interested in working on nir serialization.
>>>
>>> Are you interested in working on it? Have you started working on it?
>>> How much time would you have to work on it?
>>>
>>> Thanks,
>>>
>>> -Jordan
>>>
>>>> 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'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 <idr at freedesktop.org>
>>>>> To: Daniel Schürmann <daniel.schuermann at campus.tu-berlin.de>,
>>>>> Nicolai
>>>>> Hähnle <nhaehnle at gmail.com>, Timothy Arceri <tarceri at 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 at lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
More information about the mesa-dev
mailing list