This does two things:
1. Flush the command buffer and associate a fence with each
glLinkProgram().
2. Force the application calling glLinkProgram() to wait on the
associated fence, matching the semantics of native drivers.
This important for some workloads and some environments. For example, on
ChromeOS devices supporting VM-based android (ARCVM), an app's HWUI thread
may be configured to use skiagl, while the app may create its own GLES
context for custom rendering. Virgl+virtio_gpu supports a single fencing
timeline, so all guest GL/GLES contexts are serialized by submission
order to the guest kernel.
If the app's submits multiple heavy shaders for compliation+linking
(glCompileShader + glLinkProgram()), these are batched into a single
virtgpu execbuffer (with one fence). Then rendering performed by the
HWUI thread is blocked until the unrelated heavy host-side work is
finished. To the user, the app appears completely frozen until finished.
With this change, the app is throttled in its calls to glLinkProgram(),
and the HWUI work can fill in the gaps between each while hitting most
display update deadlines. To the user, the UI may render at reduced
framerate, but remains mostly responsive to interaction.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22341>
Ryan Neph
48062f91c7