Figure 10.1 illustrates how the nDDI architecture was adapted for networked use for the connected display wall use case. The nDDI display is now a standalone server application. The single application driving the nDDI link from our previous architecture diagrams is replaced by multiple clients connected over an nDDI Link built on top of standard Internet protocols.
The original nDDI simulation developed for the PixelBridge experiments consisted of a single application. The nDDI Display Wall simulation has three networked applications:
nDDI Link
x y
Input Vector Coefficient
Planes
Frame Volume
. . .
Display Panel nDDI Display Device
nDDI Engine
. . .
(r, g, b) M nDDI Display Server
nDDI Clients
Figure 10.1 Revised nDDI Architecture diagram for networked configuration.
• nDDI Display Server • nDDI Master Client
• nDDI Subordinate Client(s)
10.1.1
nDDI Display Server
The nDDI Display Server is a standalone application which simulates an nDDI display in much the same way as the original PixelBridge. It listens for nDDI commands on a socket and interacts with the simulated nDDI display through the nDDI API. The simulated display can be implemented on the host machine’s CPU or GPU.
The nDDI commands previously defined by the nDDI API are now implemented as networked commands. When the server receives an nDDI command, it converts the arguments into corresponding C++ nDDI API calls into the simulated nDDI display. Additionally, three new nDDI commands were added.
• Initialize- Used to trigger a call to the C++ constructor for the simulated nDDI display.
• Shutdown- Causes the nDDI Display Server to destroy the simulated nDDI display and to terminate. • Latch- Used by clients to indicate when a region of the simulated nDDI display should be updated. In
the PixelBridge experiments, this was triggered with a request for the simulated nDDI display’s output framebuffer. The Latch command makes this explicit for the specified region.
• ClearCostModelUsed to trigger the server to clear the cost model for the simulated nDDI display.
10.1.2
nDDI Clients
nDDI Clients still interact with the nDDI Display Server via the nDDI API. With the PixelBridge experiments, the nDDI API was implemented as a simulated nDDI display. This new implementation of the API sends nDDI commands to the server (see appendix E). The new implementation includes new API calls for the additional nDDI commands. These new commands lay the groundwork for collaboration amongst the clients while specifically avoiding the need to build any specific synchronization primitives. For instance, the Initialize command is not restricted to any single client, and therefore it implies that clients must work out their strategy for collaboration. Furthermore, clients do not explicitly reserve portions of the frame volume and coefficient planes.
For our connected display wall experiments, we employed a master/subordinate strategy. The nDDI Master Client connects to the nDDI Display Server and sends the Initialize command. The nDDI Subordinate Clients then connect to the nDDI Display Server and initialize their own subregions of the coefficient planes. nDDI Subordinate Clients are responsible for updating their subregions of the display, which is accomplished with a Latch command for that subregion after they have updated the coefficient planes and any related areas of the frame volume.
Our simple scheme for configuring the nDDI Display Server did not require a more sophisticated strategy, however it is quite possible to build such a strategy outside of the scope of the nDDI Display Server. For instance, the nDDI Master Client can act as a gatekeeper for all of memory components of the nDDI display: configuration, input vector, coefficient planes, and frame volume. The nDDI Subordinate Clients would cooperate by agreeing to avoid writes to areas that they have not explicitly reserved through the nDDI Master Client. While this is sufficient, it is far from secure. Extending the nDDI Link to cover these requirements is quite feasible, though outside of goals for this experiment. Instead, we focused on the connected display wall use cases and the efficiency of network extensions for the nDDI Link.
10.1.3
nDDI Link Protocol
In the previous discussions of the nDDI architecture and our prior experiments, the nDDI Link was never specified. The nDDI abstraction and command set was our priority, and details of the nDDI Link were left as
an engineering exercise. Our final connected display wall experiment required an nDDI Link design to be built upon an Internet protocol, and so we worked to specify the nDDI Link to an adequate level to enable the experiment.
The GrpcNddiDisplay implementation of the nDDI API used by the clients interacts with the nDDI Display Server using Google’s Remote Procedure Call definitions.(gRPC, 2019) gRPC is a fast, RPC framework built upon HTTP/2.(Thomson et al., 2014) Specifically, the protocol was defined using Google’s Protocol Buffers (protobuf) mechanism for serializing the nDDI command parameters and returning data.(protobuf, 2019) The effect of these design choices, was that the new GrpcNddiDisplay implementation of the nDDI API simply made gRPC calls with data that was encoded with the protocol that we defined using protocol buffers and sent to the server over HTTP. The data from the HTTP response(s) was then decoded into return values for the client.