В данной статье продемонстрированы некоторые возможности оптимизации, открывающиеся при хотя бы поверхностном учете особенностей "железа", на котором исполняется кернел. Полученные цифры весьма далеки от предельных, но даже они показывают, что при том наборе возможностей, который имеется здесь и сейчас (OpenCL API в реализации разработчиков терминала не позволяет контролировать некоторые важные для оптимизации параметры - - в частности, размер локальной группы), выигрыш в производительности в сравнении с исполнением хостовой программы очень существенен.
.
公開を約束した動画はこちらです。画質は悪いですが、応答遅れを見ることができないわけではありません。
実際、端末の遅延は少なくなっています。レコーダーをつけると、すべてが2倍遅くなる。プロセッサーの読み込みも格段に向上しています。
そのため、この動画から反応速度を完全に客観的に把握することはできませんが、ウィンドウの更新速度とウィンドウサイズとの間にパターンがあることは明らかです。
(そのため、大きさの違う窓をいくつか作りました）。
画像のレスポンスが悪くなる原因が正確にわかった気がします。ColorToARGB()関 数の定数呼び出し である。イベントごと、ピクセルごとに、この関数を呼び出す。一度計算した色をすぐに使うのではなく、常に再計算しています。
ここがポイントだと思うんです。
追伸：追記し忘れましたが、全ウィンドウのオブジェクトの総数は35個です。
.
公開を約束した動画はこちらです。画質は悪いですが、応答遅れを見ることができないわけではありません。
実際、端末の遅延は少なくなっています。レコーダーをつけると、すべてが2倍遅くなる。プロセッサーの読み込みも格段に向上しています。
したがって、この映像から反応速度を完全に客観的に把握することはできませんが、ウィンドウの更新速度とウィンドウサイズとの間にパターンがあることははっきりとわかります。
(そのため、大きさの違う窓をいくつか作りました）。
画像のレスポンスが遅くなる原因がはっきりした気がします。ColorToARGB()関 数の定数呼び出し である。イベントごと、ピクセルごとに、この関数を呼び出す。一度計算した色をすぐに使うのではなく、常に再計算しています。
そこがポイントだと思うんです。
追伸：追記し忘れましたが、全ウィンドウのオブジェクトの総数は35個です。
ソースコードを見ていただくことは可能でしょうか？自分にとって、自分の経験にとって。
OpenCLでCanvasのレンダリングを高速化するのは現実的か？
OCLは、並列処理能力＋ベクトル演算能力を持っているので、レンダリングやオーバーレイの処理速度が速くなるんですね。
ベクトルの使い方については、Mathematicsの記事 https://www.mql5.com/ru/articles/407 をご覧ください。
OCLは並列処理が可能で、ベクトルも扱えるので、描画やレイヤリングの速度が上がります。
ベクトルの使い方については、Mathematicsの記事 https://www.mql5.com/ru/articles/407 をご覧ください。
CCanvasのErase()と OpenClで作ったPixelSet() ループの速度を比較しましたか ？理論上、高速化を図れば、中間結果をキャッシュするなどの複雑な処理をしなくても、ダサい描画コードを作ることができるのです。
ちなみに、この配合でレイヤーを混ぜるのですか？
はい、計算式はwikipediaのもので、各色成分 について： 結果＝背景＋（前景-背景）＊アルファです。
ところで、OCLのEraseには問題があります。memsetのアナログはありません（CUDAとは異なります）。そのため、ホストでEraseを行い、CLBufferWriteでクリーンアップされたアレイをコピーする必要がありますが、これは単純なEraseより高速ではありません。
一方、作業単位に1点ずつ書き込むタスク配列を作ってみましたが、速度は思い出せません。以前の方法より遅かったような気がします。
そして、OCL 1.2 では、それを行うclEnqueueFillBuffer() が あります=> MQL 構文によれば、 CLBufferFill() があるはずです。
しかし、このラッパーは（バージョン1.1が移植されたため）実装されていません。
はい、計算式はwikipediaのもので、各色成分 について： 結果＝背景＋（前景-背景）＊アルファです。
ところで、OCLのEraseには問題があります。memsetのアナログはありません（CUDAと異なります）。そのため、ホストでEraseを行い、CLBufferWriteでクリーンアップされたアレイをコピーする必要がありますが、これは単純なEraseより高速ではありません。
一方、作業単位に1点ずつ書き込むタスク配列を作ってみましたが、スピードは思い出せず、前の方法より遅かったような気がします。
そして、OCL 1.2 では、それを行うclEnqueueFillBuffer() が あります=> MQL 構文によれば、 CLBufferFill() があるはずです。
しかし、このラッパーは（バージョン1.1が移植されたため）実装されていません。
イングリッシュビックでは、半透明の層を2つ混ぜるという面白い処方になっています。半透明のインターフェイスなど、きれいなものを作ることが可能です。
私の場合、これは必要なく、すべてが正しくブレンドされます。A層より下にあるものは、たとえB層が上にあったとしても、基板とみなすことができ、それを通して基板そのものが光り輝く。