Skip to content

[SYCL][PI] Move files to libpi folder #3679

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

ProGTX
Copy link
Contributor

@ProGTX ProGTX commented May 3, 2021

The PI plugins could be made into an independent library,
allowing code outside the sycl project to use it.
The first step towards getting that
is to group all PI related files into its own directory structure.

This patch moves all the PI files into the folder libpi.
Includes setting up includes as pi/piXXX.
On the SYCL runtime side the files have been moved
from pi.hpp to pi_sycl.hpp etc.

Apart from the folder change and adjusting CMake,
there should be no change in functionality.
Tests had to be updated to set up include folders.

@ProGTX ProGTX requested review from bader, pvchupin, smaslov-intel and a team as code owners May 3, 2021 07:57
@ProGTX ProGTX changed the title [PI] Move files to libpi folder [SYCL][PI] Move files to libpi folder May 3, 2021
Copy link
Contributor

@smaslov-intel smaslov-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ProGTX : please update the description of PR with the motivation for this change.

The PI plugins could be made into an independent library,
allowing code outside the `sycl` project to use it.
The first step towards getting that
is to group all PI related files into its own directory structure.

This patch moves all the PI files into the folder `libpi`.
Includes setting up includes as `pi/piXXX`.
On the SYCL runtime side the files have been moved
from `pi.hpp` to `pi_sycl.hpp` etc.

Apart from the folder change and adjusting CMake,
there should be no change in functionality.
Tests had to be updated to set up include folders.
@ProGTX
Copy link
Contributor Author

ProGTX commented May 5, 2021

@ProGTX : please update the description of PR with the motivation for this change.

Done, the motivation is to eventually make it into an independent library so that other projects apart from sycl can use it.

@smaslov-intel
Copy link
Contributor

the motivation is to eventually make it into an independent library so that other projects apart from sycl can use it.

Could elaborate on what kind of uses you envision and why "libpi" is deemed to be the right abstraction layer for those uses?

@@ -9,6 +9,8 @@
#pragma once
#include <CL/sycl/detail/type_traits.hpp>
#include <CL/sycl/exception.hpp>
#include <pi/pi.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a pity that we had to include pi.h here to use PI_INVALID_VALUE in the function that has no dependency on plug-in interface.

  __SYCL_ALWAYS_INLINE void check_dimension(int dimension) const {
#ifndef __SYCL_DEVICE_ONLY__
    if (dimension >= dimensions || dimension < 0) {
      throw cl::sycl::invalid_parameter_error("Index out of range",
                                              PI_INVALID_VALUE);
    }
#endif
    (void)dimension;
  }

@romanovvlad, @smaslov-intel, I think there should be PI-independent error codes to report errors for cases like this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such error codes getting introduced in SYCL2020

#pragma once

#include <CL/sycl/detail/defines.hpp>
#include <pi/pi.hpp>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the motivation to have this wrapper.
Do we have a dependency on defines.hpp from pi.hpp? If so, I think we should remove such tight coupling between plug-in interface and the rest of the sycl runtime library.

Comment on lines 99 to +100
include_directories("${sycl_inc_dir}")
include_directories("${pi_include_dir}")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
include_directories("${sycl_inc_dir}")
include_directories("${pi_include_dir}")
include_directories("${sycl_inc_dir}" "${pi_include_dir}")

@@ -112,7 +113,7 @@ set(SYCL_SOURCES
"detail/builtins_integer.cpp"
"detail/builtins_math.cpp"
"detail/builtins_relational.cpp"
"detail/pi.cpp"
"${pi_source_dir}/pi.cpp"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I understand correctly that building libpi as a separate library will be added in follow-up patches?

@@ -1,4 +1,4 @@
// RUN: %clangxx -std=c++17 -fsyntax-only -Xclang -verify %s -I %sycl_include/sycl -Xclang -verify-ignore-unexpected
// RUN: %clangxx -fsyntax-only -Xclang -verify %s -fsycl -fsycl-targets=%sycl_triple -Xclang -verify-ignore-unexpected
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this change related to moving files to libpi directory?
NOTE: I don't think we should make this change. Original test validates compilation of DPC++ header with C++ compiler, but this change involves device compilation as well.

@@ -8,7 +8,7 @@

#define SYCL2020_DISABLE_DEPRECATION_WARNINGS

#include "CL/sycl/detail/pi.h"
#include "CL/sycl/detail/pi_sycl.hpp"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#include "CL/sycl/detail/pi_sycl.hpp"
#include "pi/pi.h"

?

@smaslov-intel
Copy link
Contributor

the motivation is to eventually make it into an independent library so that other projects apart from sycl can use it.

Could elaborate on what kind of uses you envision and why "libpi" is deemed to be the right abstraction layer for those uses?

@ProGTX : friendly ping

@github-actions github-actions bot added the Stale label Feb 15, 2022
@github-actions github-actions bot closed this Mar 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants