QRhi Class

メンバ関数ドキュメント

[noexcept] QRhi::~QRhi()

デストラクタ。バックエンドを破棄し、リソースを解放します。

void QRhi::addCleanupCallback(const QRhi::CleanupCallback &callback)

QRhi が破棄されたとき、またはrunCleanup() が呼び出されたときに呼び出されるcallback を登録します。

このコールバックは、グラフィックス・リソースがまだ利用可能な状態で実行されるため、アプリケーションがQRhi に属するQRhiResource インスタンスをきれいに解放する機会を提供します。これは、キャッシュが QRhiResources または QRhiResources を含むオブジェクトを保持するcache タイプのオブジェクトに格納されたリソースの寿命を管理する場合に特に便利です。

runCleanup() および~QRhi()も参照してください 。

void QRhi::addCleanupCallback(const void *key, const QRhi::CleanupCallback &callback)

これはオーバーロードされた関数です。

QRhi が破棄されたとき、またはrunCleanup() が呼び出されたときに呼び出されるようにcallback を登録します。このオーバーロードは、与えられたコールバックが一度だけ登録される（そして呼び出される）ことを保証するために使用される不透明なポインタ、key を取ります。

removeCleanupCallback()も参照 。

QRhi::Implementation QRhi::backend() const

このQRhi のバックエンド型を返します。

const char *QRhi::backendName() const

QRhi のバックエンド型を文字列で返します。

[static] const char *QRhi::backendName(QRhi::Implementation impl)

バックエンドのフレンドリーな名前impl を返します。

QRhi::FrameOpResult QRhi::beginFrame(QRhiSwapChain *swapChain, QRhi::BeginFrameFlags flags = {})

swapChain の次に利用可能なバッファをターゲットとして新しいフレームを開始します。

フレームはリソースの更新と、1つ以上のレンダーパスとコンピュートパスで構成されます。

flags は、特定の特殊なケースを示すことができます。

スワップチェーンを使用してQWindow にレンダリングする高レベルパターン：

• スワップチェーンを作成する。
• サーフェスサイズが以前と異なるときはいつでもQRhiSwapChain::createOrResize （）を呼び出す。
• QPlatformSurfaceEvent::SurfaceAboutToBeDestroyed でQRhiSwapChain::destroy() を呼び出す。
• 次にフレームごとに

  beginFrame(sc);
  updates = nextResourceUpdateBatch();
  updates->...
  QRhiCommandBuffer *cb = sc->currentFrameCommandBuffer();
  cb->beginPass(sc->currentFrameRenderTarget(), colorClear, dsClear, updates);
  ...
  cb->endPass();
  ... // more passes as necessary
  endFrame(sc);

成功した場合はQRhi::FrameOpSuccess を返し、失敗した場合はQRhi::FrameOpResult を返す。これらのエラーのいくつかは、「後で再試行する」タイプのソフトなエラーとして扱われるべきである：QRhi::FrameOpSwapChainOutOfDate が返された場合、スワップチェーンはQRhiSwapChain::createOrResize() を呼び出すことで、サイズ変更または更新される。QRhi::FrameOpDeviceLost はグラフィック・デバイスが失われたことを意味しますが、QRhi 自体を含むすべてのリソースを解放し、すべてのリソースを再作成することで回復できる場合もあります。さらなる議論はisDeviceLost() を参照。

endFrame()、beginOffscreenFrame()、isDeviceLost()も参照 。

QRhi::FrameOpResult QRhi::beginOffscreenFrame(QRhiCommandBuffer **cb, QRhi::BeginFrameFlags flags = {})

新しいオフスクリーンフレームを開始します。cb にレンダリングコマンドを記録するのに適したコマンドバッファを提供します。flags は、beginFrame() と同様に、特定の特殊なケースを示すために使用されます。

スワップチェーンなしのレンダリングも可能である。典型的な使用例は、完全にオフスクリーンのアプリケーションで使用することである。たとえば、ウィンドウを表示することなく、レンダリングと読み出しによって画像シーケンスを生成する場合などである。

オンスクリーンアプリケーション（beginFrame 、endFrame 、beginOffscreenFrame、endOffscreenFrame 、beginFrame 、...）での使用も可能ですが、並列性が低下するため、使用頻度は低くすべきです。

オフスクリーン・フレームは、GPU がまだ前のフレームを処理している間、 CPU に別のフレームを生成させない可能性があります。これには、リードバックがスケジューリングされている場合、endOffscreenFrame() が戻ってくれば結果が利用可能になることが保証されるという副作用があります。スワップチェーンをターゲットとするフレームの場合はそうではあり ません。そこでは GPU がよりよく利用される可能性がありますが、endFrame() はendOffscreenFrame() と異なり、リードバックからの結果がその時点で利用可能であることを保証 しないため、リードバック操作での作業にはアプリケーションからのより多くの 注意が必要です。

スワップチェーンなしでフレームをレンダリングし、フレームの内容をリードバックするスケルトンは、次のようになります：

QRhiReadbackResult rbResult;
QRhiCommandBuffer *cb;
rhi->beginOffscreenFrame(&cb);
cb->beginPass(rt, colorClear, dsClear);
// ...
u = nextResourceUpdateBatch();
u->readBackTexture(rb, &rbResult);
cb->endPass(u);
rhi->endOffscreenFrame();
// image data available in rbResult

endOffscreenFrame() およびbeginFrame()も参照して ください。

QMatrix4x4 QRhi::clipSpaceCorrMatrix() const

アプリケーションが、アクティブなQRhi バックエンドに関係なく、OpenGL ターゲットの頂点データと透視投影行列（QMatrix4x4::perspective() によって生成されたものなど）を使用し続けられるようにするために使用できる行列を返します。

一般的なレンダラーでは、mvp の代わりにthis_matrix * mvp が使用されると、実行時にどのバックエンド（つまりグラフィックス API）が使用されるかを考慮することなく、Y を上とする頂点データと深度範囲 0 ～ 1 のビューポートを使用できます。こうすることで、isYUpInNDC() やisClipDepthZeroToOne() に基づく分岐を避けることができます（ただし、特定の高度なグラフィックス技術を実装する場合は、このようなロジックが必要になることがあります）。

Vulkanの観点からのトピックについては、このページを参照してください。

[static] QRhi *QRhi::create(QRhi::Implementation impl, QRhiInitParams *params, QRhi::Flags flags = {}, QRhiNativeHandles *importDevice = nullptr)

impl で指定されたグラフィックス API のバックエンドを持つ新しいQRhi インスタンスを、指定されたflags で返します。関数が失敗した場合はnullptr を返します。

params は、 、 、 、 、 のような、 のバックエンド固有のサブクラスのいずれかのインスタンスを指す必要があります。 を作成する例については、これらのクラスを参照してください。QRhiVulkanInitParams QRhiMetalInitParams QRhiD3D11InitParams QRhiD3D12InitParams QRhiGles2InitParams QRhiInitParams QRhi

QRhi 指定されたAPIを初期化できない場合、create()は失敗し、バックエンドのデバッグ出力に警告が表示されます。しかし、 のクライアント、例えばQt Quickは、プラットフォームに応じて、要求されたAPIとは異なるAPIにフォールバックするための追加ロジックを提供することができる。後でcreate()を呼び出したときに初期化が成功するかどうかをテストするだけであれば、create()の代わりに ()を使用することが望ましい。バックエンドによっては、インフラストラクチャの完全な初期化を実行するcreate()とは対照的に、より軽量な方法でプロービングを実装することができるため、 、そのインスタンスがすぐに捨てられてしまうと無駄になってしまうからである。QRhi probe QRhi

importDevice によって、 自身を作成することなく、すでに存在するグラフィック・デバイスを使用することができる。NULLでない場合、このパラメータは のサブクラスの1つのインスタンスを指す必要があります： , , , 。正確な詳細とセマンティクスは、バックランドとその下にあるグラフィックスAPIに依存します。QRhi QRhiNativeHandles QRhiVulkanNativeHandles QRhiD3D11NativeHandles QRhiD3D12NativeHandles QRhiMetalNativeHandles QRhiGles2NativeHandles

probe()も参照してください 。

int QRhi::currentFrameSlot() const

フレームの記録中に現在のフレームスロットインデックスを返します。アクティブなフレーム外で呼び出された場合（つまり、isRecordingFrame() がfalse の場合）は不定。

Vulkan や Metal のようなバックエンドでは、新しいフレームを開始し、CPU が GPU よりもすでにFramesInFlight - 1 フレーム進んでいる（フレーム番号current ～FramesInFlight で投入されたコマンドバッファがまだ完了していないため）ことがわかるたびにブロックするのは、QRhi バックエンドの責任です。

フレーム間で変更される傾向のあるリソース（たとえば、QRhiBuffer::Dynamic 型のQRhiBuffer をバッ クするネイティブバッファオブジェクトなど）は、複数のバージョンで存在します。そのため、前のフレームがまだ処理されている間に提出できる各フレームは、それ自身のコピーで動作します。(GPUでまだ使用中である可能性のあるリソースのコンテンツに触れるべきではありませんが、前のフレームが終了するのを常に待つだけでは、GPUの使用率が低下し、最終的にパフォーマンスと効率が低下します)。

概念的には、これはいくつかのC++コンテナや他の型が使用するコピーオンライト方式にいくらか似ています。また、OpenGLやDirect 3D 11の実装が、ある種のオブジェクトに対して内部的に実行するものと似ているかもしれません。

実際には、このようなダブル（またはトリプル）バッファリングリソースは、Vulkan、Metal、および類似のQRhi バックエンドで、固定数のネイティブリソース（VkBuffer など）slots をQRhiResource の背後に持つことによって実現されます。これは、0、1、...、FramesInFlight-1 を実行するフレームスロットインデックスによってインデックス付けされ、ラップアラウンドすることができます。

これらはすべて、QRhi のユーザーに対して透過的に管理されます。 しかし、グラフィックスAPIで直接レンダリングを行うアプリケーションは、独自のグラフィックスリソースに対して同様の2重または3重のバッファリングを行いたいと思うかもしれません。その場合、インフライトフレームの最大数（resourceLimit() で取得可能）と現在のフレーム（スロット）インデックス（この関数で返される）の値を知っていれば、最も簡単に実現できます。

isRecordingFrame()、beginFrame()、endFrame()も参照 。

QRhiDriverInfo QRhi::driverInfo() const

正常に初期化されたQRhi インスタンスで使用されているグラフィックデバイスのメタデータを返します。

QRhi::FrameOpResult QRhi::endFrame(QRhiSwapChain *swapChain, QRhi::EndFrameFlags flags = {})

swapChain の最後のbeginFrame() で開始されたフレームを終了、コミット、提示します。

ダブル（またはトリプル）バッファリングは、QRhiSwapChain とQRhi によって内部的に管理されます。

flags をオプションで使用すると、特定の方法で動作を変更できます。 を渡すと、PresentコマンドのキューイングやswapBuffersの呼び出しが省略される。QRhi::SkipPresent

成功するとQRhi::FrameOpSuccess を返し、失敗するとQRhi::FrameOpResult を返す。これらのエラーのいくつかは、「後で再試行する」タイプのソフトなエラーとして扱われるべきである：QRhi::FrameOpSwapChainOutOfDate が返された場合、スワップチェーンはQRhiSwapChain::createOrResize() を呼び出すことで、サイズ変更または更新される。QRhi::FrameOpDeviceLost はグラフィック・デバイスが失われたことを意味しますが、QRhi 自体を含むすべてのリソースを解放し、すべてのリソースを再作成することで回復できる場合もあります。さらなる議論については、isDeviceLost （）を参照。

beginFrame() およびisDeviceLost()も参照の こと。

QRhi::FrameOpResult QRhi::endOffscreenFrame(QRhi::EndFrameFlags flags = {})

終了、サブミット、オフスクリーンフレームの待機。

flags は現在使用されていません。

beginOffscreenFrame()も参照 。

QRhi::FrameOpResult QRhi::finish()

グラフィックス・キュー（該当する場合）の作業が完了するのを待ち、リードバックの完了やリソースの解放など、すべての遅延操作を実行します。フレームの内側でも外側でも呼び出せますが、パスの内側では呼び出せません。フレーム内では、コマンドバッファ上のすべての作業をサブミットすることを意味します。

bool QRhi::isClipDepthZeroToOne() const

基礎となるグラフィックス API がクリップ空間で深度範囲 [0, 1] を使用している場合、true を返します。

OpenGLはポストプロジェクションの深度範囲として[-1, 1]を使用するため、実際にはOpenGLのみfalse 。(glDepthRange()によって制御されるNDCからウィンドウへのマッピングと混同しないように、glDepthRange()は、QRhiViewport によってオーバーライドされない限り、[0, 1]の範囲を使用します) いくつかのOpenGLバージョンでは、これを変更するためにglClipControl()を使用することができますが、QRhi のOpenGLバックエンドは、OpenGL ESまたは4.5未満のOpenGLバージョンで利用できないため、この関数を使用しません。

bool QRhi::isDeviceLost() const

グラフィックスデバイスが失われた場合、true を返します。

デバイスの紛失は、バックエンドや基盤となるネイティブAPIによって異なりますが、通常、beginFrame （）、endFrame （）、QRhiSwapChain::createOrResize （）で検出されます。最も一般的なのはendFrame() である。バックエンドによっては、QRhiSwapChain::createOrResize() がデバイスの損失によって失敗することもある。したがって、この関数は、デバイスの喪失が以前の操作によって検出されたかどうかをチェックする汎用的な方法として提供される。

QRhi デバイスが失われた場合、QRhi を介してそれ以上の操作を行うべきではない。むしろ、QRhi リソースをすべて解放し、QRhi を破棄する必要がある。成功すれば、すべてのグラフィックス・リソースを再初期化しなければならない。成功しない場合は、後で繰り返し再試行してください。

単純なアプリケーションはデバイスの損失を気にしないことにするかもしれませんが、一般的に使用されるデスクトッ ププラットフォームでは、物理的にグラフィックスアダプタを外す、デバイスやドライバを無効にする、グ ラフィックスドライバをアンインストールまたはアップグレードする、あるいはグラフィックスデ バイスをリセットするようなエラーが発生するなど、さまざまな理由でデバイスの損失が発生する可能性 があります。例えば、グラフィックスドライバの新しいバージョンへのアップグレードは、Qt アプリケーションの実行中にいつでも起こりうる一般的なタスクです。たとえアプリケーションが OpenGL や Direct3D のような API を積極的に使用している場合でもです。

Qt Quick のような、QRhi 上に構築された Qt 独自のフレームワークは、デバイスの損失が発生したときに適切な処理を行い、適切な手段を講じることが期待できます。テクスチャやバッファのようなグラフィックリソースのデータがCPU側でまだ利用可能であれば、その時点でグラフィックリソースをシームレスに再初期化できるため、そのようなイベントはアプリケーションレベルではまったく気にならないかもしれません。しかし、QRhi で直接動作するアプリケーションやライブラリは、デバイスが失われた状況を自ら確認し、処理するように準備することが期待されます。

bool QRhi::isFeatureSupported(QRhi::Feature feature) const

指定されたfeature がサポートされている場合、true を返す。

bool QRhi::isRecordingFrame() const

beginFrame() (またはbeginOffscreenFrame()) が存在し、対応するendFrame() (またはendOffscreenFrame()) がまだ存在しないことを意味します。

currentFrameSlot()、beginFrame()、endFrame()も参照して ください。

bool QRhi::isTextureFormatSupported(QRhiTexture::Format format, QRhiTexture::Flags flags = {}) const

flags によって変更された指定されたテクスチャformat がサポートされている場合、true を返します。

このクエリは、非圧縮形式と圧縮形式の両方でサポートされています。

bool QRhi::isYUpInFramebuffer() const

基礎となるグラフィックス API が、フレームバッファやイメージの Y 軸を上向きにしている場合、true を返します。

実際にはOpenGLのみtrue 。

bool QRhi::isYUpInNDC() const

基礎となるグラフィックスAPIが、その正規化されたデバイス座標系でY軸を上に向けている場合、true を返します。

実際には、これはVulkanのみfalse 。

bool QRhi::makeThreadLocalNativeContextCurrent()

OpenGLでは、これは現在のスレッドでOpenGLコンテキストをカレントにします。この関数は他のバックエンドには影響しません。

QRhi が OpenGL バックエンドを使用している限り、アプリケーションによって提供される外部の OpenGL コードが、OpenGL を直接使用しても以前と同じように実行できるようにする必要がある場合に、この関数を呼び出すことは、一般的に Qt フレームワークのコードに関係します。

QOpenGLContext::makeCurrent （）と同様に、失敗した場合はfalseを返す。操作に失敗した場合、isDeviceLost() を呼び出して、コンテキストの喪失があったかどうかを判断することができる。このようなチェックは、QOpenGLContext::isValid() によるチェックと同等である。

QOpenGLContext::makeCurrent() およびQOpenGLContext::isValid()も参照 。

[static] int QRhi::mipLevelsForSize(const QSize &size)

与えられたsize の mip レベル数を返す。

const QRhiNativeHandles *QRhi::nativeHandles()

バックエンドが使用するデバイス、コンテキスト、および同様の概念に関するネイティブオブジェクトのバックエンド固有のコレクションへのポインタを返します。

必要に応じてQRhiVulkanNativeHandles,QRhiD3D11NativeHandles,QRhiD3D12NativeHandles,QRhiGles2NativeHandles,QRhiMetalNativeHandles にキャストします。

QRhiBuffer *QRhi::newBuffer(QRhiBuffer::Type type, QRhiBuffer::UsageFlags usage, quint32 size)

指定されたtype 、usage 、size を持つ新しいバッファを返します。

QRhiResource::destroy()も参照 。

QRhiComputePipeline *QRhi::newComputePipeline()

新しいコンピュート・パイプライン・リソースを返します。

QRhiResource::destroy() も参照して ください。

QRhiGraphicsPipeline *QRhi::newGraphicsPipeline()

新しいグラフィックスパイプラインリソースを返します。

QRhiResource::destroy() も参照して ください。

QRhiRenderBuffer *QRhi::newRenderBuffer(QRhiRenderBuffer::Type type, const QSize &pixelSize, int sampleCount = 1, QRhiRenderBuffer::Flags flags = {}, QRhiTexture::Format backingFormatHint = QRhiTexture::UnknownFormat)

指定されたtype 、pixelSize 、sampleCount 、flags を持つ新しいレンダーバッファを返します。

backingFormatHint がQRhiTexture::UnknownFormat 以外のテクスチャフォーマットに設定されている場合、バックエンドがレンダーバッファのストレージに使用するフォーマットを決定するために使用されることがあります。

QRhiResource::destroy()も参照 。

QRhiSampler *QRhi::newSampler(QRhiSampler::Filter magFilter, QRhiSampler::Filter minFilter, QRhiSampler::Filter mipmapMode, QRhiSampler::AddressMode addressU, QRhiSampler::AddressMode addressV, QRhiSampler::AddressMode addressW = QRhiSampler::Repeat)

指定された拡大フィルタmagFilter 、縮小フィルタminFilter 、ミップマッピングモードmipmapMode 、アドレッシング（ラップ）モードaddressU 、addressV 、addressW を持つ新しいサンプラーを返します。

QRhiResource::destroy()も参照してください 。

QRhiShaderResourceBindings *QRhi::newShaderResourceBindings()

新しいシェーダーリソースバインディングコレクションリソースを返します。

QRhiResource::destroy() も参照して ください。

QRhiSwapChain *QRhi::newSwapChain()

新しいスワップチェーンを返します。

QRhiResource::destroy() およびQRhiSwapChain::createOrResize() も参照 。

QRhiTexture *QRhi::newTexture(QRhiTexture::Format format, const QSize &pixelSize, int sampleCount = 1, QRhiTexture::Flags flags = {})

指定されたformat,pixelSize,sampleCount,flags を持つ新しい 1D または 2D テクスチャを返します。

1D テクスチャ配列は、flags にQRhiTexture::OneDimensional が設定されている必要があります。pixelSize の高さが 0 の場合、この関数は暗黙的にこのフラグを設定します。

QRhiResource::destroy()も参照 。

QRhiTexture *QRhi::newTexture(QRhiTexture::Format format, int width, int height, int depth, int sampleCount = 1, QRhiTexture::Flags flags = {})

指定されたformat 、width 、height 、depth 、sampleCount 、flags を持つ新しい 1D、2D、または 3D テクスチャを返します。

このオーバーロードは、depth を指定できるので、3D テクスチャに適しています。3D テクスチャはflags でQRhiTexture::ThreeDimensional を設定する必要がありますが、このオーバーロードを使用すると、depth が 0 より大きいときはいつでも暗黙的にフラグが設定されるため、これを省略できます。1D、2D、および立方体テクスチャの場合、depth は 0 に設定する必要があります。

1D テクスチャはflags でQRhiTexture::OneDimensional を設定する必要があります。このオーバーロードは、height とdepth の両方が 0 の場合、暗黙的にこのフラグを設定します。

これはオーバーロードされた関数です。

QRhiTexture *QRhi::newTextureArray(QRhiTexture::Format format, int arraySize, const QSize &pixelSize, int sampleCount = 1, QRhiTexture::Flags flags = {})

指定されたformat 、arraySize 、pixelSize 、sampleCount 、flags を持つ新しい1Dまたは2Dテクスチャ配列を返します。

この関数は暗黙的にflags にQRhiTexture::TextureArray を設定します。

1 次元テクスチャ配列は、flags にQRhiTexture::OneDimensional が設定されている必要があります。pixelSize の高さが 0 の場合、この関数は暗黙的にこのフラグを設定します。

newTexture()も参照してください 。

QRhiTextureRenderTarget *QRhi::newTextureRenderTarget(const QRhiTextureRenderTargetDescription &desc, QRhiTextureRenderTarget::Flags flags = {})

desc で指定された色と深度/ステンシルアタッチメントを持ち、指定されたflags を持つ新しいテクスチャレンダリングターゲットを返します。

QRhiResource::destroy()も参照 。

QRhiResourceUpdateBatch *QRhi::nextResourceUpdateBatch()

コピータイプの操作を記録できる、利用可能な空のバッチを返します。

記録されるフレームに縛られないため、例えば以下のようなシーケンスが有効です：

rhi->beginFrame(swapchain);
QRhiResourceUpdateBatch *u = rhi->nextResourceUpdateBatch();
u->uploadStaticBuffer(buf, data);
// ... do not commit the batch
rhi->endFrame();
// u stays valid (assuming buf stays valid as well)
rhi->beginFrame(swapchain);
swapchain->currentFrameCommandBuffer()->resourceUpdate(u);
// ... draw with buf
rhi->endFrame();

QByteArray QRhi::pipelineCacheData()

このQRhi の有効期間中に正常に作成されたQRhiGraphicsPipeline およびQRhiComputePipeline から収集されたデータを持つバイナリデータ blob を返す。

キャッシュデータを保存し、同じアプリケーションの後続の実行で再読み込 むことで、パイプラインとシェーダの作成時間を短縮できる可能性があります。キャッシュとその直列化されたバージョンに何が含まれるかは特定されておらず、常に使用されるバックエンドに固有であり、場合によってはグラフィックス API の特定の実装にも依存します。

PipelineCacheDataLoadSave がサポートされていないと報告された場合、返されるQByteArray は空です。

create() の呼び出し時にEnablePipelineCacheDataSave フラグが指定されていない場合、PipelineCacheDataLoadSave 機能がサポートされていても、返されるQByteArray は空になることがある。

