-
-
Notifications
You must be signed in to change notification settings - Fork 267
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
[dcompute] add support for OpenCL image I/O #3835
Conversation
88d22cf
to
e0f55eb
Compare
gen/dcompute/targetOCL.cpp
Outdated
|
||
auto sd = ptr->type->isTypeStruct(); | ||
auto mod = sd ? sd->sym->getModule() : nullptr; | ||
if (mod && mod->md && mod->md->id == Id::opencl) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is where you hardcode that the module name must be opencl
. Should this not be ldc.opencl
? That way, we can ship LDC with that hardcoded module.
Or am I misunderstanding things?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be ldc.opencl?
Alas it must be, the SPIR-V backend depends on exclusively the type e.g. opencl.image1d_ro_t
and I don't know how to force the name of a type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would work if you put module opencl;
at the top of the file, while still having it in ldc/opencl.d
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true, druntime/src/ldc
would have to be on the import path in addition to druntime/src
.
I'll do that in a separate PR, because only a few of the types are needed to test the code generation and I've not finished the file yet, I still need to figure out which combinations of {1d,2d,3d}, {ro,wo,rw}, {array, msaa, depth, buffer,(none)}
are valid and the msaa ones are only valid with OpenGL sharing or something.
(Also I still don't know how submodule update PRs work.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true,
druntime/src/ldc
would have to be on the import path in addition todruntime/src
.
That would be a big change (because then suddenly import attributes;
would 'work').
I would expect the type names to be generated from the name specified by module <name>
, rather than the how it is imported using import <name>
.
Zooming out a little, I think requiring that the type name in D is exactly how LLVM wants it internally is very brittle. For example, if LLVM expects a different type name, then all user code would have to change aswell (perhaps solvable with a bunch of stable alias
types in LDC's opencl.d
?). I'd say first priority is getting things to work, but soon after there needs to be some thought behind the future/longer term stability of this functionality working.
I'll do that in a separate PR
ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be a big change (because then suddenly import attributes; would 'work')
Indeed. We could have it along side object.d
, I currently have it under dcompute/source
requiring that the type name in D is exactly how LLVM wants it internally is very brittle
It may be brittle, but it is exceedingly unlikely to change (SPIR (n.b. not SPIR-V) is a standard after all) unless we change backends (which I would love to do, but there is not official SPIR-V that is part of the LLVM project) in which case they would probably all be i8 addrspace(1)*
to intrinsic functions which would be completely handled by the dcompute library.
perhaps solvable with a bunch of stable alias types in LDC's opencl.d?
Of course, there's no point calling it an GlobalPointer!image1d_ro_t
when you can alias it to ReadOnlyImage!1
.
The only mildly annoying concern is the conditionally declared types that depend on if OpenGL image sharing is enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be ldc.opencl?
Yeah, that would be much nicer indeed IMO, keeping extra LDC stuff in its package.
I don't know how to force the name of a type.
The name is currently initialized and then untouched AFAICT in
Line 206 in f9ba172
LLStructType::create(gIR->context(), ad->toPrettyChars())), |
Lines 49 to 55 in f9ba172
IrTypeStruct *IrTypeStruct::get(StructDeclaration *sd) { | |
IF_LOG Logger::println("Building struct type %s @ %s", sd->toPrettyChars(), | |
sd->loc.toChars()); | |
LOG_SCOPE; | |
auto t = new IrTypeStruct(sd); | |
getIrType(sd->type) = t; |
Also I still don't know how submodule update PRs work.
You push a branch onto the LDC repo and then reference it here in an LDC PR. After merging the PR here, the druntime branch needs to be merged into druntime's ldc
branch (and must be a fast-forward merge, i.e., the druntime branch must branch off the current ldc
head).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could override it before returning for opaque structs
Thanks, will do some investigation tomorrow about this.
as all of these magic structs are opaque at the moment
correct, and I don't see that changing any time soon.
You push a branch onto the LDC repo and then reference it here in an LDC PR. After merging the PR here, the druntime branch needs to be merged into druntime's ldc branch (and must be a fast-forward merge, i.e., the druntime branch must branch off the current ldc head).
THANKS!!! will bookmark this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could use isFromLDC_OpenCL(sd)
for the if-condition now, that would simplify things (and restrict it to ldc.opencl
only).
89e2e9c
to
0b66b0f
Compare
Any final comments? It would be good to get this in before |
gen/dcompute/targetOCL.cpp
Outdated
@@ -38,6 +39,7 @@ | |||
|
|||
namespace { | |||
class TargetOCL : public DComputeTarget { | |||
bool usedImage; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like you read from it but don't set it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed in 1f24be6 stackoverflow tells me that s.rfind("needle", 0) == 0
is how you're supposed to do startsWith
on a string prior to C++20.
Hmm, I seem to have a merge conflict that I can't figure out how to fix. |
f6f2cdc
to
1002c90
Compare
Hmm, the druntime commit seems to be -e1ba20fec08568c9f7d81ceedbac84d78cfdcd34
+e3738e482e9854cf7eb05c8f79abe5405fd1a8a9 instead of -06fdf5464471d9877bce2aeadc80d527b7e8db1d
+e3738e482e9854cf7eb05c8f79abe5405fd1a8a9 hence the merge conflict. I've no idea why its doing that though or how to fix it. |
1002c90
to
e8df267
Compare
|
That's probably caused by master pointing to a newer druntime hash (I've merged upstream stable recently) than when this branch was branched off - rebase this branch in that case (and yes, it's going to complain about a druntime conflict, just commit your change, your druntime branch is fine). |
b162c2b
to
a5b78ed
Compare
Yay! I've still got some fixes to do on the druntime bit. |
You could try making |
That fixes it locally. |
a5b78ed
to
52bef9e
Compare
Ubuntu 16.04 x64 ltsmaster fails with:
is that a problem with ltsmaster CI? |
I've just retried it (thought you might have pushed the druntime commit a bit too late after pushing here), but it failed identically. Might have to do with an old git of that vanilla Ubuntu 16 image and some strange |
You could try removing the Line 186 in f9ba172
|
Hmm, didn't work. |
You've patched the wrong line. |
3241c9f
to
00464a6
Compare
Thanks, that seems to have fixed it. |
For unknown reasons this can result in "Unable to checkout 'hash' in submodule path 'runtime/druntime'"
00464a6
to
b9cee9d
Compare
I think this is good to go. |
[As for druntime, I suppose you could get rid of |
b9cee9d
to
44b32e1
Compare
I think it serves a purpose as documentation, its probably not necessary but does no harm. Anyway this is good to go from my perspective. |
44b32e1
to
ecac84a
Compare
Good to go? |
Thanks! |
No description provided.