1 ¿HA SENTIDO CAMBIOS DE CONDUCTA EN SU REPRESENTADO AL MOMENTO DE ACUDIR A LA ENTIDAD EDUCATIVA?

The connected display wall experiments leveraged the nDDI Command Recorder in order to distribute the computation for the source videos. The master and subordinate clients were each modified so that they could use a RecorderNddiDisplay instead of a GrpcNddiDisplay.

For each use case, the master client and each of the subordinate clients were run in recorder mode. Similar to our previous experiments, the subordinate clients tiled their source video and recorded commands to render 10 seconds of their source video streams. Once all recordings were complete, then the nDDI Display Server was launched. Then a playback client initialized a RecorderNddiDisplay in playback mode to

Command Count (/s) Bandwidth Ideal Bandwidth Video Conference Display Wall 7.81 million 4.42 Gbps 8.42 Gbps

Digital Billboard 8.21 million 3.75 Gbps 3.06 Gbps

Stadium Jumbotron 9.37 million 3.05 Gbps 14.77 Gbps

Table 10.4 Connected display wall experiment results.

read the nDDI commands and send them to the server. The playback happened sequentially with the master client commands running first and then each subordinate client’s commands for all 240 frame running in turn. The playback of each client’s frame were not coordinated and interleaved.

The nDDI Display Server used the CostModel API to record all of the statistics for the playback.

10.3

Results

The results for the three uses cases are shown in table 10.4. The first column shows the total number of commands sent to the server. This included commands sent by the nDDI Master Client and commands sent by the DCT tilers for each nDDI Subordinate Client for each of their 240 frame sent. The cost model was not cleared after initialization.

The second column holds the total amount of data sent. This count is from the cost model, which computes this figure in the same way as with the PixelBridge experiments. It includes data sent to the frame volume, input vector, and coefficient planes as well as simple addressing information (see appendix B). This does not include any of the data for the protocol used by the GrpcNddiDisplay to encode the particular command. However, GRPC employs additional compression via its use of protobuf which would likely yield fewer bytes transmitted.

In the final column, we include the pixel data changed. This is the same as Ideal Mode from the PixelBridge experiments, where we calculate the data required to transmit just changed pixels at 32 bits per pixel with no addressing information. These calculations represent the pixels on the destination display, and not the source. Therefore, if one of the source streams is scaled by2×in both directions, then the pixel count will be scaled by4×for that stream.

In terms of data transmitted, our DCT Tilers outpaced Ideal Mode for the Video Conference Display Wall and Stadium Jumbotron experiments. The results for the Digital Billboard were not as strong as Ideal Mode. This is largely due to the simplicity of the graphics. In fact several video streams were rather primitive;

specifically the Slideshow for the Video Conference Display Wall, the signs for the Digital Billboard, and the scoreboard and ticker for the Stadium Jumbotron. These did rather well for Ideal Mode as very few pixels changed. Modern digital graphics artists make strong user of background animation, gradients, and sprites, and so it likely that the DCT Tiler would show a strong gain for those video streams if they were of a more professional caliber.

Despite the simplified graphics, DctTiler still performed quite well for largely static areas like the score- board; just not as well as a scheme that would have only updated the bounding rectangles around the clock as it ticked away. In section 10.2.2, we conceived a thought experiment that described how the ticker of the Stadium Jumbotron experiment could have been implemented as very-wide scrolling region. In that experiment we calculated the bandwidth for updating just the pixel data in that scheme was 20.3 Mbps. The actual bandwidth required for the ticker was 849.3 Mbps, which is over 40 times worse than the optimal scheme. However, the impact to the total Stadium Jumbotron experiment bandwidth is much less, upper-bounded at 36%. This is still quite significant, largely because the largest part of the display in the experiment is being scaled, and so the overall bandwidth is quite low for this experiment. Our configuration was largely based on the engineering decision, but any optimization team would likely override this decision when presented with the results of this thought experiment.

Unlike sources with simple graphical elements, DCT Tiled Mode far outpaced Ideal Mode for full motion video sources and especially those that were scaled. Quite remarkably too, the total bandwidth requirement for these uses cases is very low considering the spatial dimensions of the display. Table 10.5 lists the spatial dimension of each use case with the bandwidth requirements. Each of these use cases can easily be supported on a traditional 10 gigabit ethernet network. Furthermore, actual client bandwidth is much lower, indicated that the connected display wall can be driven from clients over simple gigabit ethernet or a high speed Internet connection. As a comparison, the DisplayPort 1.4 standard supports 8K displays over a USB Type C connector at 60 Hz.(ArsTechnica, 2016) This is using four lanes at 8.1 Gbps for a total bandwidth of 32.4 Gbps to drive an 8K @ 60Hz(7680 × 4320 or 33.18 MP). Our n-Dimensional Display Interface is driving a similarly-sized display in the Video Conference Display Wall use case in only 4.42 Gps. Granted, we’re driving the display at 24Hz, but even driving it at3×that would still be 13.26 Gbps which is just 40% of the bandwidth available for 8K video at 60 Hz with DisplayPort 1.4.

In addition to demonstrating how well the video sources can be distributed, the experiments also hint at how well an nDDI Display Wall Server implementation can be distributed over a set of display drivers each connected to a display tile. Ideally, an nDDI display would be built from a single panel with a single ASIC

Size (pixel count) Bandwidth Video Conference Display Wall 31.64 MP 4.42 Gbps

Digital Billboard 23.73 MP 3.75 Gbps

Stadium Jumbotron 44.53 MP 3.04 Gbps

Table 10.5 Connected display wall experiment bandwidth requirements.

implementation of the nDDI engine. However, it can easily be built in a more traditional way like today’s display walls. These experiments demonstrated how individual sources can reserve and drive portions of the display. All of the necessary coefficient plane data is local to the pixels and can therefore be stored over the tiles. The frame volume is shared among all of the clients, but the use cases fall into two categories where either a small amount of frame volume data is shared amongst all clients (DCT Tiler) or a large amount of frame volume data is section off and mostly reserved per area of the display (Flat Tiled). In the former case, that small amount of memory is easily cached and remains unchanged. With the later, the areas of the frame volume per client can also be cached and update frequently without affecting other clients. The exception to all of this is the case when reserved regions per client to align with tile boundaries, but Chromium and other display wall research has already addressed this problem.

CHAPTER 11:

FUTURE WORK

This dissertation embodies a tremendous amount of time and energy delving into the potential for nDDI displays. However, nDDI is a completely new abstraction derived from first principles and so the effort to date is a fraction of the future work.