Proposal – Centralized GPU Process Handling

The goal of this final project is to learn about GPU abstraction techniques and to investigate the performance implications of decoupling graphics calls (OpenGL calls in this case) from the processes that issue them to another process responsible for all communication with the GPU. Performance implications investigated will include CPU utilization, GPU utilization, and process framerate.

This final project will encompass intercepting OpenGL calls from multiple operating system level processes (henceforth called client processes), enqueuing such intercepted OpenGL calls in per-processes queues, and then servicing these enqueued OpenGL calls by a central, master GPU-interfacing process (henceforth called the master process). In this manner, the master process is responsible for all communication with the GPU on behalf of all participating client processes. OpenGL calls made by client processes are intercepted and in turn issued to the GPU by the master process. When GPU results become available, the master process is responsible for then returning those results back to the client process that made the original, intercepted request.

To intercept all graphics calls made by the client processes, a new OpenGL shared library that intercepts OpenGL calls will be created to replace the standard OpenGL shared library. This new OpenGL shared library will collect all of the OpenGL calls made by the client processes and enqueue them in per-process queues. Such an OpenGL interceptor is feasible, as a similar open-source project, GLIntercept, has been previously built. GLIntercept may serve as a reference when building the new OpenGL interceptor shared library.

With the OpenGL interceptor shared library in place, OpenGL calls will be enqueued and can be serviced by the master process. This master process will multiplex client graphics calls on the GPU and return the results to the appropriate client processes. The scheduling algorithm to determine the order in which enqueued graphics calls are handled is a side issue for the goals of this project, but could serve as an interesting area of side investigation.

When the OpenGL interceptor shared library and master process are in place, graphically intensive applications can be benchmarked – comparing CPU utilization, GPU utilization, and framerate for processes running normally (without intercepted OpenGL calls) and running as a participant client process with intercepted OpenGL calls handled by the master process. Hopefully such benchmark data will yield valuable insights into the architectural and performance implications of abstracting graphics calls from client applications.


This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Proposal – Centralized GPU Process Handling

  1. paul says:

    It looks like any interesting project I just wonder what it could be used for? Is it for something like google chrome where all the tabs are a process and need to talk to the GPU? It seems like if it was for more general use you are going to run into issues with security/permissions. Anyway looks like a hard problem, good luck.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s