Jump to content


Shader compiler bug? (DX10)


9 replies to this topic

#1 AGPX

    Member

  • Members
  • PipPip
  • 44 posts

Posted 17 August 2008 - 10:04 AM

Hi,

I have a geometry shader (DirectX 10 SDK, June 2008), like the following:

#define MAXTEXCOORDS 8

struct VSOutput
{
    float4 pos:              SV_POSITION;
    float2 UV[MAXTEXCOORDS]: TEXCOORD;
};

int normalMapUVChannel;  // From 0 to 7

[maxvertexcount(3)]
void GS(triangle VSOutput input[3], inout TriangleStream<GSOutput> OutputStream)
{
    float DeltaU1 = input[2].UV[normalMapUVChannel].x - input[1].UV[normalMapUVChannel].x;

etc...

}

The shader compiler report the following errors:

error X8000: D3D10 Internal Compiler Error: Invalid Bytecode: Overlapping input index range decl encountered. Opcode #28 (count is 1-based).
error X8000: D3D10 Internal Compiler Error: Invalid Bytecode: Can't continue validation - aborting.

The error is generated by the first line. Note if I make the index constant, the error disappear:

float DeltaU1 = input[2].UV[0].x - input[1].UV[0].x;

but in this way I need to replicate the shader 8 times (that moreover it's already replicated for other reasons), that's quite a problem. :wallbash:

Someone know a workaround to this? Thanks in advance.

- AGPX

#2 starstutter

    Senior Member

  • Members
  • PipPipPipPip
  • 1039 posts

Posted 17 August 2008 - 03:32 PM

I'm not sure this is it, but it seems to be that the shaders can only take unique semantics for each variable. Meaning in dx9, it gives me an error if I use the semantics:

float2 uv1 TEXCOORD0
float2 uv2 TEXCOORD0

If you've seen shader assembly language, the reason for this becomes pretty obvious.

So in you're code, you're doing the equivelant of:

float2 uv1 TEXCOORD0
float2 uv2 TEXCOORD0
float2 uv3 TEXCOORD0
float2 uv4 TEXCOORD0
.....ect


Like I said,
Im not sure if that was any help and it still doesn't make sense to me that a constant would work in place of #define... but this wouldn't be the first time I've heard of directX having a complier error.
(\__/)
(='.'=)
This is Bunny. Copy and paste bunny into
(")_(") your signature to help him gain world domination.
bunny also wants to fight spam: Click Here Bots!

#3 AGPX

    Member

  • Members
  • PipPip
  • 44 posts

Posted 17 August 2008 - 04:35 PM

Hi, thanks for reply.

I don't remember in DirectX 9, but in DirectX 10 the semantic are automatically forwarded. So:

float2 UV[MAXTEXCOORDS]: TEXCOORD;

give:

UV[0]: TEXCOORD0

UV[1]: TEXCOORD1

UV[2]: TEXCOORD2
...

etc...

If I try something like:

float2 a : TEXCOORD0

float2 b : TEXCOORD0

I receive the following error messages:

warning X4711: Duplicate non-system value semantic definition: input semantic 'TEXCOORD0' and input semantic 'TEXCOORD0'

error X4503: output TEXCOORD0 used more than once

So, this shouldn't be the problem. I think that the problem stay in the access to array inside an array via a variable. Probably a compiler and/or SM 4.0 limit.

- AGPX

#4 Kenneth Gorking

    Senior Member

  • Members
  • PipPipPipPip
  • 939 posts

Posted 18 August 2008 - 10:28 AM

Have you tried to simplify the statement?


VSOutput vsi1 = input[1];

VSOutput vsi2 = input[2];

float DeltaU1 = vsi2.UV[normalMapUVChannel].x - vsi1.UV[normalMapUVChannel].x;


or


float DeltaU1 = input[2].UV[normalMapUVChannel].x;

DeltaU1 -= input[1].UV[normalMapUVChannel].x;

The compiler may be freaking out over all the struct/array access, but I'm not sure. It's worth a try though.
"Stupid bug! You go squish now!!" - Homer Simpson

#5 AGPX

    Member

  • Members
  • PipPip
  • 44 posts

Posted 18 August 2008 - 02:17 PM

Hi,

yes, I have tried both your proposed changes (and many others), but the error still occurs. Sound like a Microsoft compiler bug. :no:

#6 starstutter

    Senior Member

  • Members
  • PipPipPipPip
  • 1039 posts

Posted 18 August 2008 - 05:16 PM

well, I guess you could just do it the old fashioned way :P
(\__/)
(='.'=)
This is Bunny. Copy and paste bunny into
(")_(") your signature to help him gain world domination.
bunny also wants to fight spam: Click Here Bots!

#7 AGPX

    Member

  • Members
  • PipPip
  • 44 posts

Posted 18 August 2008 - 08:11 PM

I have reported this issue to Microsoft... maybe that I receive some support... :lol:

#8 Kenneth Gorking

    Senior Member

  • Members
  • PipPipPipPip
  • 939 posts

Posted 18 August 2008 - 11:10 PM

I wouldn't hold my breath... :D
"Stupid bug! You go squish now!!" - Homer Simpson

#9 AGPX

    Member

  • Members
  • PipPip
  • 44 posts

Posted 19 August 2008 - 01:09 PM

Ok man,

I have received an e-mail from Microsoft's man. He wrote: "Barring any unforeseen circumstances, this issue should get fixed in the November release. In the meantime, a workaround is to make the vertex indices dynamic as well as the interior index (ie, vert[someindex].tex[otherindex])." :happy:

That is, instead of:

float DeltaU1 = input[2].UV[normalMapUVChannel].x - input[1].UV[normalMapUVChannel].x;

you have to write:

uint baseindex = 0;
float DeltaU1 = input[baseindex + 2].UV[normalMapUVChannel].x - input[baseindex + 1].UV[normalMapUVChannel].x;

...and this works! :worthy:

Ok, I've learned the lesson: next time, instead of try to simplify the expression, I will try to make it more complex! :lol:

I hope this post can help somebody else.

Bye for now,

- AGPX

#10 Kenneth Gorking

    Senior Member

  • Members
  • PipPipPipPip
  • 939 posts

Posted 19 August 2008 - 06:41 PM

That was fast :)
I'm still waiting for a reply to the mail I sent to nVidia in 2005... Good to see that some companies actually respond to user feedback.
"Stupid bug! You go squish now!!" - Homer Simpson





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users