ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa>
nir-to-tgsi, you're up
* alyssa
drives to figure out how to force softpipe and not llvmpipe
stuarts has quit []
<alyssa>
GALLIUM_DRIVER=softpipe apparently
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<alyssa>
can't tell if radeonsi bug or weird intended asymmetry
mdroper has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
mbrost has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
<Kayden>
alyssa: here's a link to what dj-death was mentioning: https://gitlab.freedesktop.org/kwg/mesa/-/commits/compiler-lsc-opcode-blocks - sorry it's still a mess, but if you look at the patches with "intel/fs: Introduce new MEMORY_*_LOGICAL opcodes" and the next few, you'll get the idea (rest is bug fixes)
<alyssa>
eyes
<Kayden>
alyssa: I'm reworking the intel backend to not have 28 different opcodes for reading/writing memory, instead just having 1 (well, 3 - load/store/atomic), with lots of parameters for... typed/untyped/scratch/SLM? how many components? what kind of address? 64-bit pointer? 32-bit pointer? pointer to surface state? pointer directly to memory? image load with coordinates with components?
<alyssa>
neato
<Kayden>
and then just lowering that to the actual messages in a pass
<Kayden>
a couple things definitely struck me as odd in the NIR intrinsics, namely
<alyssa>
I'm scared of both your ISA and your backend so IDK if that's the right call but seems legit :D
<Kayden>
- we kind of duplicate the hell out of the atomics rather than parameterizing the type of thing
<Kayden>
- how are there no helpers for "is this a load?" "is this a store?" "is this an atomic?" given that there are switch statements 100 lines long to determine those things
<Kayden>
or even "is this an SSBO operation"
<alyssa>
uff, yeah
<alyssa>
In general I'd like to move a lot of that metadata out of switch statements and into nir_intrinsics.py and nir_opcodes.py
<alyssa>
but that's orthogonal to what I'm working on now
<alyssa>
which is a big enough rework that I'm not inclined to add another
<alyssa>
honestly this is just a warmup for the really big cross-tree NIR hell I have in store :~P
<Kayden>
looks like you've got two atomic intrinsics now with a parameter for what operation it is? one with swap (extra suorces), one for the others?
<Kayden>
that is way nicer :)
<Kayden>
alyssa: another thing you might be interested in for NIR patches... I was looking at nir_intrinsic_can_reorder the other day, and noticed it was hardcoding some intrinsics and assumptions
<T_X>
hi, I'm seeing some issues in Wine run games when VRAM usage gets higher than 95% of the available 8GB VRAM. and when GTT is starting to be used. mostly in DCS World, but also had this in No Man's Sky a few times after jumping from one solar system to another. anyone knowing what the current status of TTM or GEM for the opensource amdgpu driver is? (TTM and GEM would be able to track active vs. inactive
psykose has quit [Remote host closed the connection]
<T_X>
allocations and move it between VRAM and GTT accordingly, right?)
<T_X>
I'm also using an Thunderbolt 3 eGPU enclosure over a 40gbit/s USB4 port here, so I believe that makes GTT usage especially painful (/ making the game unusable) for me
<tomeu>
have started getting this error from bindgen after updating to fedora 38 (even if I use rustup):
<tomeu>
thread 'main' panicked at 'Not able to resolve vector element?: Continue', /home/tomeu/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.59.2/src/ir/ty.rs:1135:22
<tomeu>
any ideas?
<karolherbst>
how would people feel about requiring mesa to be rebuilt on every single update to clang?
<kode54>
would it be a kernel or userspace bug if all compositors I throw at this driver randomly cause render bugs such as geometry blinking out of existence for a few frames?
<kode54>
(Xe, not the atomics thing above)
* zmike
only reviews MRs with subscribed tags
<HdkR>
kode54: Both
<kode54>
and how the heck would I debug that?
<alyssa>
zmike: oh gah i forgot the bot doesnt tag draft MRs
<HdkR>
kode54: Get hired at Intel and learn the codebase :P
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<kode54>
I am so glad that VM_BIND got put on the back burner for i915, and that DG2 is a second class citizen in Xe
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
<sima>
kode54, it's actually kinda annoying because no vm_bind in i915 means it's much rougher to port to xe
<sima>
since you can't tell xe bugs from vm_bind bugs in the userspace
<sima>
plus lack of vm_bind does block some features you really want on vk for gaming
<pq>
smells like sarcasm, but where is it coming from...
mbrost has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
kzd has joined #dri-devel
<kode54>
sorry for the sarcasm
<kode54>
I'm just mildly annoyed
jkrzyszt has quit [Ping timeout: 480 seconds]
<kode54>
and I don't know how I can help
<kode54>
devs have the hardware
<kode54>
all I can do is throw unknown software at it
smiles_1111 has quit [Ping timeout: 480 seconds]
<HdkR>
i can understand how frustrating it is when realities don't match with expectations around video drivers.
<alyssa>
eric_engestrom: apinheiro: itoral: Any chance one of you is up for deleting code from nir-to-vir?
crabbedhaloablut has quit [Read error: Connection reset by peer]
<alyssa>
karolherbst: How about you for codegen?
crabbedhaloablut has joined #dri-devel
<apinheiro>
alyssa, you got me right now disconnecting
<apinheiro>
and itoral is already afk right now
<apinheiro>
but I will take a look later
<alyssa>
apinheiro: :+1: those patches are for after that MR settles and merges
<alyssa>
but would like to get all the drivers converted sooner than later
<apinheiro>
and then check if there is anyone of us avaiaiable for that
<alyssa>
:+1:
<alyssa>
thanks!
<apinheiro>
thanks to you for keeping us on the loop
<alyssa>
if so that just leaves r600/sfn as unclaimed
<alyssa>
and since Gert is away and that code has a bus factor of 1.. sigh
apinheiro has quit [Quit: Leaving]
smiles_1111 has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
sarahwalker has joined #dri-devel
alatiera has joined #dri-devel
mbrost has joined #dri-devel
mbrost__ has joined #dri-devel
fxkamd has quit []
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: yeah, should be trivial
<karolherbst>
more or less
mbrost__ has quit [Ping timeout: 480 seconds]
mdroper has joined #dri-devel
<alyssa>
:+1:
<alyssa>
will pencil you in for that
<alyssa>
zmike: how is deqp-gles31 + zink + radv + amdgpu drm-shim a valid way to debug a radeonsi crash on my macbook
kts has joined #dri-devel
<alyssa>
i mean it worked, gdb gave me the backtrace I needed
mszyprow has joined #dri-devel
<alyssa>
Incidentally, dEQP-GLES31.functional.image_load_store.early_fragment_tests.no_early_fragment_tests_depth crashes with zink + radv + RADV_DEBUG=llvm
<alyssa>
backtrace deep inside llvm
<alyssa>
going to guess that one's a wontfix
Haaninjo has joined #dri-devel
<daniels>
alyssa: Gert’s back
<alyssa>
daniels: Ooh, good to know :)
<alyssa>
After !22914 is merged can I borrow him for an hour of gfx r&d time then? ;-p
mbrost__ has joined #dri-devel
<jenatali>
alyssa: Think you'll be able to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22913? I think I can work around this bug by just running nir_opt_remove_phis in my backend before lower_returns, but it seems like this is the right fix
<jenatali>
Not sure what to do about that test though :(
kts has quit [Quit: Konversation terminated!]
<daniels>
alyssa: sure, he does r600 anyway, I’m sure he’ll be thrilled to have a community
<robclark>
alyssa: you could test more of mesa incl ntt (plus virglrenderer) if you used virgl -> vtest -> zink ->lavapipe
Daanct12 has quit [Remote host closed the connection]