Re: [Mesa-dev] [RFC PATCH 00/17] Introducing SPIR-V support to clover

[Pierre Moreau]

Hello,

I am working on an updated version of this series, which will include changes
that have been suggested, as well as support for structures as a kernel
argument. Along those, I was also thinking of doing some other changes to the
SPIR-V linker:

a) Store some metadata about the SPIR-V module, such as the word offset of
   each of the different sections: if one wants to run an operation on a single
   section of the module, it is no longer needed to iterate over everything in
   front of that section.
   It could also contain the width of the literals used in the switch
   statements, avoiding having to track those every time one iterate over the
   module.
   Maybe tables for imported and exported symbols, as well?

b) Change the code from having a single loop iterating over the whole module,
   into having one loop per section. This will avoid testing for entry points,
   decorations, types, etc. when we are already iterating over the function
   bodies, possibly improving performance.

c) Remove duplicate decorations, capabilities, names? and types found in the
   linked module. Types is the most important one, as it currently prevents us
   from validating the linked module.

I am still thinking of leaving out of this series, the linking options support
for the linker.

As for clover, it should check that the devices actually support the
capabilities present in the module, so I will add that as well.

Do you think this would make sense, and should I be implementing them in this
series, or should I leave them be for later? (Point b), if deemed useful,
should be part of this series as it would rewrite a decent chunk of the code.)
If you have any other comments, feel free to share it. :-)

Best regards,
Pierre


On 11:56 pm - May 03 2017, Pierre Moreau wrote:
> Hello everyone,
> 
> I have been working on converting SPIR-V to NVIR in order to run OpenCL 
> kernels
> on Nouveau, and I would like to submit the first part of that work for review.
> Pieces from the SPIR-V to NVIR conversion work will be submitted once I have
> cleaned it up and this series has progressed through the reviewing process.
> 
> 
> What’s in this Series?
> --
> 
> The focus of this series is to let clover accept SPIR-V binaries, either
> through `clCreateProgramWithBinary()`, or through `clCreateProgramWithIL()`.
> The latter function is the proper way to feed SPIR-V binaries using the OpenCL
> API, however it was only introduced in OpenCL 2.1 (more on “why supporting
> SPIR-V through `clCreateProgramWithBinary()` can be interesting” further 
> down).
> 
> As several SPIR-V binaries can be linked together using the OpenCL API, I
> implemented a SPIR-V linker, which is not perfect, but does the job. I tested
> linking against a variable, a function, a library, and a function containing a
> switch statement; switch-statements require you to keep some extra stuff 
> around
> to be properly parsed.
> I also added a few “utilities” functions for retrieving and setting a word /
> retrieving a string from a SPIR-V binary, and converting a SPIR-V binary to 
> the
> same endianness as the host CPU.
> 
> For validating SPIR-V binaries, I use an external tool, SPIRV-Tools [1]. It
> could also be used in anv, and possibly radv if there is no validation done
> already, but I haven’t looked into that.
> 
> A few modifications have been made to the pipe interface, to add a define for
> the SPIR-V IR, and store the program’s byte-size along the program in
> `struct pipe_compute_state`. The latter will only be needed by the consumer of
> the SPIR-V, which is not part of this series. However, since clover needs to
> fill that information in and I was modifying clover already, I decided to add
> the new attribute in this series.
> 
> 
> Missing
> ---
> 
> * As there is no upstream version of LLVM which can produce SPIR-V out of
>   OpenCL code, clCreateProgramWithSource will refuse to work if the target IR
>   is SPIR-V, for now.
> 
> * Optimisation linking options are parsed by the SPIR-V code in clover but
>   are not passed along to the linker as it does not support them.
> 
> 
> To Improve
> --
> 
> The SPIR-V binary resulting from the linking of multiple SPIR-V binaries could
> be cleaned up:
> 
> * As capabilities are simply copied from all the involved binaries, you can 
> end
>   up with multiple times the same capabilities in the resulting binary; this
>   shouldn’t have any impact though.
> 
> * Similarly, types can end up being duplicated under different IDs, which
>   should have no other impact than making SPIR-V validators unhappy.
> 
> 
> Misc.
> -
> 
> Being able to feed SPIR-V binaries through `clCreateProgramWithBinary()` is 
> not
> really useful at the moment: the same can be achieved using
> `clCreateProgramWithIL()`. However it will be interesting once there is an
> upstream version of LLVM which can generate SPIR-V binaries, as the 
> application
> could query the binary created by 

Re: [Mesa-dev] [RFC PATCH 00/17] Introducing SPIR-V support to clover

[Pierre Moreau]

> hopefully this[1] will eventually happen, which would make this less
> of an issue :-)
> 
> [1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112538.html

Indeed! I have seen that thread and made sure to subscribe to the ML not to
miss anything there.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH 00/17] Introducing SPIR-V support to clover

[Rob Clark]

On Wed, May 3, 2017 at 5:56 PM, Pierre Moreau  wrote:
>
> * As there is no upstream version of LLVM which can produce SPIR-V out of
>   OpenCL code, clCreateProgramWithSource will refuse to work if the target IR
>   is SPIR-V, for now.


hopefully this[1] will eventually happen, which would make this less
of an issue :-)

[1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112538.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev