Skip to content
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

hipGraph API fixes & "native" Graph implementation #560

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

franz
Copy link
Collaborator

@franz franz commented Jul 24, 2023

This is the same as PR #434, except:

  • rebased on upstream/main
  • removed the code not related to Graphs (i'll make a separate PR for USM)
  • merged the style fixes
  • updated the code to use chipstar namespace

franz and others added 7 commits July 24, 2023 11:47
this is required for cl_khr_command_buffer
CL/opencl.h: include cl_ext_pocl.h but exclude cl_gl_ext.h
(now just redirects to cl_ext.h)
This class is used to implement Graphs that execute "natively"
in the backend, using OpenCL command-buffers or LevelZero command-lists
and only synchronizing with the host when required. Fallback to
original Graph is provided in chipstar::GraphExec::launch()

Add more error-checking to the hipGraphXYZ APIs & bugfixes

Additionally, samples/graph + samples/graphMatrixMultiply
work using the "native graphs" (cl_command_buffer), not
the original chip-spv's graph execution.

Merged style fixes by Henry.

Co-authored-by: Henry Linjamäki <linehill@users.noreply.github.com>
move graph tests to FAILING_FOR_ALL
@franz franz marked this pull request as ready for review July 25, 2023 11:04
Copy link
Collaborator

@pjaaskel pjaaskel left a comment

Choose a reason for hiding this comment

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

Great work. Just a few comments. Will test the branch on my platforms.

*pGraph = Graph;
RETURN(hipSuccess);
CHIP_CATCH
}

hipError_t hipGraphDestroy(hipGraph_t graph) {
CHIP_TRY
if (!graph)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should start with a capital per the LLVM C++ naming style, right? There are also others in the file.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This follows the original AMD's HIP API naming & style, see e.g. here. Not sure if it's a good idea to change it

Copy link
Collaborator

Choose a reason for hiding this comment

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

We already did when we decided to use the LLVM C++ style in chipStar codes.

src/CHIPGraph.cc Show resolved Hide resolved
src/CHIPGraph.cc Show resolved Hide resolved
src/CHIPGraph.hh Show resolved Hide resolved

cl_command_queue CQ = ClQueue_->get();
int err = CL_SUCCESS;
cl_command_buffer_khr Res =
Copy link
Collaborator

Choose a reason for hiding this comment

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

Add a check somewhere that we are targeting only one device, if using the single-device CB.

src/backend/OpenCL/CHIPBackendOpenCL.cc Show resolved Hide resolved
src/backend/OpenCL/CHIPBackendOpenCL.cc Show resolved Hide resolved
@@ -1291,6 +1366,401 @@ std::shared_ptr<chipstar::Event> CHIPQueueOpenCL::enqueueBarrierImpl(
return Event;
}

/********************************************************************************/

chipstar::GraphNative *CHIPQueueOpenCL::createNativeGraph() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why GraphNative, why not NativeGraph? Or BackendGraph?

Copy link
Collaborator Author

@franz franz Jul 25, 2023

Choose a reason for hiding this comment

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

because that's how the rest of the graph-related classes are named: GraphExec, GraphNodeMemcpy, GraphNodeMemset etc.

src/backend/OpenCL/CHIPBackendOpenCL.cc Show resolved Hide resolved
cmake/UnitTests.cmake Show resolved Hide resolved
@pjaaskel
Copy link
Collaborator

One test fails here with iGPU (both LZ and CL) and Intel CPU:

hipSimpleGraphWithKernel: /home/pjaaskel/src/chip-spv/src/SPIRVFuncInfo.cc:183: void SPVFuncInfo::visitKernelArgsImpl(const std::vector<void *> &, KernelArgVisitor) const: Assertion `ArgData && "nullptr in the argument list"' failed.
Filters: Unit_hipGraph_SimpleGraphWithKernel

PoCL-CPU (latest main) fails a lot of tests, but I suppose it's expected before the SVM/CB updates land to main, right?

70% tests passed, 419 tests failed out of 1384

@franz
Copy link
Collaborator Author

franz commented Jul 25, 2023

One test fails here with iGPU (both LZ and CL) and Intel CPU:

It works for me on my iGPU (with both LZ and CL), so i'm going to need more information to debug (llvm/translator exact commits, cmake build flags etc).

PoCL-CPU (latest main) fails a lot of tests, but I suppose it's expected before the SVM/CB updates land to main, right?

No, this PR is not dependent on PoCL updates. The native graphs are entirely optional, and the PR also passes tests with Level0 backend (which does not yet have the "native" graph implemented).

70% tests passed, 419 tests failed out of 1384

Is the 1384 from running ctest directly with no arguments ? The official runner is scripts/check.py; with igpu option it should run & pass 984/986 (LZ/CL) tests with this PR, and with cpu pocl there should be 957 tests. 1384 - 419 = 965 so that is actually a bit more than should be passing with PoCL.

the constructors were copying the value of Args pointer,
instead of making an actual copy of the arguments. This
can lead to a crash if the Args pointer lives on the stack,
later goes out of scope, and setupAllArgs() is called.
@pjaaskel
Copy link
Collaborator

pjaaskel commented Aug 2, 2023

Please also add some text to ReleaseNotes of this feature.

@pvelesko
Copy link
Collaborator

@franz conflicts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants