COARSE_GRAIN_BUFFERの方が使いやすそう。clEnqueueMapBuffer()だと、同じOpenCLバッファを指定してもCPU側のポインタが同一であることは保証されないんじゃないかなあ…？clSVMAlloc()ならその時点でCPU側のポインタは決定されるので、clEnqueueSVMMap()しても影響はないのかなって。
SASANO Takayoshi(@uaa@social.mikutter.hachune.net)の投稿 OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
COARSE_GRAIN_BUFFERの方が使いやすそう。clEnqueueMapBuffer()だと、同じOpenCLバッファを指定してもCPU側のポインタが同一であることは保証されないんじゃないかなあ…？clSVMAlloc()ならその時点でCPU側のポインタは決定されるので、clEnqueueSVMMap()しても影響はないのかなって。
Debian上でのIntel HD630なOpenCL2.0、CL_DEVICE_SVM_FINE_GRAIN_BUFFER未対応なのかなあ。CL_DEVICE_SVM_COARSE_GRAIN_BUFFERしか使えないってステータス返ってくる。（だったらOpenCL1.2でclCreateBuffer(CL_MEM_ALLOC_HOST_PTR)でいーんじゃね？って気がする）
このアカウントは、notestockで公開設定になっていません。
の投稿
Mzrapid@mstdn.poyo.me
このアカウントは、notestockで公開設定になっていません。
の投稿
Mzrapid@mstdn.poyo.meこのアカウントは、notestockで公開設定になっていません。
あと EU 圏の人々は GDPR でサイバーノーガードできちゃうから、「法律で守られているから『本当の意味での削除』は可能だ」みたいな幻想を抱いていても不思議ではないなという気持ちがある。知らんけど。
まあ結局、「ユーザは『不可視化できても削除はできない』SNS に耐えられない (よって履歴の保持を任意にしてもいける)」と判断されたということなんでしょうね。本当の意味で削除が可能な投稿なんてほぼないのに。
Updates to Repository Sync Semantics | AT Protocol
https://atproto.com/blog/repo-sync-update
> Even though we are setting the prev field, this can be considered a “hint” and the history is no longer considered a canonical part of the repository.
僕には耐検閲性を捨てるように見えちゃってそんなことでいいのかAT Protocol…
Updates to Repository Sync Semantics | AT Protocol https://atproto.com/blog/repo-sync-update
まあ古い時代の物なのでArcとは相性があんまり良くない、なのかもだけど。
ん－む、fr-025 The popular demo (Farbrausch)…Arc A770だと解像度の最高が1680×1050になって、MSAAはoffしか選べない。確かRX6400だと1920×1080でMSAA onはできたはずだと記憶してるんだけど。
やっぱりLLMでかな漢字変換できないかなー？とか考える人は居るか。自分もこれが実現したら結構快適な変換になるんじゃないかとかちょいとばかり期待してたりするんだけど（必要となるリソースが膨大なものになりそうな気がするけど）。 ChatGPTとGPT-4にかな漢字変換させてみた (2023/3/19) https://zenn.dev/azookey/articles/6b405c7d63fc6d
このアカウントは、notestockで公開設定になっていません。
膨大な計算を行うための計算機資源と、学習に使える（権利上問題ない）コンテンツ、あとはそこから導き出される結果が問題ないかを検証する人間の費用…その辺で商売してるんだろうなーというのはなんとなく感じてた。
統計処理である以上、同じ学習データ、同じプロンプトからは同一の結果が出ると理解してるんだけど…人間のような「揺らぎ」ってどの程度あるんだろう。
このアカウントは、notestockで公開設定になっていません。
あああああああああ作業中のファイル消したああああああああ
LPCNetState自身をSVM上に置いちゃうしかないか…あとは各所で見かけるfloat なんとか[サイズ]もSVM上に配置。そこまでやってもパフォーマンスが出るかどうかは謎。
lpcnet.cだけ手を入れれば良さそうか。vec_opencl.hの内容はopencl.cか何かとして独立させないとinit_vector_engine()による初期化の問題が出てくるかも、これは。
ちょ、sgemv_accum8x4もsparse_sgemv_accum8x4もdrowe/LPCNetでは未使用なのか…（xiph版はどうなんだろ）
CH55xをArduinoIDEで使う (2022/01/09) https://qiita.com/akita11/items/d7baed4ca3c06e292637
多少遅いとはいえ、SVM Fine Grain Bufferの手軽さは魅力だなあ。 https://rigaya34589.blog.fc2.com/blog-entry-870.html
https://social.mikutter.hachune.net/@uaa/110910782520761819
INTEL-SA-00812の件、Intelからの回答があって「Intel製のArc770/750搭載カード」に脆弱性があるという話でした。なので「Intel Arc GPUに脆弱性」という取り上げ方は、不正確です。
都心で仕事するのはもうできないかも…混雑を見ているだけで耐えられないという感情が（一瞬でも）制御できないのは、ちょっとマズい。
しっかし、とある試験でTKP市ヶ谷カンファレンスセンターへ行ったけど…あの空間に人が密集する光景で一瞬精神的に「うっ」ってなっちゃったんだよねえ。トイレはなんか狭いし、階段の幅も非常時にあの人数を短時間で安全な場所へ移せる帯域幅があるとは思えない。椅子の座り心地もあんまし良くなかったし。来年またあそこへ行く事態になりたくないと心底思っているんだけども、どうも避けられない感じ。