| 11 Dec 2025 |
 K900 | * Holy shit EXT_present_timing is real | 11:11:04 |
| K900 | We can have actually good anti-lag now | 11:12:27 |
| K900 | And probably actually good frame interpolation too | 11:12:35 |
| K900 | As much as frame interpolation can be good anyway | 11:12:41 |
 Marie | what is anti-lag actually | 11:18:04 |
| K900 | Basically it's a way for the driver to track the amount of time rendering a frame actually takes | 11:20:00 |
| K900 | And then tell the application to only start rendering when it's almost time | 11:20:13 |
| K900 | So if you have decoupled simulation and render, which you should be doing anyway, you render the most up to date state you have | 11:20:40 |
 magic_rb | Nice nice, time to make my haskell game engine decouple simulation and rendering ig :P ive been eyeing that challenge for a bit, seems like a fun programming task | 11:21:34 |
| K900 | It's a cute idea, the downside is mostly that on non-VRR displays you can sometimes drop a full frame | 11:23:00 |
| K900 | If you miss the deadline | 11:23:06 |
| K900 | And obviously the more frames you're pushing, the less impact there is to anti-lag | 11:25:36 |
| magic_rb | I mean in my case it would be nice to run the simulation at 20tps but run the renderer at 60fps | 12:09:19 |
| magic_rb | Then add interpolation and bam | 12:09:23 |
| magic_rb | Currently everything runs at 60 which for a bg3 like game is unnecessary | 12:09:56 |
|  suua joined the room. | 16:12:45 |
 Atemu | I had this odd idea w.r.t. the driver glibc incompat just now that I want to bounce off this room to see whether it's stupid:
Couldn't we simply remove the glibc it was built against from the rpath and assume whoever loads it will bring their own libc?
| 17:16:01 |
| K900 | No | 17:17:33 |
| Atemu | And then build against (but not dynamically link against) some ancient glibc to be compatible with basically anything? | 17:17:43 |
| K900 | Not enough | 17:17:56 |
| K900 | You also need libstdcpp, llvm, etc | 17:18:02 |
| Atemu | mhh | 17:18:26 |
| Atemu | but LLVM usually isn't provided by the program, right? | 17:18:52 |
| Atemu | Only by the driver | 17:19:06 |
| Atemu | I suspected that might be the answer but I'm interested in why :) | 17:19:43 |
| K900 | Because it's got a bunch of other dependencies that will also expect modern libc | 17:21:55 |
| K900 | Unless you build the entire closure of Mesa against an old libc | 17:22:04 |
| K900 | And then it'll probably explode when it tries to touch any global state wrong | 17:22:13 |
| Atemu | Ah, yeah indeed | 17:22:30 |
| Atemu | I'd kinda assumed mesa to not have many runtime deps; is that not the case? | 17:23:18 |
