u/datenwolf

No, on modern systems with contemporary graphics stacks it's not more expensive. These days retained mode UI toolkits will redraw the whole thing for every update. The moment you introduce antialiased graphics primitives, it's usually a lot easier (both in terms of code and computational complexity) to just redraw things, instead of fiddling with graphics bit operations.

Think about it this way: If your "worst case", is the nominal case, for example redrawing a very complex spread sheet with a lot of minutiae in each cell full of non-repeating CJK glyphs in response to resizing the window or scrolling, and you can do it comfortably in under 5ms, then you're not going to improve upon that, if you've to do the manual sync between model and view (which is essentially a form of manual cache in/validation, i.e. a hard problem).

Mouse-over hover still works to reveal the contents.

The OG X11 cursors are actually contained in a font, the font itself being named "cursor-misc". The current URL for the source repo is https://gitlab.freedesktop.org/xorg/font/cursor-misc

Just use volk; it takes care of all the annoying stuff, including your problem.

<rant>A decade ago, when Vulkan was proposed, one of the stated goals was, that applications could just ship their own loader, even statically link to it, so that they could be sure, they had all they required. And now, some 10 years lader, we're back to fully dynamic loaders scavanger hunting through system paths. I guess there's something to learn from this.</rant>

i don't want to write programs as much as i want to understand whats going on under the hood.

The best way to learn these things is to write small, exploratory programs, each focusing on a single concept. At some point, some elbow grease is required.

First things first: Trying to understand a system from the foundations upward is the right path. So I applaud you going this way.

The way how to really, really, really learn how everything fits together is working out every piece of the puzzle for yourself. Of course as with every complex system you need a starting point. So a good way to go about this is to take each and every function called by a program, and follow down the path of what it does until you hit the "wall" of reaching the set of system level, fundamental function that make the higher level stuff work.

So for example when you use GLFW, what does glfwCreateWindow do? Well, at some point it's going to reach one of the system level functions. On Windows CreateWindowEx on X11 xcb_create_window/XCreateWindow and so on. But then you've got only the Window. How to do things with it?

Next step: Ditch the tutorials and programming guide and go straight for the system level API reference documentation. Try to get a well rounded grasp of the kind of system functions there are, what parameters they take, and what other functions they interact with. Then write a lot of small simple experimentation programs to see what works, and what not.

If the book is about OpenGL version 4.3 then those functions better are not mentioned. They've been obsolete since OpenGL-3.

Also that archive of code samples is seriously outdated, and personally I think also follow a lot of bad practices (like setting the viewport in the window resize handler, where it absolutely does not belong). Also they use GLUT which hasn't been maintained for over 20 years. There's FreeGLUT, which is actively maintained, but you really shouldn't use that; use GLFW instead.

No, just Git; its homepage is https://git-scm.org – Github is a repository service that was built around Git, but neither did they invent it, was any of Git's core developers employed by them.

Well, and I guess the Unicode shenanigans in my user flair also may be a part of the reason.

Which makes sense, since HDMI uses the horizontal blanking interval for audio transmission, which may require to make the H-blank a tiny bit longer than would be required for pure video at the same resolution. Pixel clock rates are selected from a tight grid, so line frequency might be lowered a tiny bit to make room, thereby leading to fractionally longer vertical refresh interval.

DisplayPort is packet based and just packs audio into a separate packet stream.

The DirectX structure describing a monitor mode uses a rational for the refresh rate: https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_2/ns-dxgi1_2-dxgi_mode_desc1

typedef struct DXGI_MODE_DESC1 {
  UINT                     Width;
  UINT                     Height;
  DXGI_RATIONAL            RefreshRate;
  DXGI_FORMAT              Format;
  DXGI_MODE_SCANLINE_ORDER ScanlineOrdering;
  DXGI_MODE_SCALING        Scaling;
  BOOL                     Stereo;
} DXGI_MODE_DESC1;

Depending on the capabilities of the monitor, between its set of supported pixel clocks, the requirements it reports on the horizontal blanking interval, which is still a thing in digital video, and in fact is where audio is transmitted (if audio is sent to the display) and the permissible frequency ranges for vertical refresh, that rational number may come out being not wholly divisible.

When populating the selection box, the game simply iterates over all the mode descriptors, building the string with a function equivalent to sprintf(buf, "%.2f", (double)mode.RefreshRate.Numerator / (double)mode.RefreshRate.Denominator); if the result of that division deviates from a "whole" number only after the 4th decimal, it will round to xx.00; if it doesn't, you're going to see those wonky numbers.

Packhounds require a target to lock on. Since not many things on the ground can be targeted, you need to bring your own target, like a limpet: There's one kind of limpet that will just fly away into the direction you launch it, namely the prospector limpet (which you normally use in mining).

You can see how it looks from the ground in that live open play stream of Frontier: https://www.youtube.com/live/b0wNSPtQQ6k?si=TpZFgwG6Gfxc04hN&t=4220 – at 1:10:20 you can see me (in the Gunship) launching the limpet to target lock onto, 5 seconds later you can see the packhound barrage hitting the ground.

And I thought my little trick using prospector limpets to paint a target for packhounds* was cute.

• works a lot better in legacy though, with about 95% ammo efficiency; in Odyssey you get only about 50% of the missiles to spread out after they passed the limpet.

Actually I was visiting San Francisco for a conference. But thanks to your lovely videos I knew where to go to find super friendly ravens. So I put going to Ocean Beach with a bag of cashews and blueberries on the very top of my todo list.

You can just run the event loop at the side and send a notification flag to the state machine. Heck, it's how a lot of my LabVIEW programs deal with it.

Watching that video my reaction was exclaiming loudly

cool… sehr, sehr cool!

Really impressive.

