<phasta>
Does anyone here know how amdgpu pairs up with its cards? I looked at amdgpu_drv.c's section with the PCI IDs, and it seems they haven't added new IDs in years… do they have a catch-all ID or something like that?
<phasta>
I think it's in amdgpu_drv.c line 2139 following where they set up a catch-all and then do IP magic
* phasta
doesn't like IP magic
JRepin has quit []
JRepin has joined #dri-devel
vsro has joined #dri-devel
<MrCooper>
not sure what you mean by "IP magic"; this compares the HW configuration to what the driver can actually support, would you prefer it to roll a dice or something? ;)
<kobboi>
MrCooper: awesome, I had encountered this same coredump already some weeks ago (although the side effect was different at the time) but there was no bug about it yet and I did not have the time to do anything with it (other than downgrade mesa). So I should have checked again for an existing bug. Thanks!
<phasta>
MrCooper, just register the actual PCI device IDs. This way it becomes totally obvious what hardware the driver is actually supposed to support
<MrCooper>
phasta: you're assuming a 1:1 mapping between PCI IDs and HW configurations, which doesn't exist for newer AMD GPUs
hansg has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
JRepin has quit []
JRepin has joined #dri-devel
<DemiMarie>
MrCooper: isn't that deprecated in favor of modesetting?
kobboi has quit [Remote host closed the connection]
bolson has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
<Ermine>
so... all new cards have the same id?
<Ermine>
all new amd cards that is
JRepin has quit []
JRepin has joined #dri-devel
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
knurd has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
vsro has quit [Ping timeout: 480 seconds]
<knurd>
Lo! Is it possible to install mesa's vulkan drivers in a separate directory (say /usr/lib64/dri-freeworld) and then make the Linux install use those by default (e.g. instead of the ones from the distro) using just drop-in files?
Mis012[m] has joined #dri-devel
<Mis012[m]>
magic is the opposite of having self-describing hw, obviously the benefit of ugly magic where the kernel has to have everything hardcoded is that you don't need to rely on dumps from people with the hw to get the full picture
<knurd>
Touching the distro's driver/icd files nor using the environment variables like VK_DRIVER_FILE are options for what I want to do: provide mesa-vulkan-driver add-on packages for fedora
<knurd>
that contain vulkan drivers supporting hw video acceleration for patent encumbered codecs.
<knurd>
But I did not manage to make the system use it by default; to my untrained eyes it looks like libVkLayer_MESA_device_select.so reorders things and prefers the distro's vulkan driver.
frieder has quit [Ping timeout: 480 seconds]
Turkish-Men has quit [Remote host closed the connection]
vsro has joined #dri-devel
feaneron has joined #dri-devel
frieder has joined #dri-devel
vsro has quit [Remote host closed the connection]
davispuh has joined #dri-devel
<MrCooper>
Ermine: not all the same, not all unique ones though
fab has quit [Quit: fab]
sima has joined #dri-devel
kzd has joined #dri-devel
<alyssa>
unrolling a loop fixes a CTS test with lavapipe
<alyssa>
this does not spark joy (:
<zmike>
🤕
<alyssa>
umm... can someone with an x86 machine try a branch for me real quick?
<alyssa>
alyssa/mesa:gallivm-brokenness with lavapipe cts test dEQP-VK.ray_tracing_pipeline.watertightness.0.65536
<alyssa>
it's RT pipelines which means the diff is... large..
<zmike>
you won't believe this
<zmike>
but I don't have you in my remotes
<zmike>
are we even developer friends?
<zmike>
oh no it was just on one machine
<zmike>
alyssa: it passes before/after your branch for me
heat has joined #dri-devel
<alyssa>
extreme clown moment
<alyssa>
so this is breaking with my brnach.. only on arm64 then..? *melts*
<alyssa>
konstantin: passes with your loop limiter change cherry-picked
<alyssa>
can i go bed to sleep now
fab has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
ahmadraniri has joined #dri-devel
Fijxu has quit [Ping timeout: 480 seconds]
<stsquad>
when it comes to device memory allocated for native-context is that TTM or the driver that does it? I want to try an experiment to see if improving alignment helps
Fijxu has joined #dri-devel
dolphin has quit [Quit: Leaving]
ahmadraniri has quit [Remote host closed the connection]
<agd5f>
phasta, amdgpu claims all devices with VID=0x1002 and VGA and Display PCI classes. Then we read the IP discovery table from the device to determine if a device is supported or not. See amdgpu_discovery.c
<jenatali>
mareko: Re: glthread: I think the WGL frontend doesn't have glthread hooked up yet. I don't think there's a reason not to do it, it just hasn't been a priority yet. So we either need to hook that up or else just make sure we don't break non-glthread
<jenatali>
If Linux is trending towards glthread then we should probably enable it for WGL just so we don't get divergence that makes hard-to-investigate bugs
<agd5f>
phasta, specifically amdgpu_discovery_set_ip_blocks() for how we match ip blocks
phasta has quit [Ping timeout: 480 seconds]
FireBurn has quit [Ping timeout: 480 seconds]
<alyssa>
pendingchaos: metadata validation has significantly regressed vtn_bindgen2 performance in debug builds of mesa (== dev build times), profiling shows vtn_bindgen2 is entirely nir_validate bound and reverting the metadata/dominance validation commits helps a ton
<alyssa>
is there any low hanging optimization fruit in nir_validate for the new metadata stuff?
<alyssa>
should we necessarily be validating everything after every pass? IDK the answers to these
vlmx has joined #dri-devel
vlmx has left #dri-devel [#dri-devel]
<guludo>
jani: uh-oh... Looks like dim rebuild-tip -d doesn't work as I expected (it appears I need to use -d before rebuild-tip).
<jani>
guludo: all dim parameters go right after 'dim'
<guludo>
I realized that now... Sorry.
<guludo>
ah, thankfully it appears rebuild-tip doesn't use the local drm-intel-next.
<guludo>
so I guess, hopefully, no harm was done? I just ended up pusing a new drm-tip with the same trees as the previous one?
<guludo>
because I did not use the local branch positional arg... I guess I was lucky
imperial has joined #dri-devel
<jani>
yeah, dim is a bit dim
Duke`` has joined #dri-devel
k4noi has quit [Ping timeout: 480 seconds]
<guludo>
now I used dim -d rebuild-tip drm-intel-next and build-tested locally; then used dim push.
mehdidjait[m] has quit [Ping timeout: 480 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
colinmarc has quit [Ping timeout: 480 seconds]
kos_tom has quit [Ping timeout: 480 seconds]
mehdidjait[m] has joined #dri-devel
alicia1 has quit [Ping timeout: 480 seconds]
tomeu has quit [Ping timeout: 480 seconds]
samueldr has quit [Ping timeout: 480 seconds]
wv[m] has quit [Ping timeout: 480 seconds]
Mis012[m] has quit [Ping timeout: 480 seconds]
kusma has quit [Ping timeout: 480 seconds]
dabrain34backJan6th[m] has quit [Ping timeout: 480 seconds]
Coelacanthus[m] has quit [Ping timeout: 480 seconds]
QiuWenboAwaytilltheendofChines has quit [Ping timeout: 480 seconds]
x512[m] has quit [Ping timeout: 480 seconds]
DemiMarie has quit [Ping timeout: 480 seconds]
dcbaker has quit [Ping timeout: 480 seconds]
zzoon_back_on_27th_Jan[m] has quit [Ping timeout: 480 seconds]
readerman[m] has quit [Ping timeout: 480 seconds]
lucaceresoli[m] has quit [Ping timeout: 480 seconds]
dafna33[m] has quit [Ping timeout: 480 seconds]
jenatali has quit [Ping timeout: 480 seconds]
Newbyte has quit [Ping timeout: 480 seconds]
reedhhw[m] has quit [Ping timeout: 480 seconds]
orowith2os[m] has quit [Ping timeout: 480 seconds]
chema has quit [Ping timeout: 480 seconds]
dtgs[m] has quit [Ping timeout: 480 seconds]
dadamnss[m] has quit [Ping timeout: 480 seconds]
<jani>
I've never used dim -d myself. if the patch applied to drm-tip during CI and to an individual branch while merging, it's extremely unlikely to cause problems
<jani>
unless there's a long time between the two
<vsyrjala>
i usually do 'dim -d rebuild-tip + build test' after resolving a conflict
kano has joined #dri-devel
<jani>
I avoid applying patches that conflict ;)
<pendingchaos>
I'm not aware of any low hanging fruit
<pendingchaos>
and I think validating after each pass is generally best, since a later pass could hide the issue before the next validation
imperial has quit [Ping timeout: 480 seconds]
imperial has joined #dri-devel
<demarchi>
jani: when applying a big patch series, I don't want to be caught by surprise, **after pushing**, that a merge failed
<demarchi>
jani: so I usually do "dim -d rebuild-tip drm-xe-next"
<jani>
demarchi: yeah I get that too
<demarchi>
so it uses my local drm-xe-next branch just to check if it will be able to merge everything
mbrost has joined #dri-devel
<demarchi>
guludo: I wouldn't say lucky... I added a check for that on purpose ;)
kano has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
<rodrigovivi>
this one requires ack from you or dave since it touches include/drm right? or ack from drm-misc maintainers is enough?
<alyssa>
karolherbst: definitely the current model of shader global vars for scratch is not what we want
<alyssa>
although I don't know exactly what is
calligraphytest has joined #dri-devel
calligraphytest has quit [Remote host closed the connection]
Hazematman has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah...
<karolherbst>
from a "everything is inlined" perspective it works well enough, but once we move away from that......
QiuWenboAwaytilltheendofChines has joined #dri-devel
<karolherbst>
I still have to figure out CL global vars in the global address space and believe me, that's a mess on an entire different level 🙃 I honestly don't know what they were thinking with that one...
calligraphytest has joined #dri-devel
rasterman has quit [Remote host closed the connection]
<alyssa>
what's the problem there, other than thread safety?
DemiMarie has joined #dri-devel
DemiMarie is now known as Guest7166
<calligraphytest>
so tbh. i am writing the compiler soon for this mode executing things in new format and i no longer describe in depth as to how that plays out. in other words i am planning on leaving you now finally. it never looked that dwfreed understood what is he arranging, i never threattened anyone before the bombs landed my way, and in depth i described to david airlie as how much “real” info
<calligraphytest>
estonian scammers provide i.e than its lot saner to inspect mickey mouse asshole with apetite than listen to what fraud estonians have been up doing at.
calligraphytest has quit [Remote host closed the connection]
calligraphytest has joined #dri-devel
calligraphytest has quit [Remote host closed the connection]
<sima>
rodrigovivi, drm-misc is enough but ack
<rodrigovivi>
thank you
Hazematman has joined #dri-devel
Hazematman has quit []
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
<yrlf>
quick DMA-BUF question: if I create a DMA-BUF with gbm_bo_create, and the underlying DMA-BUF will be kept alive as long as I have a valid fd to it, right?
<yrlf>
i.e. I can gbm_bo_destroy() it as soon as I have another fd to it and I have effectively "exported" it out of libGBM
<emersion>
yeah
<emersion>
GEM handles also keep a refcount
<yrlf>
great, thanks
<yrlf>
currently trying to clean up the mess I have in wl-mirror, finally trying to get the DMA-BUF details right
frankbinns has joined #dri-devel
Kayden has quit [Ping timeout: 480 seconds]
heat is now known as Guest7169
heat has joined #dri-devel
Guest7169 has quit [Read error: No route to host]
pjakobsson has quit [Ping timeout: 480 seconds]
Calandracas_ has joined #dri-devel
Calandracas has quit [Read error: Connection reset by peer]
zzoon_back_on_27th_Jan[m] has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
Hazematman has joined #dri-devel
kano has joined #dri-devel
pjakobsson has joined #dri-devel
Hazematman has quit []
apinheiro has joined #dri-devel
imperial has quit [Ping timeout: 480 seconds]
<mareko>
alyssa: scratch is only for spilling, though if you have function calls, you need it to work like stack
<alyssa>
mareko: I'm talking about nir's load/store_scratch intrinsics
<mareko>
that's just for spilling
<alyssa>
nope :(
<mareko>
and indirect indexing emulatino
<alyssa>
..and function temps in OpenCL (`private`)
<mareko>
isn't that just indirect indexing
lucaceresoli[m] has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
<austriancoder>
daniels: if you have time to talk about what's needed to land !3418 - feel free to ping me or leave a comment in the MR
feaneron has joined #dri-devel
kano is now known as Guest7174
epoch101 has quit []
dafna33[m] has joined #dri-devel
eukara has quit []
jenatali has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
Hazematman has joined #dri-devel
Hazematman has quit []
Hazematman has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
fab has quit [Quit: fab]
airlied has joined #dri-devel
orowith2os[m] has joined #dri-devel
paulk-bis has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
jernej has quit [Read error: Connection reset by peer]
jernej has joined #dri-devel
feaneron has quit [Read error: Connection reset by peer]
feaneron_ has joined #dri-devel
chema has joined #dri-devel
dtgs[m] has joined #dri-devel
dadamnss[m] has joined #dri-devel
eukara has joined #dri-devel
Kayden has joined #dri-devel
dcbaker has joined #dri-devel
Eighth_Doctor has joined #dri-devel
tanty has quit [Remote host closed the connection]
JRepin has quit []
alicia1 has joined #dri-devel
tanty has joined #dri-devel
kusma has joined #dri-devel
guludo has quit [Quit: WeeChat 4.5.1]
Newbyte has joined #dri-devel
x512[m] has joined #dri-devel
reedhhw[m] has joined #dri-devel
dabrain34backJan6th[m] has joined #dri-devel
Coelacanthus[m] has joined #dri-devel
<karolherbst>
alyssa: sooooooo CL global vars are global to the _program_ not individual kernels, so it shares the content across kernel invocations and everything + it supports initializers, so you need to initialize it after compilation, not on a queue. worse, the initializer can depend on the address of the global var + any deref chain based on it
apinheiro has quit [Quit: Leaving]
<karolherbst>
which means... specconstantops can be derefs
<karolherbst>
which means it's not a constant
<karolherbst>
which means.. I need to be able to spill spec constant op chains to an initialization kernel 🙃
<karolherbst>
it's horrible
<karolherbst>
though...
<karolherbst>
an alternative approach would be, that I reserve an address and pass it into spirv_to_nir, but then I'd have to do deref chain resolving in spirv_to_nir and not in lower_io 🙃
<karolherbst>
this feature is just cursed
<jenatali>
karolherbst: The spec says initialization can happen on first-enqueue of any kernel from the program
<karolherbst>
and the only benefit is, that you don't have to bind a buffer containing that global state...
<karolherbst>
jenatali: sure, but what if you have 5 enqueues on 5 threads
<karolherbst>
on different queues
<jenatali>
Serialize 'em
<karolherbst>
well...
<karolherbst>
I'd prefer not to
<karolherbst>
but yeah.. I could
<karolherbst>
doesn't really change much because that's not the hard problem
<jenatali>
Heh sure
<karolherbst>
the hard problem is the specconstantop situation
<jenatali>
Yeah that's gnarly
<karolherbst>
I liked my idea with passing in the address, but then later I noticed: wait... there are deref chains on top
<karolherbst>
I have a prototype for it, but I hate it
<karolherbst>
(spilling the constant op chains to an init kernel that is)
<karolherbst>
it's just sad that 1. generic_address_space CTS testing _requires_ this feature
<karolherbst>
and generic_address_space is required by adapticecpp