-
Notifications
You must be signed in to change notification settings - Fork 714
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
[linux] Enable Reflection on *nix platforms #4810
Changes from 6 commits
b0e8aea
d75202e
aa21b32
0a31264
04a9d5f
c360ae6
09deade
62b6620
85f6d58
da6cc33
7095703
d87e286
83bd996
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,25 @@ | ||||||
/////////////////////////////////////////////////////////////////////////////// | ||||||
// // | ||||||
// DxReflection.h // | ||||||
// Copyright (C) Microsoft Corporation. All rights reserved. // | ||||||
// This file is distributed under the University of Illinois Open Source // | ||||||
// License. See LICENSE.TXT for details. // | ||||||
// // | ||||||
// Provides the needed headers and defines for D3D reflection. // | ||||||
// // | ||||||
/////////////////////////////////////////////////////////////////////////////// | ||||||
|
||||||
#pragma once | ||||||
|
||||||
#ifndef _WIN32 | ||||||
// need to disable this as it is voilated by this header | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
#pragma GCC diagnostic push | ||||||
#pragma GCC diagnostic ignored "-Wnon-virtual-dtor" | ||||||
Comment on lines
+15
to
+17
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @pow2clk Didn't we disable this warning altogether as discussed in #3793 (review), or is it now enabled by default on newer compilers (since I only commented out, instead of leaving an unconditional |
||||||
// Need to instruct non-windows compilers on what an interface is | ||||||
#define interface struct | ||||||
#include "d3d12shader.h" | ||||||
#undef interface | ||||||
#pragma GCC diagnostic pop | ||||||
#else | ||||||
#include <d3d12shader.h> | ||||||
#endif |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
/////////////////////////////////////////////////////////////////////////////// | ||
// // | ||
// D3DReflectionStrings.h // | ||
// Copyright (C) Microsoft Corporation. All rights reserved. // | ||
// This file is distributed under the University of Illinois Open Source // | ||
// License. See LICENSE.TXT for details. // | ||
// // | ||
// Used to convert reflection data types into strings. // | ||
// // | ||
/////////////////////////////////////////////////////////////////////////////// | ||
|
||
#pragma once | ||
|
||
#include <d3d12shader.h> | ||
#include "dxc/DxilContainer/DxilRuntimeReflection.h" | ||
|
||
namespace hlsl { | ||
using namespace RDAT; | ||
namespace dump { | ||
|
||
// ToString functions for D3D types | ||
LPCSTR ToString(D3D_CBUFFER_TYPE CBType); | ||
LPCSTR ToString(D3D_SHADER_INPUT_TYPE Type); | ||
LPCSTR ToString(D3D_RESOURCE_RETURN_TYPE ReturnType); | ||
LPCSTR ToString(D3D_SRV_DIMENSION Dimension); | ||
LPCSTR ToString(D3D_PRIMITIVE_TOPOLOGY GSOutputTopology); | ||
LPCSTR ToString(D3D_PRIMITIVE InputPrimitive); | ||
LPCSTR ToString(D3D_TESSELLATOR_OUTPUT_PRIMITIVE HSOutputPrimitive); | ||
LPCSTR ToString(D3D_TESSELLATOR_PARTITIONING HSPartitioning); | ||
LPCSTR ToString(D3D_TESSELLATOR_DOMAIN TessellatorDomain); | ||
LPCSTR ToString(D3D_SHADER_VARIABLE_CLASS Class); | ||
LPCSTR ToString(D3D_SHADER_VARIABLE_TYPE Type); | ||
LPCSTR ToString(D3D_SHADER_VARIABLE_FLAGS Flag); | ||
LPCSTR ToString(D3D_SHADER_INPUT_FLAGS Flag); | ||
LPCSTR ToString(D3D_SHADER_CBUFFER_FLAGS Flag); | ||
LPCSTR ToString(D3D_PARAMETER_FLAGS Flag); | ||
LPCSTR ToString(D3D_NAME Name); | ||
LPCSTR ToString(D3D_REGISTER_COMPONENT_TYPE CompTy); | ||
LPCSTR ToString(D3D_MIN_PRECISION MinPrec); | ||
LPCSTR CompMaskToString(unsigned CompMask); | ||
|
||
// These macros declare the ToString functions for DXC types | ||
#define DEF_RDAT_ENUMS DEF_RDAT_DUMP_DECL | ||
#define DEF_DXIL_ENUMS DEF_RDAT_DUMP_DECL | ||
#include "dxc/DxilContainer/RDAT_Macros.inl" | ||
|
||
} // namespace dump | ||
} // namespace hlsl |
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.
Do we actually use any of the targets created by the subproject or do we just use the static headers?
If we just use the static headers we should instead be able to just have our FindD3D12 CMake module fall back to the submodule headers. That should simplify the CMake logic.
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.
Currently we do not. However, I greatly prefer the approach that DirectX-Headers takes to defining dx guids as it allows the same guid structure to have the same address across multiple files which ours does not.
I chose not to take that step with this change, but I want to take it going forward when I try to better consolidate the efforts to make non-Windows platforms look a bit more like Windows for DirectX purposes, which is a goal both projects share.
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.
Their GUID handling is all header defined too, right? The source for it just sets a single preprocessor define then includes headers.
If we want to migrate to use it we could define that ourselves, or we depend on their static archive target. The concern I have about their static archive target is that it means filtering target dependencies through the other CMake targets. If we're only doing that on Linux it feels like we might be introducing some extra complexity. Would we shift to using the submodule headers on Windows too?
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 mean to shift to using submodule headers on Windows as it would garner us certain advantages, not the least of which being easy access to more recent headers.
You make a good point that we could just as easily recreate dxguid.cpp. Regardless of where we land on Windows using these headers, that's a sufficient argument to simplify this.