21 Oct 2024 |
Sami Liedes | I just remember years ago looking with horror at some steam shell scripts (it's probably just me, I've grown a strong dislike towards shell scripting). And a few days after that I read that there was some bug in the steam shell scripts that executed rm -rf / . | 06:51:29 |
Atemu | Do you mean this beauty? https://github.com/sonic2kk/steamtinkerlaunch/blob/master/steamtinkerlaunch | 06:52:21 |
Atemu | Why, would you not want to write a GUI steam compat tool interceptor in 27k lines of bash? | 06:52:56 |
Sami Liedes | No, I think that looks worse. I didn't get that deep. | 06:52:58 |
Atemu | Updated my write-up on a potential new hardware accel driver API in a new issue https://github.com/NixOS/nixpkgs/issues/350162 | 07:00:04 |
K900 | Do you also want to get the loader config changes in there? | 07:03:17 |
Atemu | WDYM by loader config changes? | 07:04:28 |
K900 | Like moving Vulkan drivers out of /run/opengl-drivers | 07:07:13 |
K900 | And such | 07:07:14 |
K900 | Because that's something I also want to look into because with Mesa 24.3 we can actually use host drivers sometimes | 07:07:31 |
Atemu | I think that should come after the NixOS options are redesigned | 07:07:41 |
K900 | So it would be nice to update all the loaders to also look in FHS-brained paths | 07:07:44 |
Atemu | Though if there are any constraints to be aware of here, we can let that influence the design | 07:08:00 |
Atemu | Like, the change is rather independent if you ask me | 07:09:08 |
Atemu | One can happen without the other | 07:09:14 |
netbrain | hm the pressure vessel solution from steam is pretty interesting, especially the part where they yoink graphics drivers from the host system to the container. | 07:09:35 |
Atemu | But it'd be better to have the new NixOS options to perhaps have an even better design for the driver path change which is IMHO more significant | 07:09:39 |
l0b0 | daggerfall-unity: init at 1.1.1 | 08:40:19 |
Sami Liedes | In reply to @atemu12:matrix.org Updated my write-up on a potential new hardware accel driver API in a new issue https://github.com/NixOS/nixpkgs/issues/350162 Terminology point: With "hardware-accelerated compute" I immediately wondered if you mean only things like CUDA or also graphics. I think Nvidia's usage of "compute" muddles things here; I think it means only non-graphics. Not sure what better terminology would be. GPU API? | 08:50:30 |
K900 | venc/vdec is also definitely not compute tbh | 08:55:39 |
Sami Liedes | I do more CUDA than graphics; I've also mused a bit on the pain of having to rebuild a lot of stuff after setting some cuda option. And the interesting dilemma that if I set my compute architectures, building will be much faster but there will be much less cached content. Not sure there's a solution to that either... I read a bit on if it would be even theoretically possible to split things into a "base package" and then separate compute architecture packages, but I think it looks dim.
I feel there's a monad lurking here. Compute monad, or building-with-compute monad. | 08:56:01 |
Sami Liedes | It might work if all the builds were declarative instead of shelling to, well, shell or cmake or something. | 08:57:32 |
Atemu | In reply to @k900:0upti.me venc/vdec is also definitely not compute tbh Why not? Data in, computed data out. | 08:57:42 |
K900 | It's not computing though | 08:57:54 |
K900 | At least not in the typical definition of the word | 08:58:02 |
K900 | That's all fixed function | 08:58:06 |
Sami Liedes | Maybe there's also the point that if we define compute very widely, it's not a very useful term because everything in NixOS is compute :) | 08:58:31 |
K900 | In reply to@sliedes:hacklab.fi I do more CUDA than graphics; I've also mused a bit on the pain of having to rebuild a lot of stuff after setting some cuda option. And the interesting dilemma that if I set my compute architectures, building will be much faster but there will be much less cached content. Not sure there's a solution to that either... I read a bit on if it would be even theoretically possible to split things into a "base package" and then separate compute architecture packages, but I think it looks dim.
I feel there's a monad lurking here. Compute monad, or building-with-compute monad. Honestly we should just ship unfreeRedistributable on Hydra | 08:58:46 |
K900 | And not have this problem | 08:58:48 |
K900 | But hurr durr | 08:58:52 |