Closed GoogleCodeExporter closed 9 years ago
Fumbling through this --
Std140BlockEncoder::advanceOffset just advances by
gl::UniformComponentCount(type), which is 1 for GL_INT.
So this struct will advance the offset by 2 (one for each member of the
struct), likely because the GL packing rules would have these structs packed.
But it looks like HLSL struct members are not packed, and each one needs to eat
up a full register in HLSL.
Original comment by vladim...@gmail.com
on 20 May 2014 at 5:53
looking now. if it's true ints are not packed you are correct, however I
couldn't repro this with a sample application using the above shader, trying
with essl_to_hlsl.
Original comment by jmad...@chromium.org
on 20 May 2014 at 5:54
I think I see the problem -- it may be a difference in behaviour from D3D9 to
D3D11. If you feel like finding a solution, feel free to make a patch,
otherwise I'll look at it when I have time.
Original comment by jmad...@chromium.org
on 20 May 2014 at 5:59
I just put up https://chromium-review.googlesource.com/200620 which fixes this
problem, but maybe it's not the right kind of fix.
Original comment by vladim...@gmail.com
on 20 May 2014 at 6:02
Hmm, in
http://msdn.microsoft.com/en-us/library/windows/desktop/bb509581%28v=vs.85%29.as
px :
> Differences between Direct3D 9 and Direct3D 10 and 11:
>
> Unlike the auto-allocation of constants in Direct3D 9, which did not perform
packing and instead assigned each variable to a set of float4 registers, HLSL
constant variables follow packing rules in Direct3D 10 and 11.
Which I think does indeed say that D3D10/11 do packing, but D3D9 is not packed
and everything is at least one float4.
Original comment by vladim...@gmail.com
on 20 May 2014 at 6:11
Original comment by jmad...@chromium.org
on 20 May 2014 at 7:01
This is actually a pretty bad breakage for D3D9. Shannon, we should fix this
before the branch. I think this is also a good example of where having more
testing for the D3D9/ES2 legacy path would be helpful.
Original comment by jmad...@chromium.org
on 20 May 2014 at 7:02
Before which branch? M36 branched more than a week ago, and if we need the fix
there, it will need a merge, and should be addressed immediately. If it's an
issue with the new master branch only, then we need just to avoid rolling
Chrome until after a fix lands in ANGLE.
Original comment by shannonw...@chromium.org
on 20 May 2014 at 7:10
Sorry I confused you with my terminology -- before we roll the new ANGLE maser
branch to Chrome.
Original comment by jmad...@chromium.org
on 20 May 2014 at 7:11
Thanks for clarification-- panic averted!
Original comment by shannonw...@chromium.org
on 20 May 2014 at 7:13
Original comment by jmad...@chromium.org
on 26 May 2014 at 2:37
CL committed: https://chromium-review.googlesource.com/#/c/200620/
Original comment by jmad...@chromium.org
on 29 May 2014 at 9:00
Original issue reported on code.google.com by
vladim...@gmail.com
on 20 May 2014 at 5:34Attachments: