HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2015
0605
Velgailメモリ書き換えを用いたマルチプロセスグラフィック1解決


Velgail

リンク

2015/6/5(Fri) 02:40:32|NO.69673

タイトルを見て「何を言っているのだ」という方が大多数だと思うので、
サンプルプログラムをお見せしつつ、何がしたいのかを書いていこうと思います。
但し、メモリ書き換えが行われるようなプログラムなので、
危険性を認識した上で実行するようにお願いします。
(主にソースコードを自分で読む等)

サンプルプログラム:
https://drive.google.com/open?id=0B3Iyqr1DZrPqUl9uLW1YeVRKT28&authuser=0

HSPでグラフィックを描いているときに、ふと思ったのです。
「ドロワータスクを計算タスクと分けたい」と。

普通に使っていれば、グラフィックを描画中は計算はできませんし、逆もしかりです。
ですが、計算が多すぎればコマ落ちしますし、グラフィックが重すぎると計算が満足にできません。
HSPはマルチスレッドプログラミングは事実上できないといえるので、普通の手段ではこの状態は回避できません
(いや、そりゃアルゴリズムで何とかするのが上策でしょうけど)

さて、このサンプルプログラムは、「グラフィック描画部分」と「計算部分」の分離のサンプルです。
サンプルプログラムのファイルには
get(グラフィック受信側)<-gen(グラフィック発生器)の構造として大量の実行ファイルができていますが、
shared系以外はgenを起動する事はできません。

1. Shared系:(SharedGGet <- SharedGGen)
メモリ共有型で作ったサンプルです。
http://chokuto.ifdef.jp/advanced/sharedmem.htmlを参考に作ったものです。
長所:
Get側主体でVRAMデータをコピーするので他より安全
短所:
 メモリ間コピーの回数が1回増えるので他より遅い
 Get側の手間が増える(メモリ間コピー1回分)

2. 無印系:(GGet <- GGen)
メモリ干渉型(他プロセスメモリ書き換え型)で作ったサンプルです。
http://peryaudo.hatenablog.com/entry/20100516/1273998518を参考に作ったものです。
長所:
 Gen側からGet側へ送りつけることができるので、redrawだけで表示が可能
短所:
 Gen側がデータの送信を間違えると最悪ブルースクリーンを起こす

3. 応用例:(GGetXsamples <- GGenAmano, GGenDiamond, GGenShirano, GGenVerge)
d3moduleのサンプル4つの表示を一つの画面にまとめた形で表示させるプログラムです。
d3moduleのサンプルは一つ一つが非常に重いので、Core i3以上推奨です。
使い道の例として提示しています。

・既知の問題と今後の展望

 フレーム同期をしているわけではないので、ちらつく可能性がある。
 gcopy/gzoomが意外と重い。
 マウス・キーボード入力が渡せない→対応する予定
 きちんとライブラリ化→対応する予定



この記事に返信する


nepi

リンク

2015/6/11(Thu) 20:07:31|NO.69728

おお今使いたかった物がまとまっている..
使わせてもらいます。



ONION software Copyright 1997-2018(c) All rights reserved.