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

No clear header and lib deployment + no header in windows sdk #1132

Closed
galop1n opened this Issue Mar 12, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@galop1n

galop1n commented Mar 12, 2018

Hi,

Right now, it is unclear of what is the set of headers and lib a deployed version of a dxc build should contain as we do not want to pollute or source control with hundreds of LLVM stuff.

Right now, i pull from the folders, the 4 headers below but i imagine it may need a few others depending on future needs. These are enough to compile and do some basic manipulation of the DXIL container ( part kind enum, etc ) :
dxcapi.h
HLSL/DXilCompType.h
HLSL/DxilConstants.h
HLSL/DxilContainer.h

It is worth to say that the current windows 10 sdk is also missing any of these files, and only contains dxc.exe and the proxy DLL to hijack the old compiler.

Ideally, we should only need a single header/library like we use to with d3dcompiler.h

@marcelolr

This comment has been minimized.

Contributor

marcelolr commented Mar 12, 2018

Hehe, I just filed #1131 for this. I was thinking of only including enough to call into dxcompiler, not the container functionality though.

You should be able to do most (all?) of the container manipulation via APIs in any case - is there something missing from our API surface for that?

@galop1n

This comment has been minimized.

galop1n commented Mar 12, 2018

dxcapi.h has what it needs to manipulate the container, but dxilcontainer.h has the enums and constants. The other two headers are dependencies ( dxilcomptype.h is not a dependency anymore on the latest revision )

The elements that are mandatory to work on a dxil container are :

  • DxilFourCC to recognize the part types
  • All the ShaderFeatureInfo_ to figure uses in the shader ( to validate match at runtime against D3D12_OPTIONSX members )

In the future, when things like DFCC_ShaderStatistics are implemented, or if something cannot be transposed back to an ID3D12ShaderReflection object, we may have to parse deeper ourself in the DXIL container part and need other declarations, but for the moment, nothing more is needed.

@hekota

This comment has been minimized.

Member

hekota commented May 15, 2018

Duplicate of #1131.

@hekota hekota closed this May 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment