Skip to content

Latest commit

 

History

History
140 lines (107 loc) · 5.8 KB

Queries.md

File metadata and controls

140 lines (107 loc) · 5.8 KB
Raw

Queries

OpenGL queries generally have a straightforward mapping to Vulkan queries, with the exception of GL_PRIMITIVES_GENERATED. Some Vulkan queries are active only inside a render pass, while others are affected by both inside and outside render pass commands.

Outside Render Pass Queries

The following queries are recorded outside a render pass. If a render pass is active when begin() or end() is called for these queries, it will be broken.

  • GL_TIME_ELAPSED_EXT
  • GL_TIMESTAMP_EXT

Inside Render Pass Queries

The rest of the queries are active only inside render passes. The context (ContextVk) keeps track of currently active "render pass queries" and automatically pauses and resumes them as render passes are broken and started again.

  • On query begin(): ContextVk::beginRenderPassQuery() is called which:
    • If a render pass is open, immediately starts the query and keeps track of it
    • Otherwise keeps the query tracked to be started in the next render pass
  • On query end(): ContextVk::endRenderPassQuery() is called which:
    • If a render pass is open, stops the query
    • Loses track of the query
  • On render pass start: ContextVk::resumeRenderPassQueriesIfActive() is called which starts all active queries.
  • On render pass end: ContextVk::pauseRenderPassQueriesIfActive() is called which stops all active queries.

In Vulkan, a query cannot be paused or resumed, only begun and ended. This means that GL queries that span multiple render passes must use multiple Vulkan queries whose results are accumulated. This is done on render pass start, where QueryVk::onRenderPassStart() would stash the previous Vulkan query (if any) and create a new one before starting it. When a query is begun, the QueryVk's "current" Vulkan query (mQueryHelper) is only allocated if there's a render pass active.

Invariant rule: With the above algorithm, QueryVk::mQueryHelper is at all times either nullptr or has commands recorded. This is important when getting query results to be able to ask mQueryHelper for availability of results.

Later on, QueryVk::getResult() would take the sum of the current and all stashed Vulkan queries as the final result.

Mid-Render-Pass Clears

If a clear is performed while a render pass query is active and if that clear needs to take a draw-based path, UtilsVk ensures that the draw call does not contribute to query results. This is done by pausing (ContextVk::pauseRenderPassQueriesIfActive) the queries before the draw call and resuming (ContextVk::resumeRenderPassQueriesIfActive) afterwards.

The rest of the UtilsVk draw-based functions start a render pass out of the knowledge of ContextVk, so queries will not be activated. In the future, if any UtilsVk functions use the current render pass the way UtilsVk::clearFramebuffer does, they must also ensure that they pause and resume queries.

Transform Feedback Queries

OpenGL has two distinct queries GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN and GL_PRIMITIVES_GENERATED. In Vulkan however, these are served by a single query from VK_EXT_transform_feedback. Additionally, Vulkan requires that only a single query of any type can be active at a time. This forces ANGLE to have the two GL queries share their Vulkan queries when both transform feedback queries are active.

To support the above use case, QueryVks keep ref-counted (vk::Shared) Vulkan query (vk::QueryHelper) objects. When either transform feedback query is begun:

  • If the other transform feedback query (shareQuery) is active and a render pass is active:
    • shareQuery's current Vulkan query is stopped and stashed, and a new one is allocated
    • shareQuery's new Vulkan query is taken as this query's current one with the ref-count incremented
    • The Vulkan query is started as usual
  • If the other transform feedback query is active and a render pass is not:
    • The current Vulkan query is kept nullptr. When the next render pass starts, they will share their Vulkan queries.
  • If the other transform feedback query is not active, proceed as usual

Breaking the shareQuery's Vulkan query on begin ensures that whatever results it may have accrued before do not contribute to this query.

Similarly, when a transform feedback query is ended, the Vulkan query is ended as usual and then:

  • If the other transform feedback query is active and a render pass is active:
    • shareQuery's Vulkan query (which is the same as this query's, as they share it) is stashed
    • shareQuery allocates a new Vulkan query and starts it

When a render pass is broken and active queries are paused (ContextVk::pauseRenderPassQueriesIfActive), only one of the queries will close the shared Vulkan query.

When a render pass is started and active queries are resumed (ContextVk::resumeRenderPassQueriesIfActive), only one of the queries will allocate and start a new Vulkan query. The other one will just take that and share it (and increment the ref-count).

The above solution supports the following scenarios:

  • Simultaneous begin of the two queries:
glBeginQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN)
glBeginQuery(GL_PRIMITIVES_GENERATED)
glDraw*()
  • Simultaneous end of the two queries:
glDraw*()
glEndQuery(GL_PRIMITIVES_GENERATED)
glEndQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN)
  • Draw calls between begin calls:
glBeginQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN)
glDraw*()
glBeginQuery(GL_PRIMITIVES_GENERATED)
glDraw*()
  • Draw calls between end calls:
glDraw*()
glEndQuery(GL_PRIMITIVES_GENERATED)
glDraw*()
glEndQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN)
  • Queries getting deleted / rebound when the other is active, for example:
glDraw*()
glEndQuery(GL_PRIMITIVES_GENERATED)
glDeleteQueries(primitivesGenerated)
glDraw*()
glEndQuery(GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN)