ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<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
anholt_ has quit [Ping timeout: 480 seconds]
<jenatali>
Company : The DX Control Panel or its cmdline replacement have force-warp options
<jenatali>
You can also go into device manager and just disable your GPU
<Company>
huh, then why do those tutorials all need it?
<jenatali>
It's easier to do a command line parameter or tweak a build config sometimes
<Company>
anyway, thx for telling me about d3dconfig
<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
JRepin has joined #dri-devel
<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
* jenatali
shrugs
<jenatali>
Today I got my first shaders compiled with 16-wide waves using AVX512, so that was fun
djbw has joined #dri-devel
djbw_ has quit [Ping timeout: 480 seconds]
krh has quit [Quit: Connection closed for inactivity]
<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
<airlied>
but I think for compute shaders llvmpipe might be okay
<jenatali>
airlied: I verified vertex, pixel, and compute, but haven't tried the more exotic ones yet. In theory I ported it all though
<jenatali>
I'm proud considering it's a completely custom instruction emitter that didn't even know about AVX last year
epoch101 has joined #dri-devel
<airlied>
as much as I dislike LLVM I think I dislike that more :-)
<jenatali>
Yeah. Pros and cons. It's lightweight for sure
djbw has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
djbw has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
epoch101 has joined #dri-devel
<mareko>
well, NIR could have an x86 backend
<airlied>
it totally could, but you have to deal with all the pains of avx512
<airlied>
it's why we ripped out the sse backend we used to have, because expanding it to avx2 and beyond was painful
<airlied>
we've even looked for alternate JITs but nobody really supports vectors all that well
<airlied>
and then you have to deal with non-x86
<mareko>
where llvmpipe doesn't run
<mareko>
NIR -> ARM bytecode
<airlied>
llvmpipe works on arm, riscv fine
<airlied>
power and s390
<mattst88>
I hear "orc" is a thing, but I don't know how good it is
<HdkR>
I have some users that even run llvmpipe->x86-64->arm64, bonkers.
<HdkR>
s/x86-64/{x86,x86-64}
<HdkR>
Mind you, that's not a good experience in the best of times :D
<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.
<jenatali>
Yeah WARP supports x86 (32-bit and 64-bit) and aarch64
<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
<jenatali>
I wish its high-level IR was as nice as nir though :(
<jenatali>
I also wish I was able to open-source it
sguddati has joined #dri-devel
<airlied>
warp vs proton/lavapipe benchmarks :)
<HdkR>
jenatali: If users are to be believed, Arm64 is deprecated garbage, RISC-V is now the standard ISA to support.
<jenatali>
airlied: I'd be very interested. Haven't gotten a chance
Daanct12 has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
japanreflection has joined #dri-devel
sguddati has joined #dri-devel
<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
<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,
<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
<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
<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.
<japanreflection>
But the thing is, i have not complained over programming states, or so.
gnuiyl has quit [Remote host closed the connection]
mangodev has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.6.1]
kts has quit [Ping timeout: 480 seconds]
mangodev has quit [Quit: WeeChat 4.6.1]
sguddati has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Daanct12 has joined #dri-devel
cborah has joined #dri-devel
coldfeet has joined #dri-devel
sguddati has joined #dri-devel
Duke`` has joined #dri-devel
glennk has joined #dri-devel
epoch101 has quit []
sguddati has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
mehdi-djait3397165695212282475 has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
jsa1 has joined #dri-devel
japanreflection has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
ADS_Sr_ has joined #dri-devel
fab has quit [Quit: fab]
ADS_Sr has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
phasta has joined #dri-devel
sguddati has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jsa1 has joined #dri-devel
jkrzyszt_ has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jsa1 has joined #dri-devel
mvlad has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
hgirotra has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
tejasupa has joined #dri-devel
sguddati has joined #dri-devel
rjodin has joined #dri-devel
gnuiyl has joined #dri-devel
apinheiro has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
tejasupa has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
sguddati has quit [Ping timeout: 480 seconds]
amarsh04 has quit []
jkrzyszt has joined #dri-devel
jsa1 has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
hgirotra_ has joined #dri-devel
rama has joined #dri-devel
hgirotra_ has quit []
xvf has joined #dri-devel
xvf has left #dri-devel [#dri-devel]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
hgirotra has left #dri-devel [#dri-devel]
hgirotra has joined #dri-devel
<MTCoster>
I'm hoping there's some dim users on atm
<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?
kts has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
<javierm>
MTCoster: usually what I do is to fix the patch and then cat fixed-patch | dim apply
<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)
<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
<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?
kts has joined #dri-devel
<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?
<javierm>
MTCoster: I'm not that familiar with b4 to answer your questions, sorry
<javierm>
I'm a patman user :)
<MTCoster>
javierm: Fair enough, thanks for the dim help anyway!
hgirotra_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
Lynne has quit [Remote host closed the connection]
Lynne has joined #dri-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #dri-devel
Lynne has quit [Remote host closed the connection]
kts has joined #dri-devel
Lynne has joined #dri-devel
guludo has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
<ukleinek>
MTCoster: b4 am -3 + git am -3 is usually helpful, don't know if dim and b4-shazam support that
hgirotra has quit [Remote host closed the connection]
gnuiyl_ has joined #dri-devel
gnuiyl has quit [Ping timeout: 480 seconds]
u-amarsh04 has joined #dri-devel
warpme has joined #dri-devel
fab has quit [Quit: fab]
kts has quit [Ping timeout: 480 seconds]
alarumbe has joined #dri-devel
odrling has quit [Remote host closed the connection]
odrling has joined #dri-devel
fab has joined #dri-devel
mripard has joined #dri-devel
warpme has quit []
Daanct12 has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Remote host closed the connection]
<alyssa>
jenatali: why does being custom have to do with the arm64ec issue?
<alyssa>
an arm64x build of llvmpipe/lavapipe would also generate native arm64 jit in an emulated x86-64 process..
<jenatali>
Not without explicitly adding code to do that, no
<alyssa>
why not?
<jenatali>
Which, I guess LLVM could have that code but being custom meant it could be added as arm64ec was designed
<alyssa>
(AFAIK, it would if run via wine/arm64ec, so I assumed native code is the same)
<jenatali>
Arm64ec sets the preprocessor defines for x86-64 and arm64ec, not arm64
<alyssa>
oh but there's extra thunking involved with wine, right ok
JRepin has quit []
<jenatali>
And then arm64x is building the code twice and essentially zipping it together
<alyssa>
(:
Mis012[m] has joined #dri-devel
epoch101 has joined #dri-devel
apinheiro has quit [Quit: Leaving]
<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
<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
epoch101_ has joined #dri-devel
<jenatali>
The emulation arch essentially has thunking around native code, yeah
epoch101 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
kzd has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
<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
<jenatali>
When arm64ec code calls arm64ec code they detect the thunk and skip to the native code
epoch101 has quit [Ping timeout: 480 seconds]
haaninjo has joined #dri-devel
warpme has joined #dri-devel
<HdkR>
jenatali: FEX reuses arm64ec/arm64x stuff for wine. Since it uses the same interface and can replace XTA/Prism on Windows.
<HdkR>
It's a nice robust solution that microsoft chose, no need to reinvent it.
tango_ has quit [Ping timeout: 480 seconds]
<HdkR>
There was a similar solution to arm64x proposed to Linux over a decade ago and it was rejected sadly.
<jenatali>
Womp womp
<alyssa>
jenatali: I think the disconnect for me is that with fex/wine/arm64ec, gl&vk are "special"
<alyssa>
wine includes arm64ec dll's that thunk out to the native arm64-not-EC .so's
<alyssa>
so lavapipe doesn't need to know about arm64ec, since wine is hiding that detail
<jenatali>
Ah I see
<jenatali>
Yeah on Windows only the kernel is native
davispuh has joined #dri-devel
<alyssa>
yeah the distinction for us is that any windows code is arm64ec but any linux code is arm64
<alyssa>
so like, a d3d game will call into an arm64ec dxvk dll but use a linux arm64 mesa
Kayden has joined #dri-devel
<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)
<alyssa>
entertaining
<alyssa>
I kinda wonder what the perf implication is there
feaneron has quit [Read error: No route to host]
feaneron has joined #dri-devel
tango_ has joined #dri-devel
<jenatali>
I think overhead is quite low, but I'm not on the Prism team so 🤷
rasterman has quit [Quit: Gettin' stinky!]
<HdkR>
jenatali: But what about /lower/ overhead? :P
<HdkR>
I'm over here complaining about a potential couple millisecond/frame of CPU overhead in Civilization 6
bolson has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
warpme has quit []
jsa1 has joined #dri-devel
dsimic is now known as Guest14324
dsimic has joined #dri-devel
Guest14324 has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
olivial has quit [Read error: Connection reset by peer]
<cheako>
rust on this system is fine, there is a default and it's also available in /usr/bin.
toponeyankee has joined #dri-devel
sravn has quit []
<cheako>
for some reason `echo nightly >> /home/cheako/src/rust-toolchain` fixed it.
<psykose>
the error message shows that there isn't a default and so it wasn't fine though
mvlad has quit [Remote host closed the connection]
djbw_ has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
<cheako>
The error is wrong, the instructions didn't solve anything.
jsa1 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
digetx has quit [Ping timeout: 480 seconds]
gfxstrand has quit [Ping timeout: 480 seconds]
Kwiboo has quit [Quit: .]
sravn has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
Kwiboo has joined #dri-devel
alane has quit [Remote host closed the connection]
alane has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
<cheako>
setting `rust-toolchain` to stable did work, something didn't like the non-numeric part of a nightly build number.
<karolherbst>
maybe some version check somewhere?
<karolherbst>
cheako: ohh.. that's a failure inside rustup
<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.
anholt_ has joined #dri-devel
gnarchie has joined #dri-devel
ity has quit [Quit: WeeChat 4.6.0]
Kayden has quit [Quit: Leaving]
Calandracas has joined #dri-devel
Calandracas__ has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit [Remote host closed the connection]
pcercuei has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
epoch101_ has joined #dri-devel
epoch101 has quit [Read error: Connection reset by peer]
larunbe has joined #dri-devel
guludo has quit [Quit: WeeChat 4.6.1]
alarumbe has quit [Read error: Connection reset by peer]
JLP has quit [Ping timeout: 480 seconds]
JLP has joined #dri-devel
larunbe has quit []
Kayden has joined #dri-devel
<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.