Sign in to follow this  

Direct3D on ARM processor polygons overlapping

Recommended Posts


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.


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).

[url=""][/url] -- the correct version compiled in x86 mode running on a laptop.
[url=""][/url] -- 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

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
[quote name='Vexal' timestamp='1353582552' post='5003198']
I tried lowering the z distance to 500, but it was already only 5000 which is well below 16 bit.
[/quote]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 [font=courier new,courier,monospace]near[/font] == 0x0, a pixel with depth of [font=courier new,courier,monospace]far[/font] == 0xFFFF, and a pixel at [font=courier new,courier,monospace]2 * near[/font] == 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

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this