ＵＳＢドライバも正しくインストールして、さらにデバイスマネージャーからもスマホやタブレットがきちんと見えているのに、Android StudioからRunボタンを押すと、エミュレーターが立ち上がっってしまい、実機実行できないことがあります。
これは、実行の設定がEmulatorになってしまっているためです。
設定メニューの Run -> Edit Configurationで、
General -> Target Device の設定を USB Device もしくは Show chooser dialog
にする必要があります。
何かの拍子でEmulatorの設定にしてしまうと、結構はまりますのでご注意ください。
私も何度もはまって、必要のないＵＳＢドライバのアンインストールとインストールを繰り返してしまいました。
このサイトから、サンプルをダウンロードしてみた。
Samples: Overview | Android Developers
include fileへのパスがつながっていないみたいでビルドできない。
#include
#include
などのところでエラーがでる。
build.gradle を編集すればよさそうな気もするがよくわからない。
前回の記事で、Eclipse + ADT からAndroid Studioに移行をもくろみうまくいきませんでした。
その後しばらく放置していましたが、最近また触り始めました。
いくつか設定が必要なことに気づきました。
File->Other Settings->Default Project Structure->SDKs
でJAVA SDKのパスを正しく設定しないといけないです。
ついでにこのメニューでＮＤＫもインストールしました。Eclipse + ADTの時にはＮＤＫも手動で設定が必要だったのですが、Android Studioではそういう面倒なことは必要ないようです。
また、各プロジェクトで
'File' -> 'Project Structure'->'Modules'で Module SDK のNEWを押して、例えばAndroid 4.4などを指定しなければいかなかったです。
上記設定で、以下のサイト置いてあったGLESのサンプルが実機で動きました。
Displaying Graphics with OpenGL ES | Android Developers
Khronosグループが発表している、2015年8月時点で最新のVulkan Overviewを読んでみました。
https://www.khronos.org/assets/uploads/developers/library/overview/vulkan-overview.pdf
※ Khronosグループとは、OpenGL/ES, WebGLといったGraphics APIのオープンスタンダードを手掛ける非営利の共同コンソーシアムで、日本の企業も参加しています。
Vulkanの特徴
いろんなデバイスにＧＰＵが乗るようになってきた。
ＧＰＵは３Ｄグラフィックスだけのためじゃなくなってきた。
じゃあ、そのＧＰＵを効率的に使えるようにしないといけない。
Vulkanはlow-overheadで多くのベンダーのＧＰＵをサポートする。
mobile, desktop, console, embedded platformすべてで同一のＡＰＩを提供
デバッグ、評価のレイヤーと最終製品レイヤーを分けられる。
OpenGL/ES とVulkanとの大きな違い
OpenGL/ES
複雑なドライバＧＰＵドライバ層、overheadが大きい、負荷の予想ができない
ドライバがＧＰＵコンテクスト保持・更新、メモリーマネジメント、エラーマネジメントすべてを行う。
エラーマネジメントが常に動いている（安全ともいえる）
APIはGLとESで、デスクトップとモバイル用に分かれている
Vulkan
メモリマネジメント、スレッドマネジメント、コマンドバッファの生成・更新のすべてをユーザーアプリが行う。
ドライバはシンプルになり、low-overhead。
エラーマネジメントは必要な時だけ動かせる。
モバイル、デスクトップ、組み込み機器のすべてで同じＡＰＩを使用
上記特徴を知ったうえで、開発者はGL/ESを使うか、Vulkanを使うかを選択できる。
ミドルウェア、エンジン
ユーザーアプリとVulkanの中間にミドルウェアやゲームエンジンなどが入ることがあり、これらのエンジンがハードウェアをダイレクトに操作することで処理速度が向上する。
Vulkanのmulti-threading
コマンドバッファ作成スレッドと、コマンドを投げるスレッドを別々に並列に実行できる。ＧＰＵがＣＰＵを待つことなく次々とコマンドを受け取ることができるようになる。
SPIR-Vという中間言語が提供される。
３ＤグラフィックスＡＰＩとして、２大勢力がOpenGLとDirectXがあります。
DirectXはマイクロソフト、でOpenGLはクロノスグループがそれぞれ作成・アップデートを行っています。
これらのGraphics APIは、ハードウェアであるＧＰＵの違いを吸収しいろいろなハードでプログラムが動作するように、ハードウェアを抽象化するような分厚い中間レイヤーを持っています。
そのおかげで、異なるＧＰＵを積んでいるような様々なＰＣで同じコードが動作するようになっています。
しかし、便利な反面、ＡＰＩコールのオーバーヘッドが大きくなり、実行速度が遅くなる場合があります。
例えばDraw call一つとっても、異なるＧＰＵに合わせて多くのコンテキストの設定が必要になりますが、それらはＧＰＵの負荷ではなくＣＰＵの負荷として、効いてきます。
つまり、Graphics APIのＣＰＵ負荷が無視できないくらい大きいのです。
Xboxやプレステ, Wiiなどのゲーム機では、このグラフィックスＡＰＩのオーバーヘッドが軽く作ってあり、ハードに最適化したプログラムが書けるようになっています。対象となるハードが１種類なのでこのようなことができるのです。
もちろん、ＧＰＵ内のシェーダーやＧＰＵ内部の処理がネックになっている場合はＡＰＩのオーバーヘッドが変わっても実行速度が変わることはありません。
余談ですが最近目にしたLow overhead APIの記事でもＧＰＵの処理を軽くするような記述がありました。あくまでGraphics APIの持つ、ＣＰＵのoverheadの軽量化が主で、ＧＰＵ処理の最適化はまた別の話です。誤解しやすい点ですので注意しましょう。
前置きが長くなりましたが、最近このＡＰＩのオーバーヘッドが低いLow layerのGraphics APIがあちこちから発表されています。
DrectXは、DirectX12
OpneGLは、Vulkan
また、AndroidもVulkanをサポートするとGoogleから発表されています。
Low-overhead rendering with Vulkan | Android Developers Blog
Appleは、Metal
AMDはMantleという名前で独自のAPIを発表しています。
http://www.amd.com/ja-jp/innovations/software-technologies/technologies-gaming/mantle#
この中で、Mantleに関してはかなり前に発表されたのですが、今はあまり話題になっていません。
現状ではDirectX12とVulkanがメジャーになりそうな予感です。
Metalに関しては、よくわかりません。
とくにDirectX12は、Windows10に合わせてリリースされたこともあり話題になっていますが、最初に書いたようにLow OverheadのAPIというのは、速度が速いといういい面だけではなく、
ハードに合わせた記述をしないと最悪ハングしたり、うまく速度が出なかったり、プログラマの力量がそのまま出てしまう面がありますし、移植もやりにくくなるのではないかと思われます。
DirectX 11のテクスチャ圧縮フォーマットBC1～BC7についてまとめてあるページを見つけました。
DirectX 11の圧縮フォーマットBC1～BC7について（前編）
http://www.webtech.co.jp/blog/optpix_labs/format/6993/
DirectX 11の圧縮フォーマットBC1～BC7について （後編）
http://www.webtech.co.jp/blog/optpix_labs/format/7006/
アルゴリズムまで丁寧に解説してあります。
今までローカルで管理していて論文を、最近はやりのreadcubeで管理してみることにしました。
https://www.readcube.com/
スマホアプリもあるようです。
私の場合、詳細に読む論文と流し読みする論文がカオスのようにハードディスクに入ってしまっているので、
これがうまく管理できるといいですが。
