Both expect a return string in a specified format which contains the supported OpenGL ver-sion when usingGL_VERSIONand the maximal supported shading language version when using GL_SHADING_LANGUAGE_ VERSION. To support as many platforms as possible, this should evaluate to the lowest returned version number. The last case isGL_EXTENSIONS
which contains a set of supported extensions for each renderer. It can vary between dif-ferent OpenGL implementations so that two implementations might support overlapping subsets of extensions. To keep every connected renderer supported, PipeGL should only return the subset of extensions which is supported by every connected renderer.
getUniformLocationis used to obtain the location of a specific uniform variable inside a pro-gram object. Uniforms are values inside the Shaders that stay the same for all vertices in a draw call. The concrete location of each uniform is computed at link time. Currently it can not be said if the return value is consistent between different implementations or instances of renderers. It is definitely the same on every instance of the available imple-mentation. If it is the same on different OpenGL implementations, agetUniformLocationcall can be handled the same way as aglGetAttribLocationcall. If the returned uniform locations differ from each other on other OpenGL implementationsglGetUniformLocation, calls can be handled the same way as the calls which are generating an ID.
4.5.2 Implementation
The implementation can be split up in two separate tasks. The first task is handling the IDs of OpenGL objects, the second part is evaluating getting calls. ID handling is imple-mented in the ServerIDHandler on the application server side and theClientIDHandleron the renderer side. Evaluation of return values is implemented in the returnEvaluationAdapter. A visualization of the new adapters put in the context of the Wangle pipeline can be seen in Figure 4.10.
Figure 4.10: New adapters added to the PipeGL pipeline
ID handling
The ServerIDHandler uses an array to check if the current Instruction is a generating call. If the Instruction generates a new ID, the adapter pushes an unique ID to the back of the included parameters.
The unique ID is fetched by theClientIDHandleron thePipeGL rendererand removed from the instruction’s parameters. The ClientIDHandler memorizes the given ID and waits until the return value is pushed back in the pipeline. The returned ID is matched with the ID given by the ServerIDHandler. They are saved together in a map and the given ID is returned.
Whenever an instruction uses an ID, it refers to the given ID. The ClientIDHandler is then replacing the parameter containing the given ID with the real ID.
ID handling scales well with more connected renderers as it does not require additional resources on the server side, when more than one renderer is connected.
Return value evaluation
Return value evaluation has a low priority in the current project. Even if it is implemented and works, the results are not descriptive for heterogeneous hardware platforms, because the PipeGL renderer currently runs on different instances of a single hardware platform.
Due to the limited time for the current thesis the described design is neither implemented nor tested, but it provides a solution that should fix the issue of return value evaluation on heterogeneous hardware platforms. The current solution for evaluating the OpenGL streaming protocol is to use the first value which is returned.
4.6 Evaluation
PipeGL with the OSP extension is tested as described in section 3.5. Testing is split up into the two categories bandwidth and latency. The current implementation of the OSP protocol is not as stable as the implementation of the TCP protocol. Frame rates of 0 FPS express that no frame rate could be captured for the given test conditions. This happens when PipeGL could not execute a full transmission after several approaches.
4.6.1 Test results
Bandwidth
At first the performance of the OSP protocol itself is evaluated. Then the new results are compared with the prior recorded results of PipeGL.
4.6. EVALUATION 57
When evaluating Figure 4.12 one can see framing and compression has a negative effect when using the OSP protocol. This might not directly be connected to the required band-width, but connected to the fact that the OSP protocol does not provide a sufficient way to adapt with changing network capabilities.
0 10 20 30 40
Figure 4.12: Bandwidth test Teapot with optimization
In comparison with data transmission via TCP, the new protocol requires slightly more bandwidth. Nevertheless, it still performs with 60 FPS up to the point of 8 Mbit/s. This is an acceptable loss, as a better scalability is expected.
The more capacity requiring Octahedrons application shows the shortcoming of the current implementation. Tests with one and two targets keep the frame rate below 30 FPS. What is more, the results are unstable. Every test is resulting in a different average frame rate and the frame rate itself is not consistent over the application’s run time.
0 10 20 30 40
Executing the Octahedrons application with PipeGL using compression and framing leads to a highly unstable behaviour. An usual performance test as seen in Figure 3.10 is not possible under this conditions. Using PipeGL with the OSP protocol, compression and framing requires further improvement of the existing implementation.
Figure 4.14 shows that IP multicast scales better with the amount of connected renderers than singlecast connections do. The OSP version of PipeGL can hold 60 FPS for the full measurement period without compression or framing. The TCP achieves this as well by using compression and framing, but these optimizations are more affected by a high latency. However, here it can be seen another time that using OSP together with the existing optimizations leads to worse results than using OSP without compression and framing.
Even if the OSP version of PipeGL keeps far below the expected 60 FPS, it might achieve better scalability. Figure 4.15 compares the OSP version with the TCP version when using the high utilizing Octahedrons application and three renderers. The OSP version reaches better frame rates than the TCP version with the same amount of connected renderers when limiting the bandwidth below 30 Mbit/s. At a bandwidth below 10 Mbit/s it is even comparable to the TCP variant with 1 connected renderer.
4.6. EVALUATION 59
0 10 20 30 40
0 20 40 60
bandwidth in Mbit/s
FramesperSecond
TCPOSP OSP and framing TCP and framing
Figure 4.14: Comparison between OSP and TCP using the Teapot application and three renderers
0 10 20 30 40
0 20 40 60
bandwidth in Mbit/s
FramesperSecond
TCP 1 Target OSP 3 Targets TCP 3 Targets
Figure 4.15: Comparison between OSP and TCP using the Octahedrons application and two renderers
Latency
The behaviour of PipeGL without any optimization at constrained latency is shown in Fig-ure 4.16. The reference value is the performance of PipeGL using TCP with one connected renderer and without framing or compression enabled. In this test the OpenGL streaming Protocol performs as good as TCP.
0 10 20 30 40 50 0
20 40 60
latency in ms
FramesperSecond