Windows 10: D3D12 Translation Layer and D3D11On12 are now open source

Brink · Jan 17, 2020

If you’re a developer looking to port your game to DX12, we have good news: There’s a helper library available to get you there more easily!

We’re excited to announce that the D3D12 Translation Layer is now open source. The D3D12 Translation Layer is a helper library for translating graphics concepts and commands from a D3D11-style domain to a D3D12-style domain. As an example of how to use the library, we have also opened sourced D3D11On12, a mapping layer that maps graphics commands from D3D11 to D3D12.

Check out the source on GitHub:

D3D12 Translation Layer

D3D11On12

Read on to learn more about what this means for you.

A bit of history: Why mapping layers?

The first mapping layer project was started during the development of Windows 10 and D3D12. The Windows graphics team has a large set of D3D11 content which was heavily utilized during design and bring-up of the D3D12 runtime and driver models. In order to use that content, a mapping layer named D3D11On12 was developed.

This mapping layer proved successful and useful, to the point that a second mapping layer was developed, named D3D9On12. As the name implies, this maps from D3D9 to D3D12, and it has to solve a lot of the same problems as D3D11On12. D3D11On12 was thus refactored into two pieces: a part that implements the D3D11-specific concepts, and a more general part that translates more traditional graphics constructs into a modern low-level D3D12 API consumer. This more general part is what became the D3D12 Translation Layer. The translation layer code is currently being used by two mapping layers that ship as part of Windows: D3D11On12 and D3D9On12.

We realize that the D3D12 Translation Layer solves problems that are not unique 11On12 and 9On12, and we’re sharing the source with the graphics development community so others can reuse and benefit from our work. Both the D3D12 Translation Layer and D3D11On12 are available on GitHub today. If you have questions as you play with the code, feel free to reach out to us on Discord.

What can you do with the code?

Make the move to D3D12 more quickly. Leverage the D3D12 Translation Layer library as-is in your game to port your existing work to D3D12 faster.

Build a mapping layer from your favorite graphics or compute API to D3D12. Take advantage of a tested and conformant IHV DirectX 12 driver via your own D3D12 wrapper.

Contribute back to Windows. We welcome community contributions to both the D3D12 Translation Layer and D3D11On12. Improvements will be pulled back into the Windows codebase and eventually ship in future versions of Windows 10.

Learn more

D3D12 Translation Layer GitHub readme

D3D11On12 GitHub readme

D3D11On12 conceptual documentation

D3D11On12 reference documentation

D3D11On12 blog posts: First and second

Questions? Reach out on Discord

Angela Jiang
Click to expand...

Source: https://devblogs.microsoft.com/direc...w-open-source/

:)

Dennis Mop · Jan 17, 2020

Microsoft Translator

Hi,

One way of stopping Microsoft Translator is by uninstalling it. In order for you to uninstall the app, we recommend that you follow the steps provided below:

Press Windows key and type "translator".

Right-click Translator and select Uninstall.

Follow the instructions on the screen.

Let us know if you have other concerns.

Brink · Jan 17, 2020

Open Translators to Things: Open Approach for Accessing Similar Things

To help application developers more easily interact with the “Things” (e.g. light bulbs) around them, I am delighted today to introduce an alpha version of our new open source project Open Translators to Things (OpenT2T) on GitHub. Our goal is to enable application developers to write once, in an open and interoperable way, the exact same code to access functionalities that are shared across similar Things.

With this blog post, we introduce this new project and invite developers to take a look, check the code demo video, and hopefully join in making this open source project a success.

There are just too many different APIs that application developers need to use today to control very similar “Things” created by different manufacturers or by using different protocols. It was my honor to participate in Santa Clara in the Internet Architecture Board Semantic Interoperability workshop three weeks ago with 40+ participants (from OCF, AllSeen, W3C, Eclipse, OGC and others) to discuss this exact subject. At the workshop, I said that I would share some initial work we are doing on this to inform the conversation.

How many different APIs do you need to turn on a light, or read a temperature?

We believe end users prefer a very consistent user experience when they use similar devices (e.g. lightbulbs or thermostats), even when they come from different manufacturers or support different protocols. Similarly, we believe application developers need a consistent way to control similar devices as they create apps that can support, at scale, many manufacturers.

Suppose you want to build and sell a smart application for controlling the environment in peoples’ homes (or in factories), such as temperature, lighting, or ambience. Because you don’t control all of the environments in which your application runs, you need to support a number of different devices. But talking to these devices can be taxing.

Consider, for example, these small code snippets intended for reading the temperature from three different devices:

LM35 temperature sensor probe (adapted from here):

[table][tr][td]1[/td] [td]tempCC = (5.0 * reading(tempPin) * 100.0) / 1024.0 [/td] [/tr] [/table]

TMP36 temperature probe (adapted from here):

[table][tr][td]1[/td] [td]tempC = (5.0 * reading(tempPin) - 0.5) * 100[/td] [/tr] [/table]

Directly from a 10K Ohm Thermistor on a custom breadboard (adapted from here)

[table][tr][td]1 2 3[/td] [td]tempC = log(((10240000/ reading(tempPin)) - 10000)) tempC = 1 / (0.001129148 + (0.000234125 + (0.0000000876741 * tempC ^ 2)) * tempC ) tempC = temp - 273.15[/td] [/tr] [/table]

Similarly, how a developer turns on a light can vary much more than in the real world:

If you are using a Philips Hue (adapted from here):

[table][tr][td]1[/td] [td]PUT http://<bridge ip>/api/<username>/lights/1/state {"bri":254}[/td] [/tr] [/table]

If you are using a Wink Hub (adapted from here):

[table][tr][td]1[/td] [td]PUT https://api.wink.com/light_bulb/<device_id> {“desired_state": { “powered” : true} }[/td] [/tr] [/table]

Do app developers truly need to embed in their code specific knowledge of the characteristics of each physical device or hub?

The current alpha version uses JavaScript/Node.js, is open source and cross-platforms (with examples for Windows, OS X, Android, Azure, AWS). The basic logic, as we envision it, is composed of three parts: the schema, a translator, and the app.

“Things” start with schemas

We believe instead that developers should access a common “schema” across similar Things (e.g. a “Thermostat” or a “Light” schema) with specific properties (e.g. “Temperature” or “OnOff”).

Industry organizations, companies, or individuals create category schemas to describe devices (e.g. a schema to describe a light bulb or a thermometer). There are numerous existing initiatives doing this today with Open Connectivity Foundation’s oneIoTa tool being one of many examples. Microsoft will be working with the industry to create common schemas to describe similar Things, across protocols, in both the consumer and industrial space.

Translating a “Thing” to a common schema

Complementary to “schema” efforts, we also need a “translation” effort: We believe that the task of accessing the specific protocol calls supported by individual Things and turning it, here for example, into the Temperature or OnOff properties, is the job of a “translator” — a small piece of code that takes the input/output of an actual Thing and translates it into a common schema for application developers to access.

When many similar hardware devices are translated to the same schema, Cortana or apps or cloud automated rules can start targeting those common schemas and provide consistent and delightful experiences.

Developers interested in specific hardware will pick an existing schema (whatever is most suitable for that hardware) and write some cross-platform JavaScript code to translate the hardware to the schema. We think developers will “vote with their feet” and will connect their hardware to the most valuable schema they find and share their open source translator on OpenT2T. The best schema will get the most translators.

The job of the translator is to hide the implementation details about particular data models and protocols, exposing functionalities directly as programmable APIs. Turn a lightbulb on? No need for an app developer to think about RPC vs. REST, HTTP vs. MQTT, CoAP vs. ZigBee. What is needed is myBulb.turnOn() and the translator will map the API common schema call to the appropriate libraries to perform the operation. Cortana or other voice assistants could turn your bulb on whether it comes from Philips, Samsung, Wink, or another manufacturer.

Translators can run on local devices (PCs/tablets/phones) for proximally connected Things. Translators could also run in the cloud for cloud-connected Things or on gateways for gateway-connected Things and marshalled from the cloud.

The application experience

Application developers (client or cloud apps) can write the same code to control similar devices from different manufacturers, in an open and interoperable way. Developers achieve this by referencing the single category schema associated to similar Things and use the same function call defined by that schema to control them.

For example, suppose you want to write an application to read the temperature from a Texas Instruments CC2650 Sensor Tag. Here are the steps to do this, from the OpenT2T project:

Identify a category schema. In our initial alpha, we support the AllSeen schema syntax. You can see a very simple sample testing schema we wrote for our alpha version here. The goal is to bring consistency around schemas syntaxes and encourage the creation of schemas for different categories of Things. Together with you, we will do this through working with OCF and others in the industry. Our recommendation is to start with existing standard industry schemas though you may need to create sample schemas for testing purpose.

Find and use a translator already written by the community. Or help the community and write a translator for the data that comes off the CC2650 to that schema. The data that comes off the CC2650 device is described by Texas Instruments in a spec sheet, available here. You can see an example of that translator on the OpenT2T project here. The translator is written in JavaScript using Node.js in our alpha version but the community could decide to build support for other languages such as C++, C#, or Java.

Write an application that controls your Things, in this case the CC2650. You can see five sample applications on the OpenT2T project here. The alpha version has examples for writing UWP apps for Windows (C# example), Android apps (Java example), JavaScript/Node common cloud code (with Azure IoT Hub and AWS Kinesis specific examples). For example, in this temperature sample, there is a unique function call, m_Consumer.GetCurrentTemperatureAsync(), that needs to be called to get the temperature from all different hardware sensors that have been translated to the common sample schema.

Where we are right now and next steps

As an alpha project, we’re actively developing per our roadmap. Help us develop, test, and file issues. Keep in mind that it’s not ready for real deployment yet. The project is in the following six parts:

Translators: Repository of translators. They are grouped by translators written for a specific schema. The translator name is a unique string provided by the manufacturer identifying a “Thing” specific model
Next steps: We would love to work with the community to add new translators to the initial existing sample schemas, in order to help testing additional new Things and additional protocols.

Console: On PCs/tablets/phones, developers use the console app as a runtime to communicate with and onboard (i.e. initially setting up) actual Things. The console app hosts the node.js process: when a Thing is onboarded, it is recognized by its unique identifier, its translator loaded. The Thing is then exposed on the bus as a device supporting the schema it has been translated to.
Next steps: We hope the community will help us fully support Windows, OS X, finalize Android support, build iOS support, explore additional ways to host the runtime and to identify/build robust cross-platform libraries for the different protocol buses used to communicate with “Things”.

Cloud: In the cloud, developers use the same schema to communicate to similar Things translated to that schema in a node.js process.
Next steps: our call to the community is to help us test new Things and support additional protocols (CoAP, MQTT). We can achieve this by adding new translators, running on the cloud, for cloud-connected Things or by testing how to run Translators on gateways (e.g. Arduino, home Hubs, others) to gateway-connected Things marshalled from the cloud.

CLI: command line interface used by developers to onboard and communicate with actual Things and running the JavaScript translators.
Next steps: We would love to work with the community to round up the CLI to become the tool that developers use to run to test their JavaScript code.

Sampleapps: The alpha version provides samples of UWP apps for Windows (C# example), Android apps (Java example), JavaScript/Node common cloud code (with Azure IoT Hub and AWS Kinesis specific examples)
Next steps: We can work with the community to add sample apps for other UI frameworks such as Xamarin, Cordova or Swift and for other clouds such as Google Cloud.

Voice: By adding a voice file that can understand a specific schema, developers enable their favorite assistant to control virtually all similar things that are translated to that schema. A few samples voice files are provided for Cortana to control lights and thermostats.
Next steps: we would love to see the community add more voice files for Cortana for different categories of things and provide samples for other assistants such as Alexa and others.

How to get involved and join the discussion

Our hope is that developers will check out the project, view an end user and code demo videos, read the tutorial, ask questions, and contribute a first translator for their favorite hardware and overall to the project (please check our initial roadmap).

We are looking forward to continuing the discussions about Translation to Things in the Open Connectivity Foundation and with other groups, such as the Internet Architecture Board Semantic Interoperability workshop participants. Grounding those discussions around real code will help us tremendously.

We also checked the interest of other IoT developers and manufacturers in many companies in this space and many of them agreed to continue the conversation in the GitHub project. Among them are Sol Salinas (Accenture), Sergey Grebnov (Akvelon Inc), Acer, ASUS, David Plans (BioBeats), Dell, Lenovo, John Cameron (LIFX), Daniel Quant (Multitech), Brad Ree (Nortek), Jonathan Pickett and Charles Prakash Dasari (Schakra Inc.).

Today, we have pushed some alpha code on GitHub to start the conversation around translating Things to common schemas. In time, we hope OpenT2T becomes a vast repository of crowd-sourced cross-platform translators supporting a broad set of hardware Things and constantly curated by a thriving community where similar translators can compete, collaborate, combine, or diverge. Everyone could write a new translator to support a new hardware, from industry organizations to startups, from manufacturers to students, from enterprise to hobbyists. Translators can and will be forked, cloned, patched and discussed publicly: the proven dynamics of open source development will make the best translators associated to the best schemas emerge and provide long-term sustainability.

Written by Jean Paoli, Windows Developer Platform

Click to expand...

Source: Open Translators to Things: An Open Approach for Accessing Similar Things | Building Apps for Windows

Divya Murugan · Jan 17, 2020

WIn 10 and IE 11 Google translate reports translating site but nothing happens.

Hi John,

Thank you for posting your query on Microsoft Community.

I appreciate your interest in Windows 10. We sincerely regret for the inconvenience caused.

I suggest you to add the Google translate website in compatibility mode and check if it helps:

Follow the steps:

Open internet explorer.

Click on ALT key in key board.

Click on tools tab

Select compatibility view settings

Add the website

Click ok.

Hope this information helps. Post back with updated issue details for further help.

Windows 10: D3D12 Translation Layer and D3D11On12 are now open source

D3D12 Translation Layer and D3D11On12 are now open source

D3D12 Translation Layer and D3D11On12 are now open source

D3D12 Translation Layer and D3D11On12 are now open source

D3D12 Translation Layer and D3D11On12 are now open source - Similar Threads - D3D12 Translation Layer

WinAppDriver open source

Kaizala Open source

D3D12 Debug Layer Message Callback feature is now available

D3D12 Debug Object Auto-Naming option now available

Layers

Google Translate now provides gender specific translations

Skype Translator Preview Now Available

MSBuild Engine is now Open Source on GitHub

Classic Shell no longer in development, and now open source

Users found this page by searching for:

D3D12 Translation Layer how work

11on12 open source