返されたデータが空でない場合、それは常に Qt のバージョンとQRhi バックエンドに固有です。さらに、グラフィック・デバイスや使用されているドライバのバージョンに強く依存している場合もあります。QRhi は、データが常に安全にsetPipelineCacheData() に渡されるように、適切なヘッダとセーフガードを追加します。したがって、別のバージョンのドライバで実行されたデータをロードしようとすると、安全かつ優雅に処理されます。

この機能の詳細については、EnablePipelineCacheDataSave を参照。

setPipelineCacheData （）、create （）、isFeatureSupported （）も参照 。

[static] bool QRhi::probe(QRhi::Implementation impl, QRhiInitParams *params)

与えられたimpl およびparams を呼び出したときに、create() が成功すると予想される場合に true を返す。

バックエンドによっては、create() を呼び出してその返り値をチェックし、その結果のQRhi を破棄するのと同じことである。

他のバックエンド、特にMetalでは、特定のプロービング実装があるかもしれない。これにより、失敗時にデバッグ出力を警告で汚染することなく、より軽量な方法でテストを行うことができる。

create()も参照のこと 。

void QRhi::releaseCachedResources()

バックエンドのキャッシュにあるリソースを解放しようとします。これには CPU リソースと GPU リソースの両方が含まれます。自動的に再作成できるメモリとリソースのみがスコープに含まれます。例として、バックエンドのQRhiGraphicsPipeline 実装がシェーダーのコンパイル結果のキャッシュを保持している場合、この関数を呼び出すとそのキャッシュが空になり、メモリとグラフィックリソースが解放される可能性があります。

リソースに制約のある環境では、この関数を呼び出すことは理にかなっています。ある時点で、パフォーマンスを犠牲にしてでもリソースの使用を最小限に抑える必要があります。

void QRhi::removeCleanupCallback(const void *key)

keyクリーンアップ・コールバックがkey に登録されていない場合、この関数は何もしません。キーなしで登録されたコールバックを削除することはできない。

addCleanupCallback()も参照 。

int QRhi::resourceLimit(QRhi::ResourceLimit limit) const

指定されたリソースlimit の値を返します。

値は、初期化時にバックエンドによってクエリされることが期待されます。つまり、この関数を呼び出すことは軽い操作です。

void QRhi::runCleanup()

登録されているすべてのクリーンアップ関数を呼び出します。その後、クリーンアップコールバックのリストがクリアされます。通常、QRhi を破棄すると自動的にこの処理が行われますが、キャッシュされた必要でないリソースをすべて解放するためにクリーンアップをトリガーすると便利なことがあります。

addCleanupCallback()も参照 。

void QRhi::setPipelineCacheData(const QByteArray &data)

data をパイプラインキャッシュにロードします。

PipelineCacheDataLoadSave がサポートされていないと報告された場合、この関数を呼び出しても安全であるが、何の効果もない。

pipelineCacheData() によって返される blob は、常に Qt バージョン、QRhi バックエンド、場合によってはグラフィックデバイス、グラフィックドライバの特定のバージョンに固有です。QRhi は、データが常にこの関数に安全に渡されるように、適切なヘッダとセーフガードを追加します。ドライバが新しいバージョンにアップグレードされた場合や、データが異なるQRhi バックエンドから生成された場合など、不一致がある場合は、警告が出力され、data は安全に無視されます。

Vulkanでは、これはVkPipelineCacheに直接マッピングされます。この関数を呼び出すと、新しいVulkanパイプラインキャッシュオブジェクトが作成され、その初期データはdata 。このパイプラインキャッシュオブジェクトは、その後に作成されるすべてのQRhiGraphicsPipeline 、QRhiComputePipeline オブジェクトで使用されるため、パイプラインの作成が高速化される可能性があります。

他の API では、実際のパイプラインキャッシュはありませんが、シェーダーコンパイル（D3D）ま たはプログラムバイナリ（OpenGL）のバイトコードでキャッシュを提供することがあります。実行時にソースから多くのシェーダーコンパイルを行うアプリケーションで は、この関数を使用した以前の実行から「パイプラインキャッシュ」が事前にシードさ れていれば、その後の実行で大幅なブーストを提供できます。

この機能の詳細についてはEnablePipelineCacheDataSave を参照してください。

