@wolfpld@mastodon.gamedev.place
@wolfpld@mastodon.gamedev.place avatar

wolfpld

@wolfpld@mastodon.gamedev.place

Author of Tracy Profiler, etcpak, and some other stuff.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

Nvidia driver with external sync is in beta.

Seems to work as expected. No more black flicker in Resolve, Noita, or Stardew Valley. No previous frames during hitches in Star Citizen.

@wonziu

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

Why is clang taking 5 minutes to compile a relatively small C++ (168 KB) source file? Let's see...

https://github.com/ggerganov/llama.cpp/blob/917dc8cfa67a72fb7c8bf7392270da3bf4833af4/unicode-data.cpp

Ah, oh, um... That's not how you do it.

Here's 10 MB of data as source code that compiles in about 8 seconds:

https://raw.githubusercontent.com/wolfpld/tracy/8983e14e1875ea1b7de820c558f898f3ad47015a/profiler/src/profiler/TracyMicroArchitecture.cpp

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

Gnome and window decorations, again.

https://factorio.com/blog/post/fff-408

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

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.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

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.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

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.)

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

A super useful thing in VS Code: you can ctrl-click on a name and go to the definition, even if the name is in a comment.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

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.

Is there any kind of process to this at all?

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

Fedora libraries built without frame pointer omission are a thing of beauty.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar
wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

PNG load times in etcpak, using different variants of zlib.

In 1.2.11, I had the CRC calculation patched out and used the manual assembly files that you had to somehow include in the build process.

In 1.3.1, support for assembler code was removed because "there is not sufficient gain from the inflate assembler code to warrant its inclusion." (https://github.com/madler/zlib/commit/288f1080317b954b6bdca33708631c011549c008)

Finally, I use zlib-ng as a drop-in replacement for zlib. I just need to compile it with the ZLIB_COMPAT CMake option enabled.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

Here's some interesting data about how long Vulkan takes to initialize.

WSL:
VkInstance: 42 ms
VkDevice: 13 ms (llvmpipe)

Dell XPS laptop:
VkInstance: 61 ms
VkDevice: 2.9 ms (Intel Xe), 9 ms (llvmpipe)

Some Asus laptop:
VkInstance: 1.84 s (!)
VkDevice: 38 ms (Nvidia), 5 ms (Radeon), 26 ms (llvmpipe)

Well, there is no point in parallelizing this.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

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?

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

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?

What are your opinions?

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

The Polish trains DRM talk has been released.

https://media.ccc.de/v/37c3-12142-breaking_drm_in_polish_trains

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar
wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

I'm looking for solutions to problems with Meson, and fuck, this is so miserable and soul draining.

Let's say you have Android NDK or vcpkg or whatever installed somewhere on the system. One user will have it in C:, another in Z:\dev, and someone else in /home/user/sdks/, or I don't know, /opt/ or /usr/local/. It doesn't matter.

What everyone does is set up an env variable pointing to the SDK dir that can be picked up by the build system, and everything works no matter what setup you prefer.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

https://twitter.com/LinusEkenstam/status/1727357730833530954

"should not be possible"

Hahaha, and on Wayland it is not possible, because clients must not have knowledge of where their windows are on the screen.

Sigh.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

Wayland is a gift that keeps on giving.

When you create a wl_surface, it won't be active or visible until you attach a wl_buffer to it. And when you want to hide the window, sorry, the surface, you just attach a null buffer to it and it's gone.

If you are rendering with Vulkan, you call vkCreateWaylandSurfaceKHR() and tell it which surface you want to draw on. It will automatically attach a buffer to the surface when you make the present call.

Pretty simple, right?

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

So I enabled Actions for one of my private mirrors of GitHub repos, and it resulted in both forges literally racing to finish the CI build process first. It was interesting to watch.

The GitHub runners are more or less random and not that fast. They finished in 1:57, 1:28 and 2:13. Identical code on all runs.

My cloud rental 2-core 3900X does the compilation job in 2:12.

My i7-1165G7 laptop does it in half a minute.

My 7950X desktop finishes in 8 seconds.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

I released Tracy Profiler 0.10.

It's not as big as the other major number releases in the past, but it still has some important improvements in it, and it's been cooking long enough to make it a pretty stable release.

https://github.com/wolfpld/tracy/releases/tag/v0.10

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

It's hard to remember how much screen space was taken up by useless stuff in early browsers.

The screenshot is more or less 640x480, which by 2000 was obsoleted by the ginormous 800x600 screen resolution.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

Remember that you can convert your JPEG files to JPEG XL with no loss of quality and you will save a lot of space. In theory, it should be possible to revert back to JPEG and have the same file, bit for bit, should you have the need.

A sample set of 203 photos from 2007:

JPEG: 654 MB
JPEG XL: 532 MB

JPEG dates back to 1992 and was the hot new thing on your Amiga. Why do you still use it?

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

About a decade ago, I was looking for some kind of CI solution that I could run on the ARM devboard I had running as a server at home.

Jenkins and TeamCity were out of the question due to the amount of resources they required to even get started. I tried, but after an hour of constant swapping and not even seeing a splash screen, I got bored.

It felt completely absurd to me, as the CI system I needed was supposed to just monitor the git repo and run a shell script to do the build.

wolfpld, to random
@wolfpld@mastodon.gamedev.place avatar

A propos Firefox vs. Chrome. Some time ago, I largely stopped trying to open any web pages on my phone because the Chrome experience of unfiltered web was intolerably painful. Then I installed Firefox with uBlock and things became manageable.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • khanakhh
  • kavyap
  • thenastyranch
  • everett
  • tacticalgear
  • rosin
  • Durango
  • DreamBathrooms
  • mdbf
  • magazineikmin
  • InstantRegret
  • Youngstown
  • slotface
  • megavids
  • ethstaker
  • ngwrru68w68
  • cisconetworking
  • modclub
  • tester
  • osvaldo12
  • cubers
  • GTA5RPClips
  • normalnudes
  • Leos
  • provamag3
  • anitta
  • lostlight
  • All magazines