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 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 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 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: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 Yes 00:28 MTDiscord 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 Technically both 00:29 MTDiscord <_devsh_> Seamless cubemap filtering is like GL 3.something / dx10 feature 00:29 specing Libre microcode could have cool use cases 00:29 MTDiscord 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 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 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 Nothing technically 00:33 ireallyhateirc I really like when devs work on stuff that I find useful/interesting :P 00:33 MTDiscord 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 I think its less than that 00:33 MTDiscord <_devsh_> Use texture2d array instead 00:33 MTDiscord ok yeah thats what I meant 00:34 MTDiscord (arguably an array of texture2d is 3d) 00:34 MTDiscord <_devsh_> Ok you're giving me ptsd 00:34 MTDiscord Happens 00:34 MTDiscord <_devsh_> @luatic this is what I meant by piling up tech debt 00:34 MTDiscord 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 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 yeah i know 00:36 MTDiscord (re piling up tech debt) 00:36 MTDiscord i've got a plan but no time 00:36 MTDiscord or at least not enough time 00:38 MTDiscord 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 well, i've got a couple other even more WIP things too but those aren't in a presentable state 00:39 MTDiscord 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 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 read the description, this is just preparatory work for that 00:42 MTDiscord devsh: my plan for that is to send the bone transforms to the vertex shader via an UBO 00:42 MTDiscord 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 yeah 00:43 MTDiscord 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 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 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 so what can i do? 00:47 MTDiscord 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 are you 00:49 MTDiscord <_devsh_> Aka Buffer Texture 00:49 MTDiscord 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 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 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: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 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 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 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 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 not in bed quite yet, don't you have demo videos? 01:16 MTDiscord <_devsh_> I thought you wanted to learn 😛 01:16 MTDiscord learning in a VM sounds painful 01:16 MTDiscord for this kind of thing anyways 01:16 MTDiscord <_devsh_> Try the glorious BDA and descriptor indexing workflow yourself 01:17 MTDiscord 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 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 connecting to a powerful server is great 01:18 MTDiscord 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 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 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 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 i will probably upgrade it 01:22 MTDiscord 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 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 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 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 yeah 01:32 MTDiscord <_devsh_> The aabb needs to be in the inverse bing pose though 01:32 MTDiscord 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 yeah 01:33 MTDiscord sounds good 01:33 MTDiscord <_devsh_> It works because all vertex weights are between 0-1 01:33 MTDiscord i know 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 yeah i'll keep that in the back of my mind 03:14 erle [ i use ubsan yes, you sohuld not do both at once 03:14 [ erle: why not? 03:15 erle i forgot why 03:15 erle ask again when i am awake 03:15 erle i sleep 03:25 MTDiscord erle give us the meme plz 08:53 MinetestBot 02[git] 04sfan5 -> 03minetest/minetestmapper: Apply Luanti rename 13bc8d925 https://github.com/minetest/minetestmapper/commit/bc8d925eb425fe3d2ef155f3858e8418d234b063 (152024-11-11T08:50:26Z) 08:56 MinetestBot 02[git] 04sfan5 -> 03minetest/minetestmapper: Apply Luanti rename 131c16c40 https://github.com/minetest/minetestmapper/commit/1c16c40ccca7039e7e03f9a81909c1d3e5fd11c1 (152024-11-11T08:53:35Z) 11:41 erle jordan4ibanez is this another idea to force the “2erle” thing? 11:50 MTDiscord 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 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 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 HOLY 11:53 MTDiscord 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 Yes, thank you so much omg 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: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 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 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 17:44 MTDiscord 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:28 MTDiscord 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 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 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 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 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 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 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 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 MTDiscord 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 Warr1024: yeah this "more or less" is doing quite some heavy lifting 19:49 MTDiscord 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 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 "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 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 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 > Because then your primary concern is "how do I make the least change so this ducttape tower doesn't collapse" 20:04 MTDiscord 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 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