Add more granular breakdown of work items required to build initial version of HLSL clang compiler c library #200
Conversation
|
FWIW, I don't think it would be a problem if this were just inlined in the original proposal doc. |
|
I could add this in-lined in the original propsal. I was worried because it was getting quite hefty with all of the overview of the existing compiler library info. This PR (#197) Still needs attention. |
| required to achieve the first milestone of adopotion by the ML team and | ||
| ability to compile a compute shader using clang as a library. | ||
|
|
||
| The Issues created here will be ordered to help contruct a roadmap that can be |
There was a problem hiding this comment.
| The Issues created here will be ordered to help contruct a roadmap that can be | |
| The Issues created here will be ordered to help construct a roadmap that can be |
| to be added: | ||
| * Add include handler support? | ||
| * Expose linker support? (Might be included with clang from other work) | ||
| * Expose optmizer support? (Might be include with clanga from other work) |
There was a problem hiding this comment.
| * Expose optmizer support? (Might be include with clanga from other work) | |
| * Expose optimizer support? (Might be included with clang from other work) |
| * Add include handler support? | ||
| * Expose linker support? (Might be included with clang from other work) | ||
| * Expose optmizer support? (Might be include with clanga from other work) | ||
| * Expose tooling featrures like container reflection, and other output inspection |
There was a problem hiding this comment.
| * Expose tooling featrures like container reflection, and other output inspection | |
| * Expose tooling features like container reflection, and other output inspection |
| * Expose tooling featrures like container reflection, and other output inspection | ||
| features? | ||
|
|
||
| [] Add skeleton library to llvm-project build system. This includes adding code |
There was a problem hiding this comment.
What does "skeleton library" mean here? Does this mean that there are non-functional entry points? Or does it mean that not all the expected entry points are there?
| D3D12 runtime. | ||
| * Is there a way to put these docs under an 'experimental' grouping? | ||
|
|
||
| [] Design and spec out-of-process compile library architecture. |
There was a problem hiding this comment.
IMO this should be one of the first things you do - or at least got agreement on whether or not there's an in-proc version of this. If it is out-of-proc only then I think building an in-proc interim version would be just building tech debt.
| that builds/links/calls into to the library ensuring that it is configured | ||
| properly. | ||
|
|
||
| [] Add documentation for defined library entrypoints to llvm-project docs with |
There was a problem hiding this comment.
I'd argue that documentation should be assumed to be part of the implementation, along with tests.
|
|
||
| ## Issues | ||
|
|
||
| Implementation work in this list is assumed to include tests! |
There was a problem hiding this comment.
TBH, I think that some of the steps here could likely be combined, but this glosses over the bigger roadmap questions of what the entire DXC API surface covers.
|
|
||
| Implementation work in this list is assumed to include tests! | ||
|
|
||
| [] Design and spec where the library will be built/exposed in the llvm-project |
There was a problem hiding this comment.
Sadly these check boxes don't render in GitHub's markdown previews 😞
This commit adds a sub proposal document under the big proposal 0016-c-interface-compiler-library that breaks down work required for the first milestone to compile a simple shader and have a partner team adopt the library for their needs.
Eventually this list will be turned into proper Issues and tracked on schedule to meet the milestone.