@wolfpld@JamesWidman A small tip in case it helps with your startup time: when I have huge bulk data like this I segregate it into separate sections for pointer-containing and non-pointer-containing data so that the load-time pointer fix-ups/relocs only happen to the pages in the pointer data section.
@wolfpld@JamesWidman I didn't look closely enough to see whether that will happen automatically as a result of data vs rodata splitting in your case but it's something that can otherwise help if startup time is a concern. (Alternatively, you can use relative pointers, which can typically get away with being 32 bits on 64-bit platforms, but that's a more disruptive change.)
@pervognsen@wolfpld one thing I'm curious about is how that interacts with like, the GPU driver and everything else. Maybe they have a separate process for gameplay? Or maybe that just works and I'm overthinking it.
It's nice to have an image viewer that actually works.
Of course, Wayland is completely broken, as the only supported use case is when you have, for example, a 640x480 window (at 100% scale), and you scale it to the ratio of your DPI scale, say 150% to get a 960x720 rendering area, which the compositor then "scales down" to the logical 640x480 to account for higher DPI.
Image viewers on Linux are in such a strange place. 30+ year old formats? Sure. Anything more modern? Roll the dice. Compressed textures? Lol!
There's this text-based viewer I like that outputs sixel data to the terminal. I wanted to see how I could extend it to support more formats. Turns out it's just an argv parsing shim over some Rust libraries.
Some graphical viewer? Qt was built wrong, so no JXL support. And it's 5 FPS when you pan an image, because everything is software rendered.
@castano No support for DDS or PSD in current KDE. Maybe if you install some random plugin from github, but come on. It's not that hard and should be included by default.
On the other hand, I noted some time ago that spectacle (the KDE screenshot thing) lost the ability to crop images. The only thing I used out of all the tools it provided! Later I read an explanation that it was only there because some library randomly provided it, and that library dropped support. So it's not there anymore.
For some time now I've been working on BC7 support in etcpak.
The codec I used as a base is Rich Geldreich's bc7enc, the 4-mode fast one. The results are bit-exact, so don't bother with checking the metrics.
(I find it hard to understand why you would want to go with a full-featured and slow codec (such as bc7e.ispc) and then put RDO on top, which degrades the quality way below what the fast codec can achieve.)
I spent much of yesterday evening chasing a crash in the Intel driver and/or validation layers. Finally it turned out that it was fixed in the validation layers back on January 18th.
But the latest release on GitHub is 1.3.275, made on January 10th. And it's actually something Android related instead of a proper release?
Looking at the git tags, there have been 4 "non-releases" and we're now on v1.3.279.
@wolfpld right now aside from Android, layers are only released through the LunarG SDK. Maybe we can get CI builds on GitHub for other platforms in the future.
@aras It's complicated. The code is the same as before, in the parts that matter. The compilers have improved, as you can see in the Intel timings below. The Intel chip supports AVX512 FWIW.
There is no explicit AVX512 in the code paths, but I compile with -march=native and clang is very happy to transform the logic expressed with AVX2 (or SSE2) intrinsics into AVX512 code.
@aras That was my original intention, but the API is incompatible.
They write in the readme that the ideal use case is to decompress large blocks, and streaming data is not so good. I haven't looked at the internals of libpng, but my guess is that they don't decompress more than a single line of data at a time.
How common are forced separate gfx and present queues in Vulkan? Does this separation exist on real hardware, or is it just a theoretical possibility?
To see if present is supported on a queue, you need to pass a surface to draw on to vkGetPhysicalDeviceSurfaceSupportKHR. This allows you to select the queue setup that will work.
But what if you don't have a surface to render to yet, but want to create a VkDevice that will be able to present?
Getting all the queues preemptively but using only one seems wasteful though.
The real reason I wanted to create multiple VkDevices is because I assumed VkSwapchain imageSharingMode was part of VkDevice creation. It's not, as your question reminded me.
An interesting topic came up in the PRs, related to the recent blog posts by @forrestthewoods.
Should it be acceptable for a C++ build process to require network availability to succeed?
To put it in context, the network would be used to download the source code of some of the libraries that need to be compiled and linked into your program.
My stance is that builds should be local only, but maybe I'm just an old man who hasn't noticed that modems are long gone by now?
@wolfpld@forrestthewoods This all greatly simplifies all our development processes - at the cost of a little overhead when adding an external dependency (needing to clone it to infrastructure before committing), but that's a rare enough event and just means juggling a but of gitea web UI.
We could ofc. automate that as well, but it really isn't worth it.
Our development environments are cross-platform and yet onboarding instructions are just "install nix, clone the repository, run a build".
@pervognsen@wolfpld@forrestthewoods yeah; by default it seems that a dependency-resolving program (like conan or similar) should first check a local cache directory for each of the tarballs it needs. If they're already there (because you copied them from a flash drive or something), then the conan-ish program shouldn't need to download anything.
it should also be able to give you a list of everything it would have downloaded so that you can do that part independently.