GLFW and GLEW are libraries with orthogonal functionality:

• GLFW: Sets up windows and created OpenGL contexts

• GLEW: Loads function pointers to all functions that go beyond what's exposed according to the operating systems base ABI (application binary interface) requirements. On Windows that's everything after OpenGL-1.1 on Linux (as specified by the LSB Desktop profile) it's everything beyond OpenGL-1.2. glClear was present already in OpenGL-1.0 so no function loading is required for that.

For all functions that are part of the base ABI you can just use them, without giving them extra thought. Now, the way these function calls are dispatched to the actual driver are gnarly and a many blog posts by driver developers have been written about it in frustration.

On Windows it basically it boils down that everything must go through the entry points exposed by opengl32.dll and that for extension and later version functions each driver is allowed to expose separate function pointers tied specifically to each context for the same entry point, which means that you have to manage those function pointers per context; that's what GLEW does for you

If OpenGL is accessed through GLX on the other hand, there's the requirement that all drivers must expose the same entry point through the same function pointer. Which means that somewhere between the driver and application you have some dispatch logic. And on systems with multiple GPUs using different drivers this can lead to – err – problems. So we eventually got glvnd (GL vendor neutral dispatch), a now quasi-standard (but not specified in the LSB nor SuS) library that keeps track which driver you intend to talk to (through tracking …MakeCurrent calls on each thread) and then dispatches into the respective libGL.so of that driver. Yeah, it's blue tack and duck tape. But also the only way to get some sanity on EGL on *nix, because unlike with GLX the specification of EGL left that part open.

How does GLEW know which context to use?

It hooks …MakeCurrent to set a thread-local variable (or, if it can't hook …MakeCurrent for whatever reason, it will query which context is active on the thread using …GetCurrentContext)¹

Additionally, if two OpenGL applications run simultaneously, how does the graphics driver isolate their contexts and ensure commands don’t interfere?

Basically it boils down to a separate copy of the driver's management structures living in each process' address space coordinating their operations through the kernel side part of the driver. Interesting enough the kernel side of the drivers got simpler and less responsibilities the more capable GPUs became; some 25 years ago you had only a handful of texture unit registers which had to be shared between processes and the kernel driver had to store and restore them when switching processes – these days GPUs access textures through bindless descriptors, stored somewhere in VRAM and there's no need for managing process state.

Finally, when using commands like glClearColor or glBindBuffer, are these tied to a single global OpenGL object, or does each context maintain its own state?

From the abstract OpenGL view they're controlled by per-context state, but might affect storage shared between contexts (textures, framebuffers, etc). Furthermore you can have multiple contexts (across multiple threads) bound to the same drawable (window, pbuffer), and more importantly that binding is not "hard", i.e. you can make a single context current on different windows (in succession) as long as their pixelformats are compatible with each other.

¹: for brevity I only wrote the "core" name of the functions. They're named with a different prefix for each operating system and environment, and also exist in modernized variants.

Welcome to the Buffer Zoo

Yesterday I was hopping around systems to triangulate Cocijo's trajectory and concluded that it actually might be closer to Sirius when the server tics, than Sol.

• General AX: KraitMk2 – Soft Kitty, Warm Kitty

• Spire Site Orthrus Hunting: F.Gunship – Xenophobic Honeybadger

• Titan Bomber: Orca – Xeno Eating Oreo

• Titan Bomber: PythonMk2 – Lonestar's Jam Thrower

System chat is shared between open, private group and solo. In other word's: There's no hiding from it.

300 m² = 300 · (m²)

exponentials on a unit do not extend to the numeric value they're attached to. Please don't make me look up the NIST and ISO manuals explaining that.

but it may be the best thing for the company if they're aiming at the AI market rather than PC games.

That hinges on the assumption, that the current approach to AI doesn't turn out to be a bust. Sure, I'm still kicking my ass for not buying Nvidia stock 3 years ago. But OTOH, as a developer, in my field, I simply don't know what to do with all those AI cores. I'm doing high throughput, low latency signal processing. And while it's certainly possible to shoehorn that into AI cores, they perform worse – a lot worse – in that regard, than plain old compute and shaders.

Heck, I also need somewhat decent floating point precision. FP24 (7 bit exponent, 16 bit mantissa) would hit the sweet spot numerically, but sucks in its unaligned memory access patter. FP32 has numerical reserves and performs well. FP16 works out to be numerically well just enough for applications in which DR and SNR are "well balanced" but the perf gain is much appreciated. Anything below FP16 is totally useless for my application though.

And given the fact, that the end result of all this DSP are pictures, using a GPU that can actually send a video signal to a display is kind "important". Gaming GPUs are what perform best for what I do professionally.

I don't like news like these, because it means additional work to work around absolutely uncalled for and unnecessary obstacles. grrrrr

Change the line that invokes

udevadm settle

to

udevadm settle -t <TIMEOUT_IN_SECONDS>

I usually go with 5 seconds, which should be enough for most hardware, these days (unless you got some old external spinny rust drives connected via USB, which take half a minute to wake and spin up from sleep).

Hence my /etc/runit/core-services/02-udev.sh looks like this

# vim: set ts=4 sw=4 et:

[ -n "$VIRTUALIZATION" ] && return 0

if [ -x /usr/lib/systemd/systemd-udevd ]; then
    _udevd=/usr/lib/systemd/systemd-udevd
elif [ -x /sbin/udevd -o -x /bin/udevd ]; then
    _udevd=udevd
else
    msg_warn "cannot find udevd!"
fi

if [ -n "${_udevd}" ]; then
    msg "Starting udev and waiting for devices to settle..."
    ${_udevd} --daemon
    udevadm trigger --action=add --type=subsystems
    udevadm trigger --action=add --type=devices
    udevadm settle -t 5
fi