vo_gpu_next: use pl_dispatch_info_move to avoid useless data copy

[kasper93]

Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is requested.

This require minimal libplacebo API version bump. Since new libplacebo release is close and the requirement in mpv is planned to be bumped too let's wait for it instead ifdefing everything. In the meantime we can review, so it is ready when it gets unblocked.

[haasn]

Question: Why does this struct need to be locked again, at all? Doesn't the VOCTRL run synchronously on VO thread, so how can it possibly race with the updates coming from the callbacks from pl_render_* (also on VO thread)?

Food for thought: If the above is true and the VOCTRL can run concurrently, we should hold the lock during the entire pl_render_() call, not just the callbacks! Otherwise VOCTRL may see inconsistent state...

[kasper93]

Question: Why does this struct need to be locked again, at all? Doesn't the VOCTRL run synchronously on VO thread, so how can it possibly race with the updates coming from the callbacks from pl_render_* (also on VO thread)?

I just double checked VOCTRL is correctly run on VO thread, so it is fine. Previously the issue was that it were passing a pointer, that were accessed form VO and LUA thread, but now since we are doing full copy, the data is decoupled so in fact this lock were never needed.