00:21 Company: jenatali: a thought I had about warp/llvmpipe: it's really easy to run stuff on Linux with llvmpipe, anyone can just export LIBGL_ALWAYS_SOFTWARE=1 - Warp doesn't seem to have a way to trigger it that easily and all the demos even need custom code to support it, which means there's no generic "have you tried $app with warp" thing
00:40 jenatali: Company : The DX Control Panel or its cmdline replacement have force-warp options
00:40 jenatali: You can also go into device manager and just disable your GPU
00:41 Company: huh, then why do those tutorials all need it?
00:41 jenatali: It's easier to do a command line parameter or tweak a build config sometimes
00:43 Company: anyway, thx for telling me about d3dconfig
00:44 jenatali: FWIW this is a pretty off-topic place for this discussion. I don't mind but if others do, we have a DX Discord server
00:50 Company: dunno, I think it's kinda relevant, but I'm thinking about it from my app development platform pov - and the tools that Mesa offers for that - like, it's already more complicated with Vulkan because the magic env var if more obscure
00:53 jenatali:shrugs
00:54 jenatali: Today I got my first shaders compiled with 16-wide waves using AVX512, so that was fun
01:07 airlied: jenatali: I did some playing with 16-wide last year, but there's a bunch of llvmpipe blend paths that I had trouble working through
01:08 airlied: but I think for compute shaders llvmpipe might be okay
01:14 jenatali: airlied: I verified vertex, pixel, and compute, but haven't tried the more exotic ones yet. In theory I ported it all though
01:15 jenatali: I'm proud considering it's a completely custom instruction emitter that didn't even know about AVX last year
01:21 airlied: as much as I dislike LLVM I think I dislike that more :-)
01:21 jenatali: Yeah. Pros and cons. It's lightweight for sure
03:00 mareko: well, NIR could have an x86 backend
03:01 airlied: it totally could, but you have to deal with all the pains of avx512
03:02 airlied: it's why we ripped out the sse backend we used to have, because expanding it to avx2 and beyond was painful
03:02 airlied: we've even looked for alternate JITs but nobody really supports vectors all that well
03:05 airlied: and then you have to deal with non-x86
03:05 mareko: where llvmpipe doesn't run
03:06 mareko: NIR -> ARM bytecode
03:07 airlied: llvmpipe works on arm, riscv fine
03:07 airlied: power and s390
03:14 mattst88: I hear "orc" is a thing, but I don't know how good it is
03:14 HdkR: I have some users that even run llvmpipe->x86-64->arm64, bonkers.
03:14 HdkR: s/x86-64/{x86,x86-64}
03:15 HdkR: Mind you, that's not a good experience in the best of times :D
03:15 mattst88: (https://gitlab.freedesktop.org/gstreamer/orc is what I'm referring to, not to be confused with llvm's orcjit)
03:18 HdkR: With all the pains that LLVM causes at runtime, it's still less painful than writing an optimizing JIT that supports near as many platforms and generates as good of code.
03:20 jenatali: Yeah WARP supports x86 (32-bit and 64-bit) and aarch64
03:24 jenatali: One of the nice things is that, because it's custom, it's able to be trivially enlightened and understand arm64ec to generate aarch64 JIT in an emulated x86-64 process
03:24 jenatali: I wish its high-level IR was as nice as nir though :(
03:24 jenatali: I also wish I was able to open-source it
03:33 airlied: warp vs proton/lavapipe benchmarks :)
03:38 HdkR: jenatali: If users are to be believed, Arm64 is deprecated garbage, RISC-V is now the standard ISA to support.
03:38 jenatali: airlied: I'd be very interested. Haven't gotten a chance
04:20 japanreflection: ORC i have met, it's rather exotic rare fabric. Where all DLX/ALPHA/MIPS/SPARC are rare, MIPS is most used in netowrking routers and such. Never used any of those. But ARM as RISC was commercialization of such processors, i had studied all types of the in detail. Now AVX-XXXX was always boldly and courageously wrong idea to be stuffed into the hardware, however on a stackless or
04:20 japanreflection: registerless architecture, there is no big problems to simulate or emulate those. However i have understood that for commodity OS such code would just be too performant. So is there something to talk at all, likely not anymore, we could rant all day that all fences, locks,marriers,semaphores usage is bad design on any of those chipsets. But the modernization of linux is big project,
04:20 japanreflection: cause linuxes source code is out of hands big tree, but it is supported well these, days but having gazillions of vulnerabilities due to just the bad or good design to be able to surveillance people, i won't even argue for the need to do that, because some people just need to live behind bars! Simply cause their actions aren't perceived as needed ones (tyran criminals incapable
04:20 japanreflection: narcissists), i saw too many of such devils in foreign countries too. So opencl 1.2 grabbed from BOYI documentation that supports all ways of all opencl specifications already implemented in all ways possible to translate and backward compliance behind is actually the real one that matches hw and correct design the best. As to how much i complain is nonsense, you may decide and did
04:20 japanreflection: implement all of the specs as always, so when i complain which i have not done over your works, things must be very very bad which is the dominant case elsewhere of programming often.
04:20 japanreflection: But the thing is, i have not complained over programming states, or so.
09:28 MTCoster: I'm hoping there's some dim users on atm
09:29 MTCoster: My usual workflow is: dim b4-shazam/tests+checks/dim push/b4 ty. Works great usually. Today I've got a patch that doesn't apply cleanly via git-am (though patch deals just fine). Is there a "correct" way of handling this, or should I just go ahead and manually reproduce the steps dim b4-shazam would take after manually applying the patch?
09:34 javierm: MTCoster: usually what I do is to fix the patch and then cat fixed-patch | dim apply
09:35 javierm: dim apply will add the Link: tag, etc. So not all the checks that b4-shazam does but you could manually check the patch with checkpatch --strict (which AFAIK is what b4-shazam does too)
09:36 javierm: MTCoster: or you could ask the author to re-send so that it applies cleanly, or if is your patch to re-send so that b4-shazam can pick it via git-am
09:39 MTCoster: javierm: Thanks! cat+dim apply sounds good, will give that a try. Do you know if there's an easy way to tell b4 about the patch or am I better off just sending a manual thanks?
09:43 MTCoster: Actually I know exactly what the commit is that caused the patch to break, is there an equivalent to --merge-base I can pass to b4 without using --merge?
09:46 javierm: MTCoster: I'm not that familiar with b4 to answer your questions, sorry
09:46 javierm: I'm a patman user :)
09:47 MTCoster: javierm: Fair enough, thanks for the dim help anyway!
12:08 ukleinek: MTCoster: b4 am -3 + git am -3 is usually helpful, don't know if dim and b4-shazam support that
13:40 alyssa: jenatali: why does being custom have to do with the arm64ec issue?
13:41 alyssa: an arm64x build of llvmpipe/lavapipe would also generate native arm64 jit in an emulated x86-64 process..
13:42 jenatali: Not without explicitly adding code to do that, no
13:42 alyssa: why not?
13:42 jenatali: Which, I guess LLVM could have that code but being custom meant it could be added as arm64ec was designed
13:43 alyssa: (AFAIK, it would if run via wine/arm64ec, so I assumed native code is the same)
13:43 jenatali: Arm64ec sets the preprocessor defines for x86-64 and arm64ec, not arm64
13:43 alyssa: oh but there's extra thunking involved with wine, right ok
13:44 jenatali: And then arm64x is building the code twice and essentially zipping it together
13:45 alyssa: (:
13:48 jenatali: I think FEX (Linux) and Prism (Windows) do things a bit differently, assuming I'm even thinking about the right emulation that's used for wine
13:50 jenatali: Anyway the Windows approach only has a fully native kernel. Everything in user space needs to target either the original architecture (x86) or a special emulation arch
13:53 jenatali: The emulation arch essentially has thunking around native code, yeah
14:03 jenatali: Mis012: apps can compile themselves as arn64ec to load x86 dlls, or x86 apps can load arm64ec dlls. All system dlls have arm64ec code streams
14:05 jenatali: When arm64ec code calls arm64ec code they detect the thunk and skip to the native code
14:19 HdkR: jenatali: FEX reuses arm64ec/arm64x stuff for wine. Since it uses the same interface and can replace XTA/Prism on Windows.
14:20 HdkR: It's a nice robust solution that microsoft chose, no need to reinvent it.
14:21 HdkR: There was a similar solution to arm64x proposed to Linux over a decade ago and it was rejected sadly.
14:24 jenatali: Womp womp
14:25 alyssa: jenatali: I think the disconnect for me is that with fex/wine/arm64ec, gl&vk are "special"
14:25 alyssa: wine includes arm64ec dll's that thunk out to the native arm64-not-EC .so's
14:25 alyssa: so lavapipe doesn't need to know about arm64ec, since wine is hiding that detail
14:25 jenatali: Ah I see
14:26 jenatali: Yeah on Windows only the kernel is native
14:27 alyssa: yeah the distinction for us is that any windows code is arm64ec but any linux code is arm64
14:27 alyssa: so like, a d3d game will call into an arm64ec dxvk dll but use a linux arm64 mesa
14:34 jenatali: Yeah, for us, all app code is x86 (typically) while system userspace is arm64ec and kernel is arm64 native. Even arm64 graphics drivers are arm64x. Fortunately only one vendor (and WARP)
14:38 alyssa: entertaining
14:38 alyssa: I kinda wonder what the perf implication is there
14:42 jenatali: I think overhead is quite low, but I'm not on the Prism team so 🤷
14:45 HdkR: jenatali: But what about /lower/ overhead? :P
14:48 HdkR: I'm over here complaining about a potential couple millisecond/frame of CPU overhead in Civilization 6
20:14 cheako: I'm trying to build 25.1-rc1 and I'm getting https://dpaste.com/2ZRJT6T39
20:15 cheako: rust on this system is fine, there is a default and it's also available in /usr/bin.
20:24 cheako: for some reason `echo nightly >> /home/cheako/src/rust-toolchain` fixed it.
20:31 psykose: the error message shows that there isn't a default and so it wasn't fine though
20:59 cheako: The error is wrong, the instructions didn't solve anything.
21:26 cheako: setting `rust-toolchain` to stable did work, something didn't like the non-numeric part of a nightly build number.
21:26 karolherbst: maybe some version check somewhere?
21:26 karolherbst: cheako: ohh.. that's a failure inside rustup
21:30 cheako: yeah, it's because I'm taking the high road. I don't want my gaming environment to have build tools, so I'm trying to generate deb packages with dpkg-buildpackage and something in it's environment is blocking access to my rustup settings... like if it unsets HOME.
23:21 cheako: I built 25.1.0-rc1 and installed it, but now vkcube works... but steam games don't. It looks as though steam is loading the same icd. I'm double checking things, trying to find if it's my i686 hack with the version numbers.