You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: it's no longer clear how beneficial it is to expose GL_INTEL_performance_query metrics. In practice it seems we can get richer data directly from the kernel, and even support a filtered, single-context view of metrics without any api specific extensions
Note: this work would be based on the wip/rib/intel-perf-query branch which adds support for more GL performance queries, which should be pushed to master soon. For reference, some of the functions mentioned below only exist on this branch.
Currently the web UI only supports viewing system-wide metrics.
There's some protocol defined in gputop.proto for being able to describe the queries and counters supported by OpenGL for the browser, but where we describe features in gputop-server.c:handle_get_features() we don't currently initialize the description of GL queries + counters to be serialized.
gputop-web-worker.c:update_features() then needs to be able parse the description of GL queries/counters, and forward a description to the UI frontend.
From the UI frontend, when it knows that GL queries are available then it should be able to list the queries for the user and then if one of these is requested by the user it needs to be able to issue an "open_gl_query" rpc request to actually start collecting metrics from GL, similar to "open_oa_query".
Supporting an "open_gl_query" rpc method from the UI frontend implies implementing a gputop_webworker_on_open_gl_query() function within gputop-web-worker.c (it's going to be very similar to gputop_webworker_on_open_oa_query()).
For the web worker, gputop_webworker_on_open_gl_query() implementation to be able to ask the remote device to start collecting and forwarding GL metrics it should use send_pb_message() to send a 'Request' , OpenQuery protocol buffers message giving a gl_query ID as specified by the UI frontend.
Within gputop-server.c:handle_open_query() the switch() needs to be updated to match GPUTOP__OPEN_QUERY__TYPE_GL_QUERY and then call through to a new handle_open_gl_query() function that can then - similar to gputop-ui.c:gl_perf_query_tab_enter() - request gputop-gl.c to start capturing the requested metrics.
Once gputop-server.c is able to handle requests to open GL performance queries, then similar in some ways to code in gl_perf_query_tab_redraw() then gputop-server.c needs to be periodically checking for finished query data and forwarding the metrics on to the remote web worker. This would probably be done using periodic_forward_cb + hooking into flush_streams(), flush_stream_samples(), in much the same way as we forward raw perf data.
Similar to how the web worker can parse raw perf data, the web worker then needs to be able to parse the raw GL metrics. (See gputop-web-worker.c:gputop_webworker_on_message + probably adding a handle_gl_query_message() function) We already have code in gputop-ui.c for parsing the GL metrics so some of this code can hopefully be repurposed here.
The last steps are to forward the data in its final form for presentation to the frontend UI. At this point it could be good if we forward data in exactly the same way as for system-wide metrics, re-purposing the "oa_query_update" message that forward_query_update() currently assembles. (renamed)
The text was updated successfully, but these errors were encountered:
Note: it's no longer clear how beneficial it is to expose GL_INTEL_performance_query metrics. In practice it seems we can get richer data directly from the kernel, and even support a filtered, single-context view of metrics without any api specific extensions
Note: this work would be based on the wip/rib/intel-perf-query branch which adds support for more GL performance queries, which should be pushed to master soon. For reference, some of the functions mentioned below only exist on this branch.Currently the web UI only supports viewing system-wide metrics.
There's some protocol defined in gputop.proto for being able to describe the queries and counters supported by OpenGL for the browser, but where we describe features in gputop-server.c:handle_get_features() we don't currently initialize the description of GL queries + counters to be serialized.
gputop-web-worker.c:update_features() then needs to be able parse the description of GL queries/counters, and forward a description to the UI frontend.
From the UI frontend, when it knows that GL queries are available then it should be able to list the queries for the user and then if one of these is requested by the user it needs to be able to issue an "open_gl_query" rpc request to actually start collecting metrics from GL, similar to "open_oa_query".
Supporting an "open_gl_query" rpc method from the UI frontend implies implementing a gputop_webworker_on_open_gl_query() function within gputop-web-worker.c (it's going to be very similar to gputop_webworker_on_open_oa_query()).
For the web worker, gputop_webworker_on_open_gl_query() implementation to be able to ask the remote device to start collecting and forwarding GL metrics it should use send_pb_message() to send a 'Request' , OpenQuery protocol buffers message giving a gl_query ID as specified by the UI frontend.
Within gputop-server.c:handle_open_query() the switch() needs to be updated to match GPUTOP__OPEN_QUERY__TYPE_GL_QUERY and then call through to a new handle_open_gl_query() function that can then - similar to gputop-ui.c:gl_perf_query_tab_enter() - request gputop-gl.c to start capturing the requested metrics.
Once gputop-server.c is able to handle requests to open GL performance queries, then similar in some ways to code in gl_perf_query_tab_redraw() then gputop-server.c needs to be periodically checking for finished query data and forwarding the metrics on to the remote web worker. This would probably be done using periodic_forward_cb + hooking into flush_streams(), flush_stream_samples(), in much the same way as we forward raw perf data.
Similar to how the web worker can parse raw perf data, the web worker then needs to be able to parse the raw GL metrics. (See gputop-web-worker.c:gputop_webworker_on_message + probably adding a handle_gl_query_message() function) We already have code in gputop-ui.c for parsing the GL metrics so some of this code can hopefully be repurposed here.
The last steps are to forward the data in its final form for presentation to the frontend UI. At this point it could be good if we forward data in exactly the same way as for system-wide metrics, re-purposing the "oa_query_update" message that forward_query_update() currently assembles. (renamed)
The text was updated successfully, but these errors were encountered: