SotCodeLaureate

Thanks! Yeah, this one is supposed to be a very simple implementation for a kind of "how to write a machine code interpreter" tutorial, but I was looking to experiment with some optimizations if time permits. Patching with pre-baked alt-bytecode was one of the ideas indeed.

Recently I wrote a simplistic RISC-V interpreter for educational purposes mostly, and a friend was benchmarking it against several scripting system in the context of game-character control routines. Well, it's quite fast for what it is, though Lua is still somewhat faster, heh.

Some benchmarking code is here: https://github.com/glebnovodran/roam_bench

Couple years ago was experimenting with portable OpenGL rendering, and, interestingly of all platforms I had to deal with the Web was the easiest target :) - thanks to the excellent emscripten largely.

If interested, you can find the code/demo here: https://github.com/schaban/crosscore_dev (the link to the online demo is there in the README)

> I'm going to start learning graphics for the first time

Vulkan is a quagmire of very low-level concepts, the danger of getting stuck in them and give up without learning anything is just too high.

At the same time making something with OpenGL that is more interesting than a simple rotating cube is not that difficult and you will get a lot of mid-level understanding - how rendering pipeline implemented and organized, what kind of task it is. "Porting" this knowledge to Vk is straightforward.

> No I mean do full software rendering, no shaders, no graphics card.

But why?

There doesn't seems to be a lot to learn about applied linear algebra (in the sense discussed here) by implementing a rasterizer.

But there is plenty of LA above and below that (in the scene management, in the shaders).

Well, to make an (imperfect) analogy with programming tools - Houdini is like Emacs, while Blender is more like Visual Studio.

That is not to say that one is intrinsically better than the other, but for a technically-minded person (== any programmer in this case), the way Houdini works will make much more sense.

Learning either of these tools is not an easy task, but I think that starting with Houdini will feel more natural in cases like yours (SE background, interest in interactive graphics).

You can email me (see my profile here) for some more Houdini-talk!

Please let me recommend SideFX Houdini as an artistic (yet technical) tool to learn: https://www.sidefx.com (perhaps would be a kind of therapy in itself - it was for me long ago)

> exploring toon shading

Sounds excellent! And don't hesitate to publish your work.

> terrain generation in OpenGL

Well, sounds like pretty interesting thing to do, so rewarding in itself maybe. Is it published on github or elsewhere?

Also, as someone doing graphics programming mostly as a hobby, I think a good thing to do is to learn the artistic side of things (to some extent), might give you some advantage.

He explains the carpet in the top comment under the video.

I came across a russian translation of Shahnamah several years ago, that was published in 1950-60s, and it's in rhyming verses unlike most other Western translations that mostly resort to prose approximations.

