Hello
I’m doing D3d9 activation.
The three "reg add" commands in the attached text file are executed from the command prompt started with administrator privileges on the actual machine.
After executing the command, when you check the corresponding registry key with the registry editor, it looks like the attached image.
If I restart the OS in this state, can I assume that D3D9 is enabled?
Thanks,
Koji Okuda.
this is disable as default, you need enable it according to the release note
https://www.nxp.com.cn/docs/en/release-note/IMXWNR.pdf
this is intended for customers to test existing WPF apps, if you have existing WPF apps, you can test it, maybe Microsoft has some WPF apps online, you can search it
Hello. joanxie,
I referred to the release notes and wrote how to enable D3D9 that I understood myself, is this correct?
What kind of tests did your company do when releasing the BSP that supports D3D9?
If there is an application that was used at that time, would it be possible to provide it?
Best regards,
Koji Okuda.
Hi Okuda, we focused our application testing with our WPF samples here: https://github.com/microsoft/WPF-Samples/tree/1dbe1e139c0bca15f4c25b626f28588b0d8e427c
Hi, anthonychen-msft.
Thank you for your support.
I have a question about building and running the WPF sample application on the actual machine.
Best regards,
Koji Okuda.
Hi @okuda ,
It looks like the project just got updated last week to depend on Visual Studio 2022 17.7.33711.374 and the .NET SDK/Runtime 8 preview. I haven't gotten a chance to try building it and running it yet, but you are free to try it in the meantime.
There isn't any special Arm SDK needed for D3D9.
On the NXP device, you'll need to install the correct Arm64 .NET Runtime to run the application. I'm told that the app will prompt you to download the correct version, but if it doesn't, this is the one that the application depends on: Download .NET 8.0 (Linux, macOS, and Windows) (microsoft.com). Make sure you install the Arm64 Desktop Runtime (circled in Red below)
Hi, anthonychen-msft.
The page you told me has the following description, but does it mean that it can not be built with VisualStudio2019?
(After actually downloading the ZIP and installing .Net6, I tried to build using VisualStudio2019, but an error occurred.)
To use the samples with Git, clone the WPF-Samples repository with 'git clone "https://github.com/microsoft/WPF-Samples"
After cloning the WPF-Samples respository, there will be two solution files in the root directory: WPF-Samples.sln and WPF-Samples.msbuild.sln
The easiest way to use these samples without using Git is to download the zip file containing the current version (using the link below or by clicking the "Download ZIP" button on the repo page). You can then unzip the entire archive and use the samples in Visual Studio 2019.
Best regards,
Koji Okuda.
I checked the downloaded files in that repository, and they also have a dependency on .NET 8 / VS2022 Visual Studio 2022 17.7.33711.374. So the readme in the repository is wrong. I also originally tried building the solution with my existing .NET 7 SDK and it failed to build.
Are you familiar with git?
If you are, I discovered you can clone a different branch in that repository that is built for .NET 7 so you don't need to install the .NET 8 Preview SDK/ Runtimes: microsoft/WPF-Samples at release/7.0 (github.com) Note: the link to the downloadable zip file of the solution is broken in this branch, so you'll need to use git to download this branch.
Hi, anthonychen-msft.
I created a new environment with VisualStudio2022 and .Net8.
In that environment, I was able to build the zip project.
Also, although not all of the samples, I was able to confirm that they can be executed on the x64 environment.
If I copy the file created in the build framed in red in the attached image to the actual Arm machine, can I think that I can check the operation by executing the EXE file?
(If the ARM64 version runtime corresponding to the .Net8 SDK installed in the build environment is installed on the actual machine.)
Best regards,
Koji Okuda.
Hi @okuda
Glad to hear that you were able to build it and verify that it ran on your x64 machine.
Yes, just copy that folder to the NXP device and run the .exe. You also want to make sure that when you use Build -> Publish Selection, that the Target Framework is set to the right version (e.g. net8.0-windows), and that the Target Runtime is set to the right runtime (e.g. win-arm64).
Hi, anthonychen-msft.
I tried it with both .NET8 and .NET7, but an error occurs when I run it on the actual machine.
Of course, the version of Runtime (ARM64) corresponding to the SDK used in the build is installed on the actual machine.
(The attached image Install_runtime_version.png is a screenshot when checking the .NET Runtime version when using .NET7.)
You can see that the attached image Project_Info_1.png uses .NET7.0.
You can check the Platform target settings in the attached image Project_Info_2.png.
The question in this image is that the red frame is "ARM64", but the blue frame in the project build settings is "AnyCPU".
Could this be the cause?
What should I investigate and how should I respond?
The application is running without any problems on the PC environment in which it is being built.
(x64 environment)
Best regards,
Koji Okuda.
Hi @okuda
When you publish the application, you can publish it as a "Self-Contained" application so that the application includes the correct .NET Runtime version required to run on the target device. (see: Application publishing - .NET | Microsoft Learn). This helps eliminate issues with figuring out the correct Runtime version to install on the device. Here's how to do this in a way where we sideload (e.g. manually copy the files over) the application to the device:
1. Select the project you want to build (SlidePuzzleDemo in your case)
2. Select Build -> Publish Selection
3. This will take you to the Publish page. If it's your first time publishing the application, a pop-up will ask you Where you'd like to publish your application.
If you've published the application before, it will show you a Publishing Profile. Click on the .pubxml dropdown menu at the top and try to find one that has an icon that looks like a Folder and a name that looks like "FolderProfile.pubxml". If you can find one, skip to step 6.
If you can't find an existing FolderProfile, click on the + icon that says New Profile
4. Select Folder as both the Target and Specific Target
5. Specify where the files will be placed and select Finish
6. In the Publishing Profile, click on the More Actions dropdown and select Edit
7. For Deployment mode, select Self-Contained. For Target runtime, select win-arm64. Under File publish options, select Product single file. Then click save.
8. Click the Publish button
9. Copy the folder to your NXP device and run the .exe file.
Hi, anthonychen-msft.
As shown in the attached image, I was able to run the application.
1.What did I do wrong in my steps?
2. Is it possible to remotely debug from the PC where the build environment is located?
3.I was able to check the operation of some of the WPF samples on the actual machine,
but what should I do to check the operation of D3D9?
(Do I have to create my own application using this environment?)
Best regards,
Koji Okuda.
Hi @okuda
1. Good to see that you were able to run the application. It doesn't look like you did anything wrong in your steps.
2. It's possible to remotely debug from the PC where the build environment is located. Follow this guide here: Remote Debug a C# or VB project - Visual Studio (Windows) | Microsoft Learn You won't be able to use the "Publish as Self-Contained Application" method that I shared earlier for this, so you'll need to make sure you have the correct Arm64 .NET Runtime installed on the NXP device, and that the application is getting built for Arm64.
3. WPF uses D3D9 automatically if the GPU supports it. So if D3D9 is being used, you will see GPU activity change in the Task Manager any time the application UI changes. If it is not being used, the GPU activity will be close to zero. I believe there might be another tool to check if an application is using D3D9, but I'll have to follow-up with our graphics developers and get back to you on this.
Hi, anthonychen-msft.
I apologize for the delay in replying as I was dealing with another matter with higher priority.
Regarding debugging, I will check what you have replied and try running it once.
Is there any new information about tools related to D3D9?
I believe that the content of this exchange should originally have been conducted through Microsoft's contact point.
I checked the Microsoft community, but I couldn't find the right point of contact for questions like this.
If I want to ask a question like this through a Microsoft contact, which contact should I use?
(A contact point where you can make inquiries free of charge)
Best regards,
Koji Okuda.
Hi @okuda
For tools related to D3D9:
Our team primarily tests the D3D9 driver using a subset of the Device.Graphics tests in the Windows Hardware Lab Kit (HLK).
This is not something we expect partners/customers to do, as it is quite involved to set up and run.
If you want to check what processes are using D3D9 on a given system, you can enter the following in the command prompt:
tasklist.exe /m d3d9.dll
Microsoft has a Windows IoT forum that is similar to NXP's i.MX forum here: Windows 10 IoT - Microsoft Community Hub
Thanks,
Anthony
Hi, anthonychen-msft.
Thank you for the new information.
I am currently working on another matter, so I will confirm the information you have received as soon as that matter is completed.
Another issue is to use the I2C of NXP's reference board to implement HID over I2C.
I will create a separate thread about HID over I2C, so if you have any information, please give me your answers and advice there.
Best Regards,
Koji Okuda.