pipelineCacheData() およびisFeatureSupported()も参照してください 。

[static] QSize QRhi::sizeForMipLevel(int mipLevel, const QSize &baseLevelSize)

与えられたmipLevel のテクスチャ画像サイズを返します。これは、baseLevelSize で与えられたレベル 0 サイズに基づいて計算されます。

QRhiStats QRhi::statistics() const

グラフィックスリソースのタイミングと割り当てに関する統計を収集し、返します。

メモリ割り当てに関するデータは、そのような操作がQtの制御下にある、いくつかのバックエンドでのみ利用可能です。リソースのメモリ割り当てに対する低レベルの制御がないグラフィックスAPIでは、これは決してサポートされず、結果の関連するフィールドはすべて0になります。

特にVulkanでは、値は常に有効で、基礎となるメモリアロケータライブラリから照会されます。これにより、アクティブバッファとテクスチャのメモリ要件を知ることができます。

Direct 3D 12も同様です。メモリアロケータライブラリの統計に加えて、ここでは、DXGI によって報告された、メモリアロケータライブラリの制御下にない追加リソース（スワップチェーンバッファ、記述子ヒープなど）を含む合計サイズを報告するtotalUsageBytes フィールドも結果に含まれます。

この値は、使用されるすべてのタイプのメモリを合計したものです。(例: ディスクリート GPU の場合、ビデオ + システム)

グラフィックスとコンピュートパイプラインの作成に費やされた合計時間（通常、シェーダのコンパイルやキャッシュのルックアップを含み、潜在的に高価な処理を伴う）のようなミリ秒単位の追加データは、ほとんどのバックエンドで利用可能です。

QList<int> QRhi::supportedSampleCounts() const

サポートされているサンプル数のリストを返します。

典型的な例は(1, 2, 4, 8)である。

バックエンドによっては、このサポートされる値のリストがあらかじめ固定されているものもあれば、（物理的な）デバイスのプロパティによって、実行時にサポートされる値が示されるものもある。

QRhiRenderBuffer::setSampleCount()、QRhiTexture::setSampleCount()、QRhiGraphicsPipeline::setSampleCount()、QRhiSwapChain::setSampleCount()も参照のこと 。

QThread *QRhi::thread() const

QRhi がinitialized されたスレッドを返す。

int QRhi::ubufAligned(int v) const

ubufAlignment() で指定された一様バッファ・アライメントにアライメントされた値 (通常はオフセット)v を返す。

int QRhi::ubufAlignment() const

一様バッファオフセットアライメントの最小値をバイト単位で返します。これは通常256である。

この値にアライメントされていないオフセットで一様バッファ領域をバインドしようとすると、バックエンドや基礎となるグラフィックスAPIによっては失敗します。

ubufAligned()も参照 。

[static] QRhiSwapChainProxyData QRhi::updateSwapChainProxyData(QRhi::Implementation impl, QWindow *window)

impl で指定されたバックエンドおよびグラフィックス API に固有の不透明データを含むQRhiSwapChainProxyData 構造体を生成して返します。window は、スワップチェーンがターゲットとしているQWindow です。

返された構造体はQRhiSwapChain::setProxyData() に渡すことができる。これは、スレッド化されたレンダリングシステムでは理にかなっています。この静的関数は、すべてのQRhi 操作とは異なり、メイン（gui）スレッドで呼び出され、その後、QRhi とQRhiSwapChain を操作するスレッドに転送され、スワップチェーンに渡されることが期待されます。これにより、例えばNSViewからCAMetalLayerにクエリを実行し、そのデータをレンダリングスレッド上のQRhiSwapChain 。Metalの例では、専用のレンダリングスレッド上でview.layerアクセスを行うと、Xcode Thread Checkerで警告が発生します。データプロキシメカニズムを使用すると、これは回避されます。

スレッドが関与していない場合、QRhiSwapChainProxyData を生成して渡す必要はありません。バックエンドは、必要なものは何でもそれ自身でクエリできることが保証されており、すべてがメイン（gui）スレッドに存在するのであれば、それで十分です。