Closed GoogleCodeExporter closed 8 years ago
Is there any output from the debug runtime layer?
Original comment by josh.petrie
on 11 Mar 2010 at 2:41
I have enabled the debug layer on DX11 (pointed to my application first, then
set the
"Force on" radio button. No other checkboxes are on.) I also tried to enable the
debug unmanaged code option in my C# project. Nothing changes, the same problem
occur. Maybe there is something more I have to change?
I also tried to debug step by step the SlimDX code: The effect compiles well,
there
are no compilation errors. But then, the call to D3DX11CreateEffectFromMemory
in the
Effect-Constructor returns nothing for the effect and a negative hr.
Maybe this is a bug in DX? If you can explain step by step, how I can provide
you
more info, for example, if I missed something to enable the debug layer, please
tell me.
I think, you can try it yourself. Just create a simple effect and in the
technique
set the hull and domain shader to "0". (Or use an existing DX11 example
effect.) This
effect should compile fine using fxc.exe. But calling to:
new Effect(device, ShaderBytecode.CompileFromFile("effect.fx", "main", "fx_5_0",
ShaderFlags.None, EffectFlags.None), 0);
should throw an error.
Original comment by remi2...@googlemail.com
on 11 Mar 2010 at 9:10
LOL, now I have with 70% chance on starting my application this error:
Unbehandelte Ausnahme: System.ArgumentException: Ein Element mit dem gleichen
Schlüssel wurde bereits hinzugefügt. (This means: Tere is already an element
with the
given key.)
bei System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
bei System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean
add)
bei SlimDX.ObjectTable.Add(ComObject comObject, ComObject owner) in
dev\slimdx\source\objecttable.cpp:Zeile 105.
bei SlimDX.ComObject.Construct(IUnknown* pointer, ComObject owner) in
dev\slimdx\source\comobject.cpp:Zeile 116.
bei SlimDX.Direct3D11.DeviceContext..ctor(ID3D11DeviceContext* pointer, ComObject
owner) in dev\slimdx\source\direct3d11\devicecontext11.cpp:Zeile 73.
bei
SlimDX.ComObject.ConstructFromPointer<SlimDX::Direct3D11::DeviceContext,ID3D11De
viceContext>(ID3D11DeviceContext*
pointer, ComObject owner, ComObjectFlags flags) in
dev\slimdx\source\comobject.h:Zeile 94.
bei SlimDX.Direct3D11.Device.get_ImmediateContext() in
dev\slimdx\source\direct3d11\device11.cpp:Zeile 113.
What I have done? Oo Why this now?
Original comment by remi2...@googlemail.com
on 11 Mar 2010 at 9:17
The last exception may be an unrelated bug.
What feature levels are you using to create the device, and what feature level
are
you actually getting selected at runtime? That will be neccessary to try to
reproduce
this.
Original comment by josh.petrie
on 11 Mar 2010 at 4:48
Ok, I create my device this way:
factory = new Factory();
device = new Device(factory.GetAdapter(0));
For some reason, this is the one and only way I can create a device supporting
the
Level_11_0. After that, if I ask the device, it has the proper Level_11_0. With
a
lower level the "fx_5_0" target for the effect compiler would fail, I think. ^^
For the other bug: I posted this as an other isue, I hope, this is ok for you.
Original comment by remi2...@googlemail.com
on 11 Mar 2010 at 6:47
I tried to debug this today. All I know, is, that the shader compiles well,
because
there are all values inside like technique etc. Then the
D3DX11CreateEffectFromMemory
function fails, without touching the shader stream (but I don't know this for
sure).
It's pointer seems to point still to index 0 after the
D3DX11CreateEffectFromMemory
function returns.
If I remove the SetHullShader(0); and SetDomainShader(0); functions from my
effect
file, all is running fine.
I have an other idea to explain this behaivour:
Maaaaaaaaaybeeee the HLSL team allow as to set this functions to 0, BUT the DX
team
suppose, that IF we use those two shaders, then we always define both of them
together AND this will replace the old one. And after that, IF we want to use an
effect without those two shaders, THEN we can leave them out from the pass and
then
we can't use control points as input anymore. But if we don't use control
points,
then the old hull/domain shader will be automatically ignored -> implicitly
disabled
for that pass ^^. And then the DX team leader said: "Guys, we do not have to
support
SetHull/DomainShader(0); explicitly!"
Original comment by remi2...@googlemail.com
on 13 Mar 2010 at 12:19
I just ran into this exact same issue.
Setting the Hull and Domain shaders to 0 or NULL causes the Effect constructor
to
throw an exception.
The DirectX debug says this:
"Effects11: Internal loading error: invalid shader index."
Which leads me to believe it is on the DirectX side and that I'm just probably
doing
something wrong. Is there another way to disable the Hull/Domain Shaders?
I am using feature level 11_0.
Original comment by mccarthp
on 17 Mar 2010 at 7:26
I did some more searching online, and this is definitely on the DirectX side,
but it
is (apparently) the way DirectX works by design.
The solution is to disable them using the Device, like so:
device.ImmediateContext.HullShader.Set(null);
device.ImmediateContext.DomainShader.Set(null);
This solves the problem, so it is no longer an issue.
Original comment by mccarthp
on 17 Mar 2010 at 7:43
AS I said, if you disable them, you can't use control points anymore, you have
to use
normal vertices instead. But if you use normal vertices, then you don't have to
disable the hull/domain shaders, because they are automatically ignored. So
specifing, that you want to use for example trianglestrip instead of patches
with 3
controlpoints automatically ignores the hull/domain shaders.
Maybe this is the reason, why MS want not correct the bug so fast.
Original comment by remi2...@googlemail.com
on 17 Mar 2010 at 9:26
Original comment by josh.petrie
on 18 Mar 2010 at 5:25
Original issue reported on code.google.com by
remi2...@googlemail.com
on 10 Mar 2010 at 9:03