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

[SYCL] Specify a modifiable graph as having device specific nodes #83

Merged
merged 7 commits into from
Mar 24, 2023

Conversation

EwanC
Copy link
Collaborator

@EwanC EwanC commented Feb 28, 2023

Modifies the API and behaviour of a command_graph to enable a single modifiable command_graph to contain commands targeting different devices.

See #7 for motivation.

Marked Draft for now as this requires discussion.

@EwanC EwanC added the Graph Specification Extension Specification related label Feb 28, 2023
Copy link
Collaborator

@Bensuo Bensuo left a comment

Choose a reason for hiding this comment

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

LGTM, just a few minor comments.

Modifies the API and behaviour of a command_graph
to enable a single modifiable command_graph to
contain commands targeting different devices.

See #7 for discussion.
The `syclDevice` parameter to `add()` is now described as being
the device used to process `cgf`.
@reble
Copy link
Owner

reble commented Mar 20, 2023

It might make sense to break this patch down into two. One that has all changes to existing functions, without support for multiple devices per graph. And a second patch that removes this restriction.

@EwanC EwanC marked this pull request as ready for review March 22, 2023 05:23
@EwanC EwanC changed the title Enable multi-device graphs [SYCL] Enable multi-device graphs Mar 22, 2023
@EwanC
Copy link
Collaborator Author

EwanC commented Mar 22, 2023

It might make sense to break this patch down into two. One that has all changes to existing functions, without support for multiple devices per graph. And a second patch that removes this restriction.

Done that now, although I have one discussion point about where to throw the error if a user does try to use multiple devices - #83 (comment)

PR with second patch is at #107

@reble
Copy link
Owner

reble commented Mar 22, 2023

LGTM. You might want to rename the PR to avoid confusion.

Co-authored-by: Pablo Reble <pablo.reble@intel.com>
@EwanC EwanC changed the title [SYCL] Enable multi-device graphs [SYCL] Specify a modifiable graph as having device specific nodes Mar 23, 2023
@EwanC EwanC requested a review from Bensuo March 23, 2023 08:51
Copy link
Collaborator

@Bensuo Bensuo left a comment

Choose a reason for hiding this comment

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

LGTM

@EwanC EwanC merged commit 6192647 into sycl-graph-update Mar 24, 2023
EwanC added a commit that referenced this pull request Mar 30, 2023
Based on feedback from the Working Group it is
clearer to represent the current single device characteristic
of a graph by passing a device to the graph constructor that all
nodes will target. Then remove the `device` parameter from the
explicit API, as it can be added as an overload in a future revision
due to experimental nature of the extension

A diff of these changes against the commit prior to when the [original
multi-device PR](#83) went in
can be seen
[here](28acfa8...reble:llvm:ewan/single_device)
EwanC added a commit that referenced this pull request Mar 30, 2023
Based on feedback from the Working Group it is
clearer to represent the current single device characteristic
of a graph by passing a device to the graph constructor that all
nodes will target. Then remove the `device` parameter from the
explicit API, as it can be added as an overload in a future revision
due to experimental nature of the extension

A diff of these changes against the commit prior to when the [original
multi-device PR](#83) went in
can be seen
[here](28acfa8...reble:llvm:ewan/single_device)
@EwanC EwanC deleted the ewan/multi-device branch June 28, 2023 14:37
mfrancepillois pushed a commit that referenced this pull request Oct 2, 2023
…… (#67069)

We noticed some performance issue while in lldb-vscode for grabing the
name of the SBValue. Profiling shows SBValue::GetName() can cause
synthetic children provider of shared/unique_ptr to deference underlying
object and complete it type.

This patch lazily moves the dereference from synthetic child provider's
Update() method to GetChildAtIndex() so that SBValue::GetName() won't
trigger the slow code path.

Here is the culprit slow code path:
```
...
frame #59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt]
...
frame #67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt]
frame #68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt]
frame #69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt]
...
frame #78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt]
frame #79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt]
frame #80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt]
frame #81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt]
frame #82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt]
frame #83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt]
...
```

Differential Revision: https://reviews.llvm.org/D159542
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Graph Specification Extension Specification related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants