| Time |
Nick |
Message |
| 00:00 |
ireallyhateirc |
luatic, no one is expecting anything, but free/libre firmware is better than black box proprietary firmware that could be running backdoors |
| 00:01 |
ireallyhateirc |
backdoors aside, planned obsolescence is probably the main use case |
| 00:02 |
ireallyhateirc |
so it makes sense for Pinephone to use chips that has free/libre firmware, possibly at the price of performance |
| 00:03 |
MTDiscord |
<luatic> that is too great a price if you ask me. it seems obvious to me that manufacturers don't want to open source the trade secrets that make their firmware go vroom. |
| 00:03 |
MTDiscord |
<_devsh_> Ironically the M1 GPU with Asahi Linux has open source firmware XD |
| 00:03 |
ireallyhateirc |
yeah, the same person who did Panfrost reverse engineered Apple's thing |
| 00:04 |
MTDiscord |
<_devsh_> Yes it runs pretty fast too |
| 00:04 |
MTDiscord |
<luatic> i wouldn't worry too much about backdoors in the GPU firmware. obviously you have to trust your hardware manufacturers. |
| 00:04 |
MTDiscord |
<_devsh_> Hehehe |
| 00:05 |
MTDiscord |
<_devsh_> I'd worry about the bugs in your unmaintained drivers! |
| 00:05 |
ireallyhateirc |
well it's perfect world vs techno dystopia and running whatever you can play Luanti on |
| 00:06 |
MTDiscord |
<_devsh_> Shit driver Devs do planned obsolescence just fine |
| 00:06 |
MTDiscord |
<luatic> ancient hardware seems dystopian to me. you've swapped planned obsolescence for buying already long obsolete things. what a great solution. |
| 00:07 |
MTDiscord |
<_devsh_> The pinephone people in HK are making a killing on paranoid bearded gnu guys willing to pay top dolar for 10 year old GPUs |
| 00:08 |
MTDiscord |
<_devsh_> They are serving a niche |
| 00:08 |
ireallyhateirc |
obviously buying 16 years old librebooted Stinkpads is not the solution to the problem, but a dead end. This comes from an owner of a 16 librebooted Stinkpad. |
| 00:09 |
ireallyhateirc |
the solution would be to buy devices from companies that make open hardware, but there are few |
| 00:10 |
MTDiscord |
<_devsh_> Capitalism at its best, nothing gets wasted, if there no demand create demand for 65 nm lithography |
| 00:11 |
|
SFENCE joined #minetest |
| 00:12 |
MTDiscord |
<_devsh_> TBF if you're holding up the whole train, won't take HW donations, then maybe you should learn the secrets of GL 2.1 and maintain/extend the renderer |
| 00:15 |
ireallyhateirc |
ooh the website changed "Luanti (formerly Minetest)" |
| 00:16 |
MTDiscord |
<_devsh_> https://www.theregister.com/2024/04/05/amd_mes_open_source/ |
| 00:19 |
MTDiscord |
<_devsh_> Would it be kosher for the libre minded person to connect an eGPU and use that for gaming? Or do you see a potential for backdoors if all you're doing is quemu + pcie passthrough |
| 00:20 |
[ |
Are there any eGPUs that'd work without proprietary init code (VGA option ROM) or proprietary firmware? |
| 00:22 |
specing |
<_devsh_> Ironically the M1 GPU with Asahi Linux has open source firmware X |
| 00:22 |
specing |
[citation needed] |
| 00:22 |
specing |
afaik Asahi linux installer extracts firmware from existing OS |
| 00:23 |
[ |
There's a vulnerability in MEv11 (used in kaby lake) that allows for code execution in the ME and bypassing bootguard. I think the solution is to wait for someone to write a free ME replacement (that does enough to boot the system, not all of the unnecessary security risk backdoor-y stuff) and reverse-engineer the FSP (it does basically the same thing as the MRC on broadwell and earlier, and |
| 00:23 |
[ |
that's already been reverse-engineered) |
| 00:23 |
[ |
Executing unsigned microcode is apparently also possible on kabylake, so free microcode could be written too |
| 00:23 |
MTDiscord |
<_devsh_> Waaait |
| 00:24 |
MTDiscord |
<_devsh_> You want libre microcode on CPU? |
| 00:24 |
MTDiscord |
<_devsh_> Nice didn't know |
| 00:26 |
ireallyhateirc |
I just made a cool necklace for my a character for my WIP luanti game, now waiting for someone to add support for metalic materials |
| 00:27 |
[ |
but until that's done the choice is either neutered ME and nonfree microcode updates on haswell, or nonfree firmware and init code with a newer eGPU/dGPU (or possibly RK3399 which has worse single core performance then the core 2 duos in those old thinkpads and only supports 4GB RAM) |
| 00:28 |
MTDiscord |
<_devsh_> Ekhm ekhm cubemaps needed |
| 00:28 |
MTDiscord |
<greenxenith> Yes |
| 00:28 |
MTDiscord |
<greenxenith> That is on my todo list after jam stuff |
| 00:28 |
MTDiscord |
<_devsh_> Haswell GPUs actually support gles 3.0 |
| 00:29 |
ireallyhateirc |
greenxenith, cubemaps or metalic materials? |
| 00:29 |
MTDiscord |
<greenxenith> Technically both |
| 00:29 |
MTDiscord |
<_devsh_> Seamless cubemap filtering is like GL 3.something / dx10 feature |
| 00:29 |
|
SFENCE joined #minetest |
| 00:29 |
specing |
Libre microcode could have cool use cases |
| 00:29 |
MTDiscord |
<greenxenith> Cubemaps are part of supporting metallic which is part of supporting a material workflow |
| 00:30 |
MTDiscord |
<_devsh_> Also one more rip about doing that in irrlicht |
| 00:30 |
specing |
like.. imagine program-specific instructions |
| 00:30 |
MTDiscord |
<_devsh_> Tring to support anything other than texture2d is naaasty |
| 00:31 |
MTDiscord |
<luatic> one nastiness at a time |
| 00:31 |
MTDiscord |
<_devsh_> If you at least had renderdoc you'd be able to find the fucking thing and at least verify it uploaded correctly |
| 00:32 |
MTDiscord |
<_devsh_> As opposed to "black mesh, why?" |
| 00:32 |
MTDiscord |
<_devsh_> Or "why am I seeing some other random texture?* |
| 00:32 |
MTDiscord |
<greenxenith> making SSR reflections without texture3d was annoying |
| 00:32 |
ireallyhateirc |
both, that's great |
| 00:32 |
MTDiscord |
<_devsh_> What on earth do you need tezture3d for? |
| 00:32 |
MTDiscord |
<greenxenith> Nothing technically |
| 00:33 |
ireallyhateirc |
I really like when devs work on stuff that I find useful/interesting :P |
| 00:33 |
MTDiscord |
<greenxenith> but our pipeline is maxing out simultaneous textures |
| 00:33 |
MTDiscord |
<_devsh_> Yes 16 max |
| 00:33 |
MTDiscord |
<_devsh_> Oh god no |
| 00:33 |
MTDiscord |
<greenxenith> I think its less than that |
| 00:33 |
MTDiscord |
<_devsh_> Use texture2d array instead |
| 00:33 |
MTDiscord |
<greenxenith> ok yeah thats what I meant |
| 00:34 |
MTDiscord |
<greenxenith> (arguably an array of texture2d is 3d) |
| 00:34 |
MTDiscord |
<_devsh_> Ok you're giving me ptsd |
| 00:34 |
MTDiscord |
<greenxenith> Happens |
| 00:34 |
MTDiscord |
<_devsh_> @luatic this is what I meant by piling up tech debt |
| 00:34 |
MTDiscord |
<greenxenith> I dont disagree that its all awful |
| 00:34 |
MTDiscord |
<_devsh_> You do weird shit to do simple stuff |
| 00:34 |
MTDiscord |
<_devsh_> Just digging a hole, deeper and deeper |
| 00:35 |
MTDiscord |
<greenxenith> Hey, people wanted to rush SSR into the engine and I am trying to pull back because I dont want to dig the hole deeper. Id rather find the right way to implement generic materials rather than full send my janky hyper-specific implementation |
| 00:36 |
MTDiscord |
<_devsh_> It's the data packing in weird things that you have to do simply because of some weird preset slots |
| 00:36 |
MTDiscord |
<luatic> yeah i know |
| 00:36 |
MTDiscord |
<luatic> (re piling up tech debt) |
| 00:36 |
MTDiscord |
<luatic> i've got a plan but no time |
| 00:36 |
MTDiscord |
<luatic> or at least not enough time |
| 00:38 |
MTDiscord |
<luatic> my current effort of reducing tech debt and fixing a couple bugs in the process is #15354 |
| 00:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/15354 -- Fix skeletal animations and attachments once and for all by appgurueu |
| 00:38 |
MTDiscord |
<luatic> well, i've got a couple other even more WIP things too but those aren't in a presentable state |
| 00:39 |
MTDiscord |
<greenxenith> And now we are piling on new fancy effects onto our debt-machine pipeline without enough game control (no disrespect to Gefullte, the work looks nice) |
| 00:39 |
MTDiscord |
<luatic> btw pro tip do ü -> ue if you can't type ü, it will still read correctly |
| 00:41 |
MTDiscord |
<_devsh_> Looking at the PR |
| 00:41 |
MTDiscord |
<_devsh_> I don't actually see you pump the bones/joints to the shader |
| 00:41 |
MTDiscord |
<_devsh_> What's the plan for that? |
| 00:41 |
MTDiscord |
<luatic> read the description, this is just preparatory work for that |
| 00:42 |
MTDiscord |
<luatic> devsh: my plan for that is to send the bone transforms to the vertex shader via an UBO |
| 00:42 |
MTDiscord |
<luatic> along with the weights |
| 00:42 |
MTDiscord |
<_devsh_> Good direction buuut |
| 00:42 |
MTDiscord |
<_devsh_> Weights are just an extra vertex attribute |
| 00:43 |
MTDiscord |
<luatic> yeah |
| 00:43 |
MTDiscord |
<luatic> i don't want to compute the transforms on the shader yet, that doesn't fit well into our current pipeline |
| 00:43 |
MTDiscord |
<_devsh_> Ooof, irrlicht never finished that flex vertex format thing |
| 00:43 |
MTDiscord |
<luatic> and i expect the skinning to dominate anyways so we should see good gains by just doing that on the shader for starters |
| 00:43 |
MTDiscord |
<_devsh_> That was one of the things that gave us perf boosts |
| 00:44 |
MTDiscord |
<_devsh_> Why would you store a block position as a float32? |
| 00:44 |
MTDiscord |
<_devsh_> Having uint vertex format was awesome |
| 00:45 |
MTDiscord |
<_devsh_> What does Uniform in Uniform Buffer Object stand for? |
| 00:46 |
MTDiscord |
<luatic> uniform as in shader uniform variables? |
| 00:46 |
MTDiscord |
<_devsh_> You're not supposed to index an array in a UBO with non uniform index, it will work, and on Latest GPUs it will work just fine |
| 00:46 |
MTDiscord |
<_devsh_> But the older ones (dx10 class) will experience constant waterfalling |
| 00:47 |
MTDiscord |
<luatic> so what can i do? |
| 00:47 |
MTDiscord |
<luatic> I think GPU skinning just for 90% of the userbase is fine, the rest can have CPU skinning as a fallback |
| 00:48 |
MTDiscord |
<_devsh_> https://www.khronos.org/opengl/wiki/Core_Language_(GLSL)#Dynamically_uniform_expression |
| 00:48 |
MTDiscord |
<_devsh_> Son you don't have the dev budget time or energy for two codepaths |
| 00:48 |
MTDiscord |
<_devsh_> SamplerBuffer |
| 00:49 |
MTDiscord |
<luatic> are you |
| 00:49 |
MTDiscord |
<_devsh_> Aka Buffer Texture |
| 00:49 |
MTDiscord |
<luatic> are you saying i should stuff my matrices into samplers |
| 00:49 |
MTDiscord |
<_devsh_> No they're not images |
| 00:49 |
MTDiscord |
<_devsh_> They're funny buffers |
| 00:50 |
MTDiscord |
<luatic> this thing: https://www.khronos.org/opengl/wiki/Buffer_Texture ? |
| 00:50 |
MTDiscord |
<_devsh_> Yes |
| 00:50 |
MTDiscord |
<_devsh_> Also known as a Buffer View in Vulkan |
| 00:50 |
MTDiscord |
<luatic> oh |
| 00:51 |
MTDiscord |
<_devsh_> You're guaranteed they can be at least 128MB in size |
| 00:51 |
MTDiscord |
<_devsh_> Btw gl doesn't have texture views until gles 3.1 / GL 4.1 |
| 00:52 |
MTDiscord |
<_devsh_> Which are super useful |
| 00:52 |
MTDiscord |
<_devsh_> Because you can view one buffer or image with multiple formats |
| 00:53 |
|
cation joined #minetest |
| 00:54 |
MTDiscord |
<_devsh_> Hmm I think buffer views could be aluased even in old gl |
| 00:54 |
MTDiscord |
<_devsh_> https://registry.khronos.org/OpenGL-Refpages/gl4/html/glTexBuffer.xhtml |
| 00:54 |
MTDiscord |
<_devsh_> Anyway the trick is to have multiple of those, and write yourself and allocator over them |
| 00:55 |
|
CRISPR joined #minetest |
| 00:55 |
MTDiscord |
<_devsh_> Then shove all your persistent data into them, e.g. block and mesh vertices |
| 00:55 |
MTDiscord |
<_devsh_> Then you can kinda do programmable pulling and the whole doom eternal batching thing |
| 00:56 |
MTDiscord |
<_devsh_> Anyway |
| 00:56 |
MTDiscord |
<_devsh_> As for the bone data |
| 00:57 |
MTDiscord |
<_devsh_> Because gles and GL <4 doesn't have persistent mapping |
| 00:57 |
MTDiscord |
<_devsh_> And neither does webgpu |
| 00:58 |
MTDiscord |
<_devsh_> It's best you re-create a 32, 128 or whatever mb buffer each frame (buffer orphaning) and fill it up with a linear allocator |
| 00:58 |
MTDiscord |
<_devsh_> Then throw it away, there's an article in OpenGL 4.3 or 4.1 inaights about best way to stream such data |
| 00:59 |
MTDiscord |
<_devsh_> *insights |
| 00:59 |
MTDiscord |
<_devsh_> It's either a gen-delete loop or respecify with glBufferData |
| 00:59 |
MTDiscord |
<_devsh_> glBufferSubData not good for large streaming like this |
| 01:00 |
MTDiscord |
<_devsh_> Slap everything into it, bones and ubo/uniforms |
| 01:01 |
MTDiscord |
<_devsh_> Then as you draw, you'll bind the UBO at different offsets or if fetching from the Buffer Texture pass an offset through one single glUniform1u |
| 01:01 |
MTDiscord |
<_devsh_> By this I mean slap into a vector<uint8_t> you really don't want to be doing tiny updates ona buffer |
| 01:02 |
MTDiscord |
<_devsh_> The idea is, cull, memcpy all the draw uniforms/prams, then sort shader+texture+ubo_offset drawcall records, then do drawcalls |
| 01:03 |
MTDiscord |
<luatic> I gotta go to bed now. Thank you for all your eye-opening insights today (this may sound over the top, but I mean it seriously). I feel like Irrlicht has numbed me now. |
| 01:03 |
MTDiscord |
<_devsh_> It's a common pattern |
| 01:03 |
MTDiscord |
<_devsh_> Dota draws like this |
| 01:03 |
MTDiscord |
<_devsh_> No fancy instancing |
| 01:03 |
MTDiscord |
<_devsh_> Big UBO per frame |
| 01:04 |
MTDiscord |
<_devsh_> Btw UBO is limited to 64kb even on rtx 4099 |
| 01:04 |
MTDiscord |
<_devsh_> Which is why texture buffer (UTB) makes more sense cause most GPUs report 128mb |
| 01:05 |
MTDiscord |
<_devsh_> Obviously SSBO is best because everything but pre-skylake intel reports min(vram size, 2GB) |
| 01:06 |
MTDiscord |
<_devsh_> And in vulkan we have BDA, which is just a 64bit GPU pointer |
| 01:06 |
MTDiscord |
<_devsh_> https://cdn.discordapp.com/attachments/369137254641303560/1305311453661888654/image0.jpg?ex=67329186&is=67314006&hm=cfc1241a67eda6608e21a1fb01636f9862131bedc28e806fc3395be766f8023d& |
| 01:07 |
MTDiscord |
<_devsh_> Dual boot or set up pcie passthrough ina VM and come and see how the big boys play |
| 01:09 |
MTDiscord |
<_devsh_> Finał Word, you shouldn't use more than 128 bytes of uniforms or driver will hate you |
| 01:09 |
MTDiscord |
<_devsh_> Like the glUniform ones |
| 01:09 |
MTDiscord |
<_devsh_> They're stored in registers, and past a certain point they'll spill |
| 01:10 |
MTDiscord |
<_devsh_> This means no more than two mat4s |
| 01:10 |
MTDiscord |
<_devsh_> Problem is that driver needs to figure out where they'll spill ti |
| 01:10 |
|
SFENCE joined #minetest |
| 01:10 |
MTDiscord |
<_devsh_> All that allocation and shenanigans take time, putting pressure on cpu |
| 01:14 |
MTDiscord |
<_devsh_> Well fixed function may be implemented in hardware with an ASIC, and that is closed source and undocumented. Whereas shaders are programmable and outside of firmware, moreover trying to figure out what they're doing and snoop data out of them is an instance of the halting problem, so shaders (GPU driven rendering even more so) are a path to more open source, libre and secure rendering. Possibly at this price of performance. |
| 01:15 |
MTDiscord |
<luatic> not in bed quite yet, don't you have demo videos? |
| 01:16 |
MTDiscord |
<_devsh_> I thought you wanted to learn 😛 |
| 01:16 |
MTDiscord |
<luatic> learning in a VM sounds painful |
| 01:16 |
MTDiscord |
<luatic> for this kind of thing anyways |
| 01:16 |
MTDiscord |
<_devsh_> Try the glorious BDA and descriptor indexing workflow yourself |
| 01:17 |
MTDiscord |
<luatic> now that's an exercise |
| 01:17 |
MTDiscord |
<_devsh_> 20% of my company connects to a server farm with different GPUs over moonshine/RDP every day |
| 01:17 |
MTDiscord |
<_devsh_> And works in a 100% virtualized env |
| 01:17 |
MTDiscord |
<luatic> i don't have a server farm |
| 01:18 |
erle |
<_devsh_> TBF if you're holding up the whole train, won't take HW donations, then maybe you should learn the secrets of GL 2.1 and maintain/extend the renderer |
| 01:18 |
MTDiscord |
<luatic> connecting to a powerful server is great |
| 01:18 |
MTDiscord |
<luatic> but consider this: all i have is a mid-range laptop (Ryzen 5 3500U, 8 GB RAM) |
| 01:18 |
MTDiscord |
<_devsh_> I'm saying that a VM with pcie passthrough is actually quite fast |
| 01:18 |
erle |
you mean fork? |
| 01:18 |
MTDiscord |
<_devsh_> Does it have a dGPU as well? |
| 01:19 |
MTDiscord |
<luatic> iGPU only |
| 01:19 |
MTDiscord |
<_devsh_> Oof |
| 01:19 |
MTDiscord |
<_devsh_> The fun thing with dGPU laptops is that you can give the dGPU to VM with windows and use iGPU with linux |
| 01:19 |
MTDiscord |
<_devsh_> And all you need is just an external monitor |
| 01:20 |
MTDiscord |
<_devsh_> Yeah pcie passthrough not fun with 1 gpu |
| 01:20 |
MTDiscord |
<_devsh_> Have to log out of the X server and atuff |
| 01:20 |
erle |
<luatic> I think GPU skinning just for 90% of the userbase is fine, the rest can have CPU skinning as a fallback |
| 01:21 |
erle |
nah, that will just be culled at some point |
| 01:21 |
MTDiscord |
<_devsh_> That sounds like pain, that lapto should have 16gb of ram |
| 01:21 |
MTDiscord |
<luatic> yeah the RAM is a pain point |
| 01:22 |
MTDiscord |
<_devsh_> 8 logical cores need 2 GB ram per core for good compilation experience |
| 01:22 |
MTDiscord |
<luatic> i will probably upgrade it |
| 01:22 |
MTDiscord |
<luatic> I tend to compile using only 4-6 threads so I can still do other stuff and have a little bit of RAM left and don't run into thrashing |
| 01:22 |
MTDiscord |
<_devsh_> Compiling Nabla is not gonna be fun on that |
| 01:23 |
MTDiscord |
<_devsh_> But it only happens once |
| 01:23 |
erle |
seriously what kind of compilation needs jiggabytes of RAM? is it the LTO? |
| 01:23 |
MTDiscord |
<_devsh_> I actually use 64gb |
| 01:23 |
MTDiscord |
<_devsh_> When you compile llvm from source |
| 01:24 |
MTDiscord |
<luatic> ah yeah |
| 01:24 |
[ |
I compile with -j8 with 16GB of RAM and I don't run out (this is not on the X200 obviously) |
| 01:24 |
MTDiscord |
<_devsh_> J8 with 16gb is my magical 2gb per job ratio |
| 01:25 |
MTDiscord |
<_devsh_> That step is half of the nabla compile time |
| 01:25 |
MTDiscord |
<_devsh_> Also we build every single dep from source |
| 01:28 |
MTDiscord |
<_devsh_> You need to think about how skinning affects the AABB |
| 01:29 |
MTDiscord |
<_devsh_> If your solution is to turn off frustum culling, rip your framerate |
| 01:30 |
MTDiscord |
<_devsh_> If you know all the animations in advance and don't allow programmatic joint manipulation/procedural animation you can compute a worst case AABB across all animations |
| 01:30 |
MTDiscord |
<_devsh_> Then you can skip even doing the animations |
| 01:30 |
MTDiscord |
<_devsh_> Problem is if you then attach something large to one of the joints |
| 01:30 |
MTDiscord |
<_devsh_> But you can give the skinned models stupidly large bounding boxes and use that as an animation cull |
| 01:30 |
MTDiscord |
<luatic> while we're still doing CPU skinning we can just recompute the AABB afterwards |
| 01:31 |
[ |
erle: asan and ubsan add a lot to compilation memory usage if you use those |
| 01:31 |
MTDiscord |
<luatic> but with GPU skinning this will become trickier indeed |
| 01:31 |
MTDiscord |
<_devsh_> It's easy to do |
| 01:31 |
MTDiscord |
<_devsh_> You can build aabbs for each bone |
| 01:31 |
MTDiscord |
<_devsh_> Simply accumulate the vertex into an aabb of the joint if weight > 0 |
| 01:32 |
MTDiscord |
<luatic> yeah |
| 01:32 |
MTDiscord |
<_devsh_> The aabb needs to be in the inverse bing pose though |
| 01:32 |
MTDiscord |
<luatic> but we do allow programmatic joint manipulation |
| 01:32 |
MTDiscord |
<_devsh_> (relative to joint) |
| 01:32 |
MTDiscord |
<_devsh_> Works for that too |
| 01:32 |
MTDiscord |
<_devsh_> Then you just transform and merge all joint aabbs and you have a mesh aabb |
| 01:33 |
MTDiscord |
<luatic> yeah |
| 01:33 |
MTDiscord |
<luatic> sounds good |
| 01:33 |
MTDiscord |
<_devsh_> It works because all vertex weights are between 0-1 |
| 01:33 |
MTDiscord |
<luatic> i know |
| 01:33 |
|
SFENCE joined #minetest |
| 01:35 |
MTDiscord |
<_devsh_> I started mocking some stuff but nobody will pay me for skinning so... https://github.com/Devsh-Graphics-Programming/Nabla/tree/master/include/nbl/scene |
| 01:36 |
MTDiscord |
<luatic> yeah i'll keep that in the back of my mind |
| 01:54 |
|
SFENCE joined #minetest |
| 02:00 |
|
Trifton joined #minetest |
| 02:01 |
|
CRISPR joined #minetest |
| 02:18 |
|
SFENCE joined #minetest |
| 02:50 |
|
SFENCE joined #minetest |
| 02:55 |
|
SFENCE joined #minetest |
| 03:01 |
|
SFENCE_arch joined #minetest |
| 03:03 |
|
Trifton joined #minetest |
| 03:07 |
|
Verticen joined #minetest |
| 03:14 |
erle |
[ i use ubsan yes, you sohuld not do both at once |
| 03:14 |
[ |
erle: why not? |
| 03:15 |
|
SFENCE joined #minetest |
| 03:15 |
erle |
i forgot why |
| 03:15 |
|
nopjmp_ joined #minetest |
| 03:15 |
erle |
ask again when i am awake |
| 03:15 |
erle |
i sleep |
| 03:22 |
|
SFENCE joined #minetest |
| 03:25 |
MTDiscord |
<jordan4ibanez> erle give us the meme plz |
| 03:44 |
|
SFENCE joined #minetest |
| 03:56 |
|
SFENCE joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:22 |
|
chilledfrogs joined #minetest |
| 05:29 |
|
Verticen joined #minetest |
| 05:32 |
|
chilledfrogs joined #minetest |
| 05:37 |
|
CRISPR joined #minetest |
| 07:58 |
|
SFENCE_arch joined #minetest |
| 08:10 |
|
gregon joined #minetest |
| 08:21 |
|
Glaedr joined #minetest |
| 08:22 |
|
SFENCE joined #minetest |
| 08:45 |
|
jaca122 joined #minetest |
| 08:45 |
|
SFENCE joined #minetest |
| 08:53 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Apply Luanti rename bc8d925 https://github.com/minetest/minetestmapper/commit/bc8d925eb425fe3d2ef155f3858e8418d234b063 (2024-11-11T08:50:26Z) |
| 08:56 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Apply Luanti rename 1c16c40 https://github.com/minetest/minetestmapper/commit/1c16c40ccca7039e7e03f9a81909c1d3e5fd11c1 (2024-11-11T08:53:35Z) |
| 08:58 |
|
tarsovbak joined #minetest |
| 09:04 |
|
SFENCE joined #minetest |
| 09:22 |
|
SFENCE joined #minetest |
| 09:49 |
|
yezgromafic joined #minetest |
| 09:53 |
|
yezgromafic joined #minetest |
| 09:56 |
|
SFENCE joined #minetest |
| 10:08 |
|
tarsovbak joined #minetest |
| 10:13 |
|
tarsovbak joined #minetest |
| 10:13 |
|
tarsovbak joined #minetest |
| 10:14 |
|
tarsovbak joined #minetest |
| 10:16 |
|
MacroFaxSax joined #minetest |
| 10:17 |
|
tarsovbak joined #minetest |
| 10:18 |
|
tarsovbak joined #minetest |
| 10:18 |
|
tarsovbak joined #minetest |
| 10:18 |
|
tarsovbak joined #minetest |
| 10:20 |
|
behalebabo joined #minetest |
| 10:22 |
|
tarsovbak joined #minetest |
| 10:22 |
|
tarsovbak joined #minetest |
| 10:24 |
|
SFENCE joined #minetest |
| 10:30 |
|
tarsovbak joined #minetest |
| 10:30 |
|
tarsovbak joined #minetest |
| 10:30 |
|
tarsovbak joined #minetest |
| 10:39 |
|
ireallyhateirc joined #minetest |
| 10:58 |
|
SFENCE joined #minetest |
| 10:59 |
|
illwieckz joined #minetest |
| 11:09 |
|
SFENCE joined #minetest |
| 11:41 |
erle |
jordan4ibanez is this another idea to force the “2erle” thing? |
| 11:42 |
|
SFENCE joined #minetest |
| 11:49 |
|
est31 joined #minetest |
| 11:50 |
MTDiscord |
<jordan4ibanez> No I want this meme from minetest delta |
| 11:51 |
erle |
i think you can scroll back on /r/minetest on reddit |
| 11:51 |
erle |
it should be one of the very first posts there |
| 11:51 |
MTDiscord |
<jordan4ibanez> https://cdn.discordapp.com/attachments/749727888659447960/1305500191058563073/image0-1.jpg?ex=6733414c&is=6731efcc&hm=681518c3df4a5eb2a80e90d585c3d0025a8d5336aed42fa6b038fc51155288e4& |
| 11:51 |
erle |
or what do you mean? |
| 11:51 |
MTDiscord |
<jordan4ibanez> Oh no, this was an irc meme, it's lost media |
| 11:52 |
erle |
jordan4ibanez http://daten.dieweltistgarnichtso.net/pics/zeichnungen/minetest-dad.png |
| 11:52 |
erle |
you mean that? |
| 11:53 |
MTDiscord |
<jordan4ibanez> HOLY |
| 11:53 |
MTDiscord |
<jordan4ibanez> Thank you so much |
| 11:54 |
celeron55 |
wait, i remember that but i can't find it in my memes folder |
| 11:54 |
erle |
here is the xcf: http://daten.dieweltistgarnichtso.net/pics/zeichnungen/minetest-dad.xcf |
| 11:55 |
erle |
happy now? |
| 11:55 |
erle |
if so, bring back omsk bird! |
| 11:55 |
MTDiscord |
<jordan4ibanez> Yes, thank you so much omg |
| 12:08 |
|
SFENCE joined #minetest |
| 12:15 |
[ |
erle: why not use both asan and ubsan at once? |
| 12:17 |
erle |
[ https://blogs.oracle.com/linux/post/improving-application-security-with-undefinedbehaviorsanitizer-ubsan-and-gcc |
| 12:17 |
erle |
> Do not try to compile with both ASan and UBSan at the same time, even though it is possible to do so. Our experience is that the source code needs to be instrumented separately and different runs have to be conducted to detect all errors. |
| 12:17 |
erle |
also some sanitizers do not play well AT ALL with each other |
| 12:18 |
[ |
"This site requires JavaScript to be enabled." |
| 12:18 |
erle |
yes sorry |
| 12:18 |
erle |
i have quoted the relevant part |
| 12:19 |
erle |
[ IMO it's a conceptual issue. do you want one sanitizer to sanitize the instrumentation the other adds? |
| 12:20 |
erle |
maybe i am wrong here |
| 12:23 |
[ |
when I fuzz dnethack I usually use both at once if I have enough memory to do so |
| 12:23 |
erle |
random: IIRC DWARF debug info was one of the things where zlib outperforms zstd, because LEB128 encoded integers are bad |
| 12:23 |
erle |
for zstd https://github.com/facebook/zstd/issues/1325 |
| 12:25 |
erle |
[ even if it works (as opposed, to, e.g. using asan and msan together), i doubt the instrumentation is designed to run together |
| 12:26 |
erle |
[ i don't doubt that ubsan and asan work together somewhat, but since asan adds stuff, i would worry that it might mask bugs |
| 12:27 |
erle |
also, memory increase of asan is like, what, ⅛ of memory your app takes anyway? |
| 12:30 |
|
SFENCE joined #minetest |
| 12:33 |
ireallyhateirc |
Dumb question: if I have my mod and directory ./my-mod/textures, then can I do a subdirectory say ./my-mod/textures/foo ? |
| 12:39 |
MTDiscord |
<luatic> ireallyhateirc: yes, you can do that. for all types of media in fact. |
| 12:43 |
ireallyhateirc |
that's great |
| 12:45 |
[ |
erle: A lot more than 1/8. In this case: ~600M for asan+ubsan, ~500M for asan, ~36M for ubsan, ~15M for no sanitizers |
| 13:10 |
|
SFENCE joined #minetest |
| 13:10 |
|
Oblomov joined #minetest |
| 13:20 |
|
HuguesRoss joined #minetest |
| 13:29 |
|
SFENCE joined #minetest |
| 13:31 |
|
SwissalpS joined #minetest |
| 13:37 |
|
Juliet joined #minetest |
| 14:04 |
|
SFENCE joined #minetest |
| 14:11 |
|
SFENCE joined #minetest |
| 14:28 |
|
Sharpman joined #minetest |
| 14:38 |
|
Sharpman joined #minetest |
| 15:05 |
|
SFENCE joined #minetest |
| 15:12 |
|
SFENCE joined #minetest |
| 15:32 |
|
SFENCE joined #minetest |
| 15:45 |
|
serp joined #minetest |
| 15:56 |
|
tarsovbak joined #minetest |
| 15:56 |
|
MacroFaxSax joined #minetest |
| 15:56 |
|
tarsovbak joined #minetest |
| 16:12 |
|
SFENCE joined #minetest |
| 16:14 |
|
SFENCE joined #minetest |
| 16:17 |
MTDiscord |
<_devsh_> I don't condone all the design decisions in the video, but pretty nice regardless https://www.youtube.com/watch?v=40JzyaOYJeY |
| 16:20 |
MTDiscord |
<_devsh_> 300k tris at sub 0.1ms, that makes >3 GTris/s |
| 16:42 |
|
MTDiscord joined #minetest |
| 16:51 |
|
tarsovbak joined #minetest |
| 16:51 |
|
tarsovbak joined #minetest |
| 17:04 |
|
fluxionary joined #minetest |
| 17:17 |
|
dabbill joined #minetest |
| 17:29 |
|
TomTom joined #minetest |
| 17:41 |
|
kamdard joined #minetest |
| 17:44 |
MTDiscord |
<warr1024> Build 5.10.0 server, get a minetestserver executible but no luantiserver executible ... run it, and get a warning: "The executable minetestserver is a deprecated alias, please use luantiserver instead" |
| 17:45 |
specing |
That's what you get when you don't have erle doing your QA |
| 17:58 |
sfan5 |
this works in all of our CI runs, so open a bug |
| 18:03 |
|
Talkless joined #minetest |
| 18:03 |
|
Markow joined #minetest |
| 18:28 |
MTDiscord |
<goodclover> devsh: oo, that's a really nice video. I'd never heard of half these optimisations. |
| 18:30 |
Krock |
@_devsh_ instancing requires OpenGL 3.1 afaik |
| 18:30 |
Krock |
though that's not a reason to not use it. |
| 18:31 |
Krock |
there's also a video about greedy mesher approaches which is rather entertaining. |
| 18:31 |
Krock |
not from the same author, but generally a concept that's also applied to a certain degree in Luanti/Minetest |
| 18:46 |
MTDiscord |
<_devsh_> Instancing is one of the decisions I don't approve |
| 18:57 |
erle |
Krock for ARB_draw_instanced, 3.0 is required according to http://www.opengl.org/registry/specs/ARB/draw_instanced.txt |
| 18:59 |
Krock |
transparency sorting could also become a really interesting challenge with such sophisticated approaches. |
| 18:59 |
erle |
and according to “glxinfo |grep instance” i don't have it. |
| 18:59 |
sfan5 |
ban semi-transparency |
| 18:59 |
MTDiscord |
<_devsh_> Greedy meshing is a nasty misoptimization |
| 18:59 |
Krock |
glxinfo |grep instance | wc -l |
| 18:59 |
Krock |
13 |
| 18:59 |
MTDiscord |
<_devsh_> It's called order independent transparency and it's fun |
| 19:00 |
MTDiscord |
<_devsh_> MLAB4, WBOIT, hashed and stencil k routed are the goto approaches |
| 19:00 |
Krock |
@_devsh_: not necessarily. it can be used as a memory optimization, though not much more than that. |
| 19:01 |
MTDiscord |
<_devsh_> Greedy meshing makes edits hard/impossible |
| 19:01 |
MTDiscord |
<_devsh_> Without recomputing a whole chunk |
| 19:01 |
Krock |
the trick is to have the greedy mesher be somewhat fast, although not perfect. |
| 19:02 |
erle |
i for one, agree with sfan5. semi-transparency must be banned. use A1R5G5B5 textures for everything, save half of texture memory and never look back! |
| 19:02 |
Krock |
the meshgen in Luanti/Minetest currently works like that. each node update triggers a whole re-meshing of the mapblock. |
| 19:02 |
erle |
(it's not like people can see the difference anyway) |
| 19:02 |
Krock |
opaque water... hmmmm. |
| 19:03 |
erle |
reflective metallic water :D |
| 19:03 |
MTDiscord |
<_devsh_> It's like polishing a turd, if you put all the effort you have to put into greedy meshing that works, into raycasting instead you'd get better perfx maintainability and features |
| 19:03 |
erle |
Krock is the mesh thing the reason why fiddling with the mapblock size (or was it chunk size?) affects performance? |
| 19:03 |
MTDiscord |
<_devsh_> https://jcgt.org/published/0007/03/04/ |
| 19:04 |
sfan5 |
raycasting for what exactly? culling? |
| 19:04 |
MTDiscord |
<_devsh_> No rendering |
| 19:04 |
Krock |
erle: that one's down to the amount of draw calls from what I remember |
| 19:04 |
Krock |
larger meshes = less drawcalls = faster |
| 19:04 |
MTDiscord |
<_devsh_> You draw a Proxy geometry then use a fancy shader to make cubes out of billboards |
| 19:05 |
* erle |
shudders |
| 19:05 |
erle |
_devsh_ that would also allow people to make geometry that looks like blobs? |
| 19:05 |
MTDiscord |
<_devsh_> Whatever you want |
| 19:05 |
erle |
i'll call the inquisitor |
| 19:06 |
MTDiscord |
<_devsh_> It's kinda like a hybrid stop gap solution between KHR_acceleration_structure raytracing and plain triangle raster |
| 19:09 |
erle |
jokes aside, _devsh_ can you tell me why people use shadow maps instead of soft stencil shadows for monochrome shadows in games nowadays? like, screen-space blur of the shadow space or whatever. from all i know it can't do colored shadows (obv.) but has much less artifacts |
| 19:09 |
erle |
*shadow pass |
| 19:11 |
erle |
and as i understand it, the shadow map is *necessarily* undersampled, except if you are pixar and do not render in realtime |
| 19:11 |
erle |
(blurring can help somewhat) |
| 19:19 |
MTDiscord |
<_devsh_> There's actually a view distance at which it's faster to splat voxels as point clouds to a fake depth+ID compute shader shared memory using uint64 atomics than actually usibg the HW rasterizer |
| 19:20 |
MTDiscord |
<_devsh_> Because silhouette extrusion is extremely PITA and needs to be done every frame, also stencil shadows don't have any way to soften them, they alias like crazy |
| 19:21 |
MTDiscord |
<_devsh_> Shadow Maps aren't bad if you've got your cascaded shadow map and adaptive shadow map impl down to a T |
| 19:23 |
MTDiscord |
<_devsh_> Furthermore stencil shadows work by flipping bits in screen space and depth fail |
| 19:23 |
MTDiscord |
<_devsh_> It means transparent objects can't receive shadows |
| 19:23 |
MTDiscord |
<_devsh_> Or cast them (smaller problem) |
| 19:23 |
erle |
i know that |
| 19:23 |
erle |
transparent cape on player avatar thingy |
| 19:25 |
MTDiscord |
<_devsh_> Fixed function sucks balls big time |
| 19:25 |
MTDiscord |
<_devsh_> Shadow mapping is basically more robust |
| 19:26 |
MTDiscord |
<_devsh_> You can cache them, amortize their draw calls over multiple frames |
| 19:26 |
MTDiscord |
<_devsh_> Etc etc |
| 19:28 |
erle |
if you want to amortize some draw calls over multiple frames … does the inventory still take more draw calls than the rest of the world if you make it big and add my “studs” mod? |
| 19:28 |
erle |
(caching the result is correct for every node that is not animated) |
| 19:29 |
MTDiscord |
<_devsh_> I don't get your question |
| 19:29 |
|
specing left #minetest |
| 19:29 |
erle |
just ignore it then |
| 19:29 |
erle |
sorry |
| 19:29 |
erle |
_devsh_ on which part of the engine are you working? |
| 19:29 |
MTDiscord |
<_devsh_> Huh? |
| 19:30 |
Krock |
"What is Minetest?" |
| 19:30 |
MTDiscord |
<_devsh_> I'm not touching mine test with a 10 foot pole, codebase is disgusting |
| 19:30 |
erle |
LMAO |
| 19:30 |
MTDiscord |
<_devsh_> Also I have block game PTSD |
| 19:30 |
erle |
do you have your own games/demos that i could look at? |
| 19:30 |
MTDiscord |
<_devsh_> There's nothing in the world that would make me render another block |
| 19:30 |
erle |
hahahahaha |
| 19:31 |
MTDiscord |
<_devsh_> Build a World |
| 19:31 |
MTDiscord |
<_devsh_> After that I stopped doing games |
| 19:31 |
erle |
_devsh_ if you want to see block game engine abuse, look at my xcam mod. it is a proof-of-concept that abuses the raycasting function to make in-game photos with a redneck raytracer. |
| 19:31 |
erle |
turns out casting like 100k rays in a single server step is not the healthiest approach |
| 19:31 |
erle |
it got me some downvotes |
| 19:31 |
erle |
but it is funny |
| 19:32 |
erle |
_devsh_ see here: https://content.luanti.org/packages/erlehmann/xcam/ |
| 19:32 |
MTDiscord |
<_devsh_> Raycasting the game from a single GL_TEXTURE_3D would probably be faster that drawing with irrlicht |
| 19:32 |
erle |
you clearly have not run it on potato hardware |
| 19:32 |
erle |
i have potato |
| 19:33 |
erle |
despite all the waste going on (tons of drawcalls or so), games that look similar use MUCH more resources |
| 19:33 |
erle |
unless you take games from 15 years ago |
| 19:33 |
MTDiscord |
<_devsh_> 256 steps through a 256x256x256 occupancy volume take 2048 bits |
| 19:34 |
|
Verticen joined #minetest |
| 19:34 |
MTDiscord |
<_devsh_> The shittiest GPU you can target has 800 MB/s of bandwidth |
| 19:35 |
MTDiscord |
<_devsh_> Sorry |
| 19:35 |
MTDiscord |
<_devsh_> 8GB/s |
| 19:36 |
MTDiscord |
<_devsh_> You could probably pull of 30fps rendering |
| 19:37 |
MTDiscord |
<_devsh_> https://www.shadertoy.com/view/4dX3zl |
| 19:38 |
MTDiscord |
<_devsh_> 60 FPS on my phone, 1024x800 viewport |
| 19:38 |
erle |
i do actually have 30fps with fixed pipeline on old thinkpad, but i guess soon i will have 0fps, when the gamer guys axe that renderer |
| 19:39 |
MTDiscord |
<_devsh_> https://www.shadertoy.com/view/csscD4 |
| 19:39 |
MTDiscord |
<_devsh_> 40 FPS on my phone |
| 19:39 |
MTDiscord |
<_devsh_> No triangles wer harmed |
| 19:39 |
MTDiscord |
<_devsh_> All just plain raycasting in shaders |
| 19:39 |
erle |
that shader toy thing is like 7fps here small, about 1fps fullscreen |
| 19:39 |
erle |
fullscreen 1400x1050 |
| 19:40 |
erle |
sorry _devsh_ we are living in different hardware realities |
| 19:40 |
erle |
_devsh_ link to “build a world” game you made? |
| 19:41 |
MTDiscord |
<_devsh_> Yeah I mean your having shitty hardware is such a drag on graphics developers lives that someone should literally just send you an old 780 ti |
| 19:41 |
erle |
nah, it is not. no one listens to me. |
| 19:41 |
MTDiscord |
<_devsh_> Because the manhours required to pay for that are literally less than trying to maintain a gles 2.1 renderer and "optimize" the irrlicht stack |
| 19:41 |
erle |
so don't worry |
| 19:41 |
Krock |
This gaming router might be more capable at this point: https://kittenlabs.de/real-gaming-router/ |
| 19:42 |
erle |
i am waiting for replacement batteries for my reform 2 |
| 19:42 |
MTDiscord |
<_devsh_> An raspberry pi is more capable |
| 19:42 |
erle |
MNT reform (the MNT stands for My New Thinkpad) |
| 19:43 |
MTDiscord |
<_devsh_> If I had to pick, developing for that gles 2.0/gl 2.1 hardware your user base loves so much and a software renderer, I'd choose the software renderer |
| 19:44 |
MTDiscord |
<luatic> software renderers are kinda fun to write, just not fun to use |
| 19:44 |
MTDiscord |
<_devsh_> At least llvmpipe works, is maintained and you can step through them |
| 19:44 |
erle |
software renderer but opengl API (this is how mesa developers are created) |
| 19:44 |
MTDiscord |
<warr1024> by "software" I assume you mean "software on CPU" which is the thing that actually sounds antiquated, rather than "software on GPU" which is de facto what everyone is doing these days and just using terms like "shader" to pretend it's fundamentally different 😄 |
| 19:45 |
MTDiscord |
<_devsh_> I literally mean, CPU code |
| 19:45 |
MTDiscord |
<_devsh_> No GPU |
| 19:45 |
erle |
Warr1024 i can actually get like 7fps by using LIBGL_ALWAYS_SOFTWARE (and enjoying the smell of burnt plastic), so not even an order of magnitude rendering performance improvement and GPU doees not matter |
| 19:46 |
erle |
well, i haven't tried actually playing with that tbh |
| 19:46 |
MTDiscord |
<luatic> Warr1024: if you're stuck on old GL versions, what you can do on shaders is fundamentally different from what you can do on the CPU :( |
| 19:46 |
MTDiscord |
<warr1024> I've been trying to figure out if twitch.tv/nodecoremt is actually fully software rendered, since it runs entirely inside docker, or if some iGPU features are directly available to unprivileged CPU processes... |
| 19:46 |
MTDiscord |
<luatic> well, depends on your definition of fundamentally, i guess |
| 19:47 |
erle |
luatic what is *fundamentally* different for you? |
| 19:47 |
erle |
i mean obviously you can render pixels to screen one way or another |
| 19:48 |
|
kamdard joined #minetest |
| 19:48 |
MTDiscord |
<warr1024> to me they both involve using a more or less general-purpose-capable computing chip to run potentially arbitrary software to define rendering |
| 19:48 |
MTDiscord |
<_devsh_> SSBO |
| 19:48 |
MTDiscord |
<_devsh_> https://www.khronos.org/opengl/wiki/Shader_Storage_Buffer_Object |
| 19:49 |
MTDiscord |
<_devsh_> https://www.khronos.org/opengl/wiki/Compute_Shader |
| 19:49 |
MTDiscord |
<luatic> Warr1024: yeah this "more or less" is doing quite some heavy lifting |
| 19:49 |
MTDiscord |
<warr1024> more or less everything requires at least a little heavy lifting |
| 19:50 |
MTDiscord |
<_devsh_> The neat thing about compute shader rendering is that you have no helper invocations |
| 19:50 |
MTDiscord |
<_devsh_> 4x faster than rendering HW triangles |
| 19:50 |
MTDiscord |
<luatic> to give an example, consider order-independent transparency. on real general purpose CPUs this is trivial to implement, just use some data structure to allow for multiple fragment layers per pixel. i'm not aware of an easy way to do this on ancient GL versions. maybe devsh is. |
| 19:51 |
MTDiscord |
<_devsh_> Depth peeling but that's stupidly unperformant |
| 19:51 |
MTDiscord |
<_devsh_> Ekhm ekhm raytracing |
| 19:51 |
MTDiscord |
<_devsh_> Best data structure no data structure |
| 19:52 |
Krock |
this is perhaps the first time I've heard "general purpose" used outside of electronics component datasheets |
| 19:52 |
MTDiscord |
<_devsh_> Yes yes we know mine test graphics team is non existent |
| 19:53 |
MTDiscord |
<warr1024> "general purpose" as in not like a smart thermostat or an iphone or something 😆 |
| 19:53 |
MTDiscord |
<_devsh_> I've always found it amusing |
| 19:53 |
MTDiscord |
<_devsh_> Little gfx knowledge, 0 desire for gfx knowledge, pushing GFX to the side and then wondering why perf sucks |
| 19:54 |
MTDiscord |
<luatic> I will admit that I'm not very knowledgeable when it comes to graphics dev, but I don't think there is a need to be condescending like this. |
| 19:54 |
MTDiscord |
<luatic> Our performance issues go well beyond graphics by the way. |
| 19:55 |
MTDiscord |
<_devsh_> Yes, I know |
| 19:55 |
MTDiscord |
<_devsh_> The performance issue comes from building around irrlicht |
| 19:55 |
MTDiscord |
<_devsh_> And learning anti patterns |
| 19:55 |
MTDiscord |
<_devsh_> Then being locked into anti patterns |
| 19:57 |
erle |
i actually like the tone that _devsh_ has, but i'd like it to be backed up by some actual demonstrations of easy gainz performance or effects wise. |
| 19:57 |
MTDiscord |
<_devsh_> The reason why other games/engines got a lot nicer over time is because people were actively targeting the problem areas/bottlenecks and not afraid to make huge changes |
| 19:57 |
erle |
the proof is in the pudding, so to say |
| 19:58 |
MTDiscord |
<_devsh_> Graphics is special |
| 19:58 |
MTDiscord |
<_devsh_> Audio, networking, etc don't tend to push your software arch to it's limits |
| 19:58 |
MTDiscord |
<_devsh_> So people don't start paying attention to what really matters |
| 19:58 |
MTDiscord |
<_devsh_> Which is making software that fits the target arch, is easy to maintain and agile |
| 19:59 |
erle |
_devsh_ you can't be agile without discipline in my experience |
| 20:00 |
MTDiscord |
<_devsh_> And problem is super magnified if you take 10 different foss libraries tape them together, don't ont fork them, don't want to maintain them and are scared to look inside |
| 20:00 |
erle |
and by discipline i mean “write test cases, yes even for the stupidest thing where you just fixed a < into a >” |
| 20:00 |
celeron55 |
some downtime on the website Very Soon (tm). i'm trying to do the domain switch now |
| 20:00 |
erle |
i wish you success |
| 20:00 |
MTDiscord |
<_devsh_> Because then your primary concern is "how do I make the least change so this ducttape tower doesn't collapse" |
| 20:02 |
Krock |
negative LOC changes are always a joy to see |
| 20:03 |
MTDiscord |
<_devsh_> https://cdn.discordapp.com/attachments/749727888659447960/1305623962444894288/image-3.png?ex=6733b491&is=67326311&hm=30b3488167e2622814c727749590e4514a59d6488352e4166b5b7e9ea230e81e& |
| 20:03 |
MTDiscord |
<_devsh_> Let me get you a logarithmic scale so you can see better |
| 20:03 |
MTDiscord |
<_devsh_> https://cdn.discordapp.com/attachments/749727888659447960/1305624083219877910/image-4.png?ex=6733b4ae&is=6732632e&hm=a8767a9d36b4807e1c4db2302b130bc66ae1c1d01c74f67512d5d7c419949a27& |
| 20:04 |
Krock |
GDI, as in the Windows software rendering? |
| 20:04 |
MTDiscord |
<_devsh_> Yes it's for a cad thing |
| 20:04 |
MTDiscord |
<grorp> > Because then your primary concern is "how do I make the least change so this ducttape tower doesn't collapse" |
| 20:04 |
MTDiscord |
<grorp> indeed, that's the way you currently have to think if you're trying to work on Luanti graphics code |
| 20:04 |
MTDiscord |
<_devsh_> https://youtu.be/M-IMQT7yKVI?si=JgTlQpucmS1yLZbu |
| 20:05 |
MTDiscord |
<grorp> and it sucks |
| 20:05 |
erle |
grorp that's the way you have to think with every project that has that kind of history and hardware platform support and no resources for a full rewrite of some component. |
| 20:05 |
MTDiscord |
<_devsh_> And that's why you cut the balast |
| 20:05 |
MTDiscord |
<_devsh_> And draw the line at gles 3.1 |
| 20:06 |
MTDiscord |
<_devsh_> The higher you amputate the better |
| 20:07 |
celeron55 |
huh, i think i managed to do it |
| 20:07 |
ROllerozxa |
hooray |
| 20:07 |
Krock |
what did you amputate? |
| 20:08 |
MTDiscord |
<_devsh_> Most of irrlicht |
| 20:08 |
erle |
grorp btw i would appreciate if you privately wrote me which kinds of things you found unhelpful. i don't want to debate you on it or justify it, i just would like to know in general what you disliked about cases where you agree with me about the issue at hand (i.e. not if there is a bug). |
| 20:08 |
MTDiscord |
<_devsh_> And any GPU that's not getting driver updates |
| 20:08 |
erle |
_devsh_ i think the dev team is far ahead of you |
| 20:09 |
erle |
_devsh_ they did cut most of irrlicht already |
| 20:09 |
erle |
and are definitely planning to cut support for GPUs that still have mesa support |
| 20:09 |
ROllerozxa |
now don't forget to fully move over the forums and wiki to luanti.org |
| 20:09 |
celeron55 |
well, the forum is dead again, so i can't change the cookie domain there |
| 20:10 |
ROllerozxa |
don't you have SSH access? |
| 20:10 |
ROllerozxa |
or did that time out too |
| 20:10 |
celeron55 |
i don't think that helps with phpbb much |
| 20:10 |
celeron55 |
i mean, sure i do |
| 20:11 |
celeron55 |
if i'm to spend time with the forum, i'll rather spend it figuring out a good setup for the box i got for moving the forum onto |
| 20:12 |
celeron55 |
it's just that i made the mistake of getting a 10x faster dedibox so it doesn't make sense to do anything with it without virtualization on top first |
| 20:12 |
celeron55 |
having said that, anyone want to play around with it? |
| 20:13 |
celeron55 |
it's kind of fun, i put proxmox on it for testing |
| 20:13 |
celeron55 |
but not everything works like i expect |
| 20:14 |
celeron55 |
i so far have failed to make a VM that would run a HTTP(S) reverse proxy for the thing |
| 20:14 |
celeron55 |
for some reason TCP packets just don't want to go through the network |
| 20:23 |
erle |
celeron55 the whole downtime thing, is that some resource exhaustion that can be debugged without having access to the live data you want to keep private? |
| 20:23 |
celeron55 |
there's not much point diagnosing it as the resource that's exhausted is CPU time |
| 20:24 |
celeron55 |
the server is probably weaker than your old thinkpad |
| 20:24 |
erle |
well, computers are fast. there is no reason a phpbb should eat itself |
| 20:24 |
erle |
(is it a phpbb?) |
| 20:24 |
celeron55 |
i'm not hopping onto the phpbb fork bandwagon |
| 20:24 |
celeron55 |
that would be a slowly growing disaster |
| 20:25 |
erle |
nah, but it could be that there is some thing that is accidentally quadratic or so |
| 20:25 |
erle |
i recently found on an old server that was to be decommissioned that instead of overwriting logfiles, i apparently appended to them … the entire logfile and new logs. |
| 20:25 |
celeron55 |
yes, no |
| 20:25 |
celeron55 |
i have better use for my time |
| 20:26 |
erle |
the question i was asking is: can i help debugging but in a way you don't have to trust me with user data? |
| 20:26 |
erle |
i used to do php a long time ago |
| 20:26 |
celeron55 |
anyway, i restarted the forum's php-fpm and that brought the forum back online. now the domain should be swapped there too |
| 20:26 |
erle |
yay |
| 20:26 |
celeron55 |
your forum session will be lost |
| 20:27 |
celeron55 |
hopefully nobody is writing a long forum post right now as they'll probably lose it if they don't copy it into a text editor... |
| 20:27 |
erle |
i always do that, don't trust web forms |
| 20:27 |
erle |
after wordpress ate one too many posts of mine |
| 20:27 |
celeron55 |
yeah, never trust web forms. i've learned my lesson too |
| 20:28 |
erle |
reddit is especially interesting there. they are happy to serve a stale version of an edited comment once it was edited if the page is refreshed. |
| 20:29 |
erle |
but then you refresh a couple times and *sometimes* you get the new one, sometimes the old |
| 20:34 |
ROllerozxa |
um, I think you forgot to set up a redirect on minetest.net |
| 20:34 |
ROllerozxa |
(well, it redirects to c55.me, but I'm sure that's not intentional) |
| 20:35 |
sfan5 |
works fine here |
| 20:36 |
erle |
yeah for me as well, but maybe c55 is just ninja fast |
| 20:36 |
ROllerozxa |
how embarrassing x_x |
| 20:37 |
ROllerozxa |
yes indeed it is fixed now |
| 20:45 |
celeron55 |
there were some messed up overall states during all that as i couldn't do it all at once |
| 20:45 |
celeron55 |
and depending on when your DNS happens to update, especially if it doesn't follow TTLs, there might still be |
| 21:43 |
|
kamdard joined #minetest |
| 21:57 |
|
sinvet joined #minetest |
| 21:59 |
|
MisterE1230 joined #minetest |
| 22:00 |
|
kamdard joined #minetest |
| 22:03 |
|
serp joined #minetest |
| 22:28 |
|
silverwolf73828 joined #minetest |
| 22:47 |
|
jaca122 joined #minetest |
| 23:02 |
|
Baytuch_2 joined #minetest |
| 23:04 |
|
fling_ joined #minetest |
| 23:34 |
|
panwolfram joined #minetest |
| 23:58 |
|
shinbet joined #minetest |
