Ok, I’ve already built my ‘buildtools’ and now the OS is building as well.
I see jam is also downloading some hpkg in order to build the anyboot image, can I prevent it from downloading those (as this would save both time and disk space) ?
the kernel image I seek for will be named haiku.hpkg or something ?
Thanks!
No.
Yep, but with the additional hrev no.
FYI: the own-built Haiku wont show the Haiku logo at boot. This is intentional.
The whole system will be is inside of haiku.hpkg package together with the kernel itself (kernel_x86_64).
We don’t download things just for fun, but because they are required to compile Haiku. So, no, you can’t build Haiku without these.
The build ended successfully! 
I am glad the kernel doesn’t require an endless configuration step as linux!
as the boot logo is still there after updating haiku(blahblah).hpkg, I think I made some mistakes on the path: how can I check I am running my own built kernel?
before launching the build I forgot editing the macro KDEBUG_LEVEL, so it is still ‘2’ . I will modify the value to ‘0’, has jam some sort of “jam clean” or something?
Thanks
Note: I’ve built the hrev55874, the same I used in the benchmark, so the comparison is fair.
You shouldn’t need to clean when changing that file, jam should rebuild everything that depends on it (i.e. the whole kernel and most drivers.)
The easiest way to clean everything is deleting things directly from the “generated” directory.
In this case, to be sure everything is built correctly (shouldn’t be needed) and also to not keep old files you don’t need (debug and non-debug files are built in different directories) you can delete objects/common/ and objects/haiku/ and then rebuild them.
I removed both objects/common and objects/haiku, then re-launched jam, but an error raised:
https://0x0.st/oKG0.txt
I can’t catch the root cause - I didn’t modify any files (but build/config_headers/kernel_debug_config.h of course)!
Can you help me ?
If you’re building from Haiku, make sure the haiku_devel package is installed.
I got the point: it has to match the running kernel.
Thanks
Updated the result table linked in my first post.
I’ve done everything suggested to remove any debug features, but the numbers show not much improvements.
Did you update ffmpeg ? Because there are significant changes in ffmpeg over the version numbers, i know x265 has seen a lot of optimization over the years.
Roll down the Linux ffmpeg version to match the one in haiku, test apples to apples
Both the videos linked in my post are uncompressed material, so I could use them to directly feed x265.
No ffmpeg involved in any steps.
I want to share some results of my encoding series, that may require some investigation.
After applying my latest patch to x265 (https://github.com/haikuports/haikuports/pull/6677) I did a new series using both SolLevante and TearsOfSteel as input. Last night I went with:
boot Haiku → encode SolLevante (1.37 fps) → encode SolLevante (1.19 fps)) → encode SolLevante (1.18 fps) → encode SolLevante (1.18 fps)
After seeing this, I changed my strategy when encoding ToS, so I did:
boot Haiku → encode ToS (2.44 fps) → boot Haiku → encode ToS (2.20 fps) → boot Haiku → encode ToS (2.20 fps)
Now, I see the most common performance lie together with the previous runs (so they seem to be “right”), but those odd cases, well, they happened indeed!!!
I don’t know whether they are repeatable (it seems they aren’t, after all rebooting the OS doesn’t bring the performance jump) and I would like to seek HOW make them appear again. I don’t know Haiku very well, so I cannot tell some tasks which auto-start or suddenly end freeing resources, I can’t (some caching perhaps? across reboots? naaah). Where can I start to shed some lights on all this?
Are you using the same revision of ffmpeg on linux and haiku??? if not, the comparison is not accurate