Jump to content

  • Log In with Google      Sign In   
  • Create Account


Direct3D on ARM processor polygons overlapping


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Vexal   Members   -  Reputation: 416

Like
0Likes
Like

Posted 22 November 2012 - 03:32 AM

BACKGROUND:

I have a program set up to run on ARM, Win32, and x64 architecture. The program can run either with the Windows RT Store API or with Win32 API. The code, aside from the initialization is shared between the win32 and Windows RT versions.

The code for the ARM, Win32, and x64 versions are the same*. The program checks whether the card card can use a particular Direct3D feature level -- the Surface tablet I test the program on supports 9_1. The laptops support 11_1. In cases where the feature level supported is 9_1, the code that runs is slightly different in that it uses unsigned short for indices and some tiny other variations.

*The compiled code between x64 and the other platforms differs in that for the non-x64 versions, there is some extra code to maintain 16 byte alignment.

ISSUE:

The program renders correctly on all modes on my laptop (x64 i7), but does not render correctly on the ARM processor on the Surface tablet (nvidia tegra 3).

Pictures:
http://i.imgur.com/zYkkn.png -- the correct version compiled in x86 mode running on a laptop.
http://i.imgur.com/ZGQ9F.png -- the incorrect version compiled to ARM running on the nvidia tegra 3 Surface tablet.

The incorrect version has holes and gaps -- these holes and gaps are dependent on the view angle, and appear to only come up when there is something behind the polygon.

Forcing the x86 version to be compiled as 32 bit or use feature level 9_1 does not reproduce the issue on the x86 machine, even though in this case the code is completely identical to the ARM compilation.

The problem disappears in wireframe mode.

What is wrong?

Edited by Vexal, 22 November 2012 - 03:37 AM.


Sponsor:

#2 Erik Rufelt   Crossbones+   -  Reputation: 3285

Like
2Likes
Like

Posted 22 November 2012 - 04:02 AM

Try modify your near/far plane, perhaps the tablet device uses a 16-bit Z buffer which could lead to something like that. Also double-check that you clear your buffers and set up Z-test correctly.. but I guess since it only happens when something is behind the polygon it has to do with the depth (and it looks like it's the color behind that bleeds through so that seems likely). You could double-check by changing draw-order to front-to-back to see if that fixes the problem, or changing Z-test between Less and LessOrEqual.

#3 Vexal   Members   -  Reputation: 416

Like
0Likes
Like

Posted 22 November 2012 - 05:09 AM

The code for setting up and clearing the buffers is compiled from the same file for both the ARM version and the x86 / 64 version.

For the ARM version, the z buffer is initialized identically to the sample that comes with Visual Studio 2012 that draws a cube. I tried lowering the z distance to 500, but it was already only 5000 which is well below 16 bit.

Switching to DepthFunc = D3D11_COMPARISON_LESS_EQUAL appears to cause the problem to be on different parts of the cubes.

#4 Hodgman   Moderators   -  Reputation: 29383

Like
1Likes
Like

Posted 22 November 2012 - 05:14 AM

I tried lowering the z distance to 500, but it was already only 5000 which is well below 16 bit.

Depth buffer values are stored logarithmically, which means approximately half of your precision is used to represent the values between the near plane and twice the near plane.
This is a simplification, but to illustrate -- with a 16-bit buffer imagine a pixel with depth of near == 0x0, a pixel with depth of far == 0xFFFF, and a pixel at 2 * near == 0x7FFF.
So, it's very important that you don't use a small value for the near plane. The far-plane isn't very important in comparison.

Edited by Hodgman, 22 November 2012 - 05:17 AM.


#5 Vexal   Members   -  Reputation: 416

Like
0Likes
Like

Posted 22 November 2012 - 05:22 AM

Oh, wow. Thanks a lot. Switching the near plane to 100 (originally .01) fixed it.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS