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?
Show differencesHistory of post edits
#2Vexal
Posted 22 November 2012 - 03:36 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, objects overload new 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?
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, objects overload new 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?
#1Vexal
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, objects overload new 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.
What is wrong?
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, objects overload new 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.
What is wrong?