Amazing experience, I even remember cross-referencing certain passages in Tajik edition to try to get some idea of original rhyming and rhythmic techniques mentioned by the translators (I don't know the language, but since it was written in Cyrillic I could get at least a general idea how it sounds).

For whatever reason I stopped right before the Iskandar (Alexander the G.) parts, have to get back to it someday.

Frank L. Holt's books on the subject are really interesting, "Into the land of bones" in particular.

Neat.. of course it seems obvious now, but that's funny - I'm Ukrainian and I think that without explicit explanation it would have never occurred to me to read, let alone pronounce it this way - the dot before the extension somehow puts an insurmountable boundary after "olive".

> at least tens of thousands of simulated AI agents

Are you planning on displaying all/most of them every frame, or just to control that many of them, then draw those nearby/visible?

If it's the former (but how exactly?) then perhaps Vk is the way to go, if the latter, then it's hard to see how Vulkan vs OpenGL is all that relevant here.

> along the lines of Blender/Maya/Houdini

That's very interesting indeed, but arent's these lines are way too blurry?

That's why I'm using Houdini and not the other two.

And even then, Houdini is not set in stone, there were some significant changes during the years, an example of something that's probably most relevant here - say I prefer newer Wrangle operators in SOP rather than the classical visual programming style, but many Houdini people have the exact opposite preference.

I often recommend this book, RTCD, as a "better intro to data structures and algorithms" (sometimes as "the best"). The advice often falls on deaf ears, unfortunately.

SSE has scalar instructions - like "addss", "subss" etc.

These will be used by default (at O2 without vectorization enabled) for single-precision floating point math on x86-64 (where stack-based FPU is deprecated).

Vector instructions you're referring to end with "ps", they're very unlikely to be emitted for typical fp operations.

> PREFETCH

It's generated by GCC with "-fprefetch-loop-arrays", not supported in clang I believe.

> the compiler will never emit ... instructions like PSHUFB or PUNPCKxx

These are most certainly generated by GCC from C++ code (no intrinsics and such) - can even provide an evidence in the form of a codebase with appropriate build flags.

Their use is rather straightforward I think, but still.

> sqlite ... 19x slower

But is this a failing of wasm or the system glue layer, that for something like sqlite/web has to go through js/browser/etc?

Yes, I understand the importance of real-life tests like this, but how one is expected to go about testing wasm performance as such other than using benchmarks that are mostly arithmetic/logic and not syscall-type code?

> if the original uses highly-tuned x86 SIMD

BTW, if there is a problem with the current WASM performance, it's probably SIMD.

Again, based solely on my own benchmarks, exclusively in the area I'm interested in (game-type workload, so, say, multiplying many small matrices, performing geometric tests), there is little to no speed-up from wasm-simd128 (where it is supported), whereas native code compiled from the same sources, by the same compiler, profiled on the same machine, seems to be running a bit faster when vectorized.

> 3-5x slower than native

Depends on workload of course, but seems too pessimistic with the current state of WASM support. At least this is not what I'm seeing with the things I'm working on (graphics-related), when comparing to native builds.

See this test for example, native seems to be only 50% faster: https://old.reddit.com/r/WebAssembly/comments/vjxtv4/webasse...

> what do YOU not like about arm?

I find it difficult to read, it's aesthetics mostly, not necessary an architectural thing as such, the choice of mnemonics, why "ubfx", what's "rsb" - have to lookup these things constantly when I need them, while 6502 or x86 I can just open and read after all those years.

But that's just a personal preference certainly - yeah, I was fine with the abovementioned LDIR on Z80, heh.

Hm, as a counter-example, I learned assembly languages in this order - Z80, x86, 6502, ARM, SuperH, MIPS (then some more). SH and MIPS I like the most, not because of delay slots specifically, but I do like the concept. (The one I "hate" is ARM.)

Removing lighting before object recognition may be a separate step, yes. But in this case it's just that their goal is to scan objects, shapes as such, and not intrinsic properties of their constituent materials (such as specularity).

These are just standard OBJ files with diffuse textures only and trivial material settings (all white). Additional there is some metadata that specifies that the same data is to be used as displayable model and collision geometry.

So, essentially, this data is highly portable, photoreal aesthetics is not really a goal. (Also see some notes in the paper, e.g. "Limitations of the Dataset".)

No, you can't boot into ARM code without it. ARM part is disabled power-on, VPU is a general purpose processor really. Basically, on start-up it loads its start.elf (i.e. boot application compiled for its instruction set) from boot-media, initializes some hardware, then loads ARM boot image into common memory, then starts ARM. It also exposes some low-level hardware interface via syscall-type "mailbox" interface.

I don't know, I live right next to where this was happening, what I've heard seemed like artillery fire (not an expert though, but I probable will soon be).

Here is the latest local news on this (in Russian, this is russian-language news site in Odessa): https://dumskaya.net/news/v-chernom-more-vblizi-odessy-spasl...

Fortunately all 6 crew members seems to be safe (4 of them are Russians IIRC).

Apparently the power plant was captured by russian forces, source (in Ukrainian): https://censor.net/ua/news/3318857/okupanty_zahopyly_chaes

Right now the local news sources (I'm in Odessa, Ukraine) seems to diverge on this, some say there was an (averted) sabotage attempt, some say there is a fighting going on.