ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
YuGiOhJCJ has joined #dri-devel
<Company>
I have no idea what modifier is used actually - but I think libva doesn't return LINEAR
<Company>
NV12:0x100000000000002
shoragan has quit [Read error: Network is unreachable]
<kode54>
what does the PL in PL DOORBELL stand for?
<kode54>
since google is entirely useless and also wants to sell me video doorbells
kaiwenjon has quit [Quit: WeeChat 3.8]
<robclark>
alyssa: I think for all platforms.. it is in common .gitlab-ci stuff.. and AFAICT we aren't skipping wsi tests (premerge vk is fractional but we have full run for nightly)
simon-perretta-img has quit [Ping timeout: 480 seconds]
shoragan has joined #dri-devel
simon-perretta-img has joined #dri-devel
lstrano_ has joined #dri-devel
pH5 has quit [Read error: Network is unreachable]
dolphin has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
pH5 has joined #dri-devel
lstrano has quit [Ping timeout: 480 seconds]
dolphin has joined #dri-devel
<karolherbst>
alyssa: ever thought about implementing query_memory_info? I want drivers to do that in order to get rid of more compute pipe caps :D
shankaru has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
lstrano_ has quit [Remote host closed the connection]
apinheiro has quit [Quit: Leaving]
lstrano_ has joined #dri-devel
shoragan has quit [Quit: quit]
sukuna has joined #dri-devel
<alyssa>
karolherbst: it's in asahi/mesa now
sassefa has joined #dri-devel
<alyssa>
i think
<alyssa>
robclark: Hmm ok
riteo has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
shoragan has joined #dri-devel
<karolherbst>
ahh cool
<robclark>
seems like query_memory_info could be a common helper for at least all the arm uma type gpu's
<alyssa>
yeah, probably
<karolherbst>
well
<karolherbst>
except the avail ones
<alyssa>
I think I just copypasted freedreno
<karolherbst>
would you have to use os_get_available_system_memory for the avail memory?
<karolherbst>
*wouldn't
<karolherbst>
I hate how parsing `/proc/meminfo` is apparently the way of doing that
<alyssa>
probably in theory
shankaru has joined #dri-devel
<alyssa>
in practice i just wanted to fix steam's system info screen ;P
<karolherbst>
:D
<karolherbst>
I don't need avail anyway in rusticl
<robclark>
oh, I guess we have the silly thing were we limit some devices to 4G gpu va because of silly fw $reasons... but it wouldnt be too hard to impl a w/a for that (just need to make sure certain buffers don't straddle 4G)
<karolherbst>
I just do that in the frontend
<karolherbst>
ohh wait
<karolherbst>
you mean something else
<karolherbst>
gallium doesn't support single allocations bigger than 2G anyway
<karolherbst>
but that's not even covered with that interface
<robclark>
it's really about driver internal allocations.. some versions of fw fail at doing 64b math (sqe is basically 32b risc core thingy) which could cause problems if vsc draw stream straddles
<karolherbst>
oh no
<karolherbst>
that reminds me, I need to get my hands on some dev board so I can enable freedreno in rusticl and drop all that nir support code in clover :D
<robclark>
there are laptops too.. and I hear some nice ones will come out in the next month or so (but even the current x13s is nice)
<karolherbst>
mhhh
<karolherbst>
I don't need another laptop though :D
<kode54>
what is PL domain doorbell
<kode54>
or do I need to consult the kernel documentation offline
<robclark>
I've been using x13s as daily driver for upstream work for a year or so now... only drawback is now I don't have a convenient x86 laptop to build freedreno x86 for steam+fex :-P
<karolherbst>
but I think somebody promised me hardware :D
<karolherbst>
not quite sure
<karolherbst>
maybe it wasn't for freedreno
<karolherbst>
right..
<karolherbst>
but like.. I have a macbook air, which is a lot faster then the x13s :D
<kode54>
there is only one mention of "PL domain" in the entire kernel documentation folder, and it doesn't tell me what it means
<kode54>
I guess nobody who even uses the terminology knows what it means
<karolherbst>
but anyway... I just don't want to have a laptop taking away even more space, but a dev board is generally quite better to deal with, especially due to easier serial console access
<robclark>
x13s is faster than the kbl i7 xps13 that it replaced.. but not as fast as the macs.. the upcoming things should give the macs a run for their money.. but yeah, serial console is nice
<kode54>
I love opaque acronyms
<karolherbst>
being passive aggressive about won't help you getting an answer either
<alyssa>
robclark: ugh, yeah, I have been x86-free for years but tempted to get an x86 build machine just to deal with fex. Ironic, isn't it?
kxkamil2 has quit [Read error: Connection reset by peer]
<robclark>
heh, yeah
<karolherbst>
just use qemu-user
<karolherbst>
*hides*
Ryback_ has joined #dri-devel
<alyssa>
sounds.. unpleasant
<karolherbst>
it is
kxkamil2 has joined #dri-devel
<alyssa>
it is $current_year, why does cross compiling still suck
<karolherbst>
we have containers now, which made it suck less at least
<robclark>
admittedly fex is like the one case where I kinda think multiarch distro would make things easier
<karolherbst>
it's a fine idea in theory, but sadly we have none which is actually proper multiarch
<karolherbst>
but like the issue on macbooks specifically with fex and steam is the page size mess anyway, so that's kinda a huge problem anyway
<karolherbst>
so even if we get to proper multiarch distro, now we have to figure out using different page sizes :')
<robclark>
thankfully that is a problem I have to deal with ;-)
<robclark>
*not
<alyssa>
karolherbst: page size is a solved problem now
<karolherbst>
oh really?
<karolherbst>
you mean the micro vm thing or something else?
<alyssa>
yes
<alyssa>
I merged the mesa patches last week
<alyssa>
(into asahi/mesa I mean)
<karolherbst>
interesting
<alyssa>
robclark: ...so it is a problem you deal with ;P
<alyssa>
or a solution rather
<alyssa>
^^
<karolherbst>
given the micro VM solution didn't work for me (because full screen windows were busted and it overall was a giant mess) I'm delighted to know that this is a thing of the past and I can just use fex directly :D
<alyssa>
the microvm is the solution i mean
<karolherbst>
oh no
<alyssa>
it's trending in the direction of less of a mess :)
<alyssa>
current iteration shares your root filesystem, no container needed
<karolherbst>
ahh
<karolherbst>
though I think I mostly just had issues with window/cursor positions, so some games I couldn't put into window mode, because fullscreen was just a broken mess
<karolherbst>
maybe I shall try again the next time I feel the need wanting to play games while traveling
<robclark>
alyssa: qc things work fine with 4k pages, so not-my-problem ;-)
flynnjiang has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
<alyssa>
(;
<kode54>
sorry for being passive aggressive there
<kode54>
it's also entirely possible I was asking someone to break an NDA there, if they knew but could not answer, so that's fair to dodge
flynnjiang has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
flynnjiang has joined #dri-devel
Daanct12 has joined #dri-devel
rossy has quit [Remote host closed the connection]
rossy has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
sassefa has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
simon-perretta-img has joined #dri-devel
unerlige has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
aswar002 has quit [Read error: Connection reset by peer]
guludo has quit [Read error: Connection reset by peer]
pzanoni has quit [Read error: Connection reset by peer]
aswar002 has joined #dri-devel
guludo has joined #dri-devel
pzanoni has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
sassefa has joined #dri-devel
sassefa has quit [Remote host closed the connection]
sassefa has joined #dri-devel
mbrost has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
sassefa has quit []
mbrost has quit [Ping timeout: 480 seconds]
flynnjiang has quit [Remote host closed the connection]
epoch101 has quit []
guludo has quit [Quit: WeeChat 4.2.2]
kxkamil2 has quit [Read error: Connection reset by peer]
kxkamil2 has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
samuelig has quit [Quit: Bye!]
samuelig has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.2.2]
warpme has quit []
mbrost has joined #dri-devel
jsa has joined #dri-devel
warpme has joined #dri-devel
fab has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
mvlad has joined #dri-devel
vliaskov_ has joined #dri-devel
ungeskriptet is now known as Guest4474
ungeskriptet has joined #dri-devel
Guest4474 has quit [Ping timeout: 480 seconds]
pepp_ has left #dri-devel [#dri-devel]
iyes has joined #dri-devel
<MrCooper>
kode54: PL stands for "placement", AMDGPU_PL_ correspond to TTM_PL_
<kode54>
sorry I was so persistent about that
<MrCooper>
a doorbell is a HW mechanism involving special memory pages which can be mapped directly into user space, and then memory access triggers certain HW operations
<kode54>
I should read the DRM docs before I ask anything further
<kode54>
I know what a doorbell is vaguely
<kode54>
thanks for the explainer though
mwalle has joined #dri-devel
<kode54>
I recall seeing them being implemented in the Xe kernel driver
<kode54>
didn't stick around in Arc land long enough to see the Xe driver come to fruition though
vliaskov__ has joined #dri-devel
<kode54>
I tested that kernel patch, it seems to have fixed at least the stability issues I had with Resizable BAR disabled
<kode54>
but then I promptly re-enabled it
mripard_ has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
frankbinns1 has joined #dri-devel
mripard has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
adavy has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
mripard has joined #dri-devel
lynxeye has joined #dri-devel
mripard_ has quit [Ping timeout: 480 seconds]
sigmaris_ has joined #dri-devel
sigmaris has quit [Ping timeout: 480 seconds]
Calandracas_ has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
sigmaris has joined #dri-devel
zxrom has quit []
sigmaris_ has quit [Read error: Connection reset by peer]
pepp has joined #dri-devel
qyliss has quit [Quit: bye]
martink has quit []
qyliss has joined #dri-devel
qyliss has quit []
qyliss has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
iyes has joined #dri-devel
zxrom has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
hansg has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
pochu has quit [Quit: reboot]
pochu has joined #dri-devel
dviola has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
pekkari has joined #dri-devel
pekkari has quit []
ratheralone has joined #dri-devel
<karolherbst>
zmike: mhh, so I'm hitting an issue with zink, but I'm not quite sure who's fault it is yet. The tldr is that I buffer_subdata cb0 before each launch_grid. What happens if I call buffer_subdata on the same buffer each time? Can I expect the content to be properly synchronized or should I use a different cb0 buffer for each launch_grid until I wait on the relevant fences?
<karolherbst>
(or use a different mehtod of making sure the buffer isn't in use anymore)
<zamundaaa[m]>
maybe I misunderstand the issue, but isn't this "just" a kernel bug that would have to be fixed in the kernel? Application code can't always know if different application code uses epoll on a file, right?
<pq>
that's what I'd say
<pq>
but apparently that would take significant work, and possibly reduce epoll's performance
<pq>
I hope that "eager beaver" Linus mentioned will materialize to fix things
yyds has quit [Remote host closed the connection]
willy has quit [Remote host closed the connection]
<ratheralone>
Zink or rather all API backbends should be written different, the compiler generates inefficient code, I am forking and splitting out from your terrorists, though you have not done those magical bits it's even better that way, I have the data and metadata format for hw agnostic code compressed format. Life is beautiful I do not know why you chose abuse. I got lots of work done in 20 years time, I branch off all my businesses
<ratheralone>
around this work, dmabuf is so and so, I already said it should be taught to deal with offloading compute. There are two regimes the source code is compressed into container and compiled into binary or can be harvested and generated from hw agnostic hash and compiled still with llvm. The other data is all structures that is compiled with llvm too they have direct generator to ansi c text or any language always. It's a decomp
<ratheralone>
ler kit called triton, that worries me , works with fuzzed binaries but some countries have sw license honoring turned into court practice. But in general I am stable programmer today already, it's just all my systems are intruded into and full of spyware. They treat dwfreed and all other terrorist scammers on those channels, you are too stupid bullies to avoid to get manhandled. My personal phone is magical Xiaomi a Chinese
<ratheralone>
model where Chinese deal with ROMs and security and a conflict with you is handled around their work heroics etc. so far they manage their phones sw extremely well.
<ratheralone>
But in general us based iphones and macs are good too.
guludo has joined #dri-devel
co1umbarius has joined #dri-devel
<ratheralone>
Overall dma controllers i.e dmac's yes have three modes polling, interrupt, and dma channel like true dma mode. I am short of time to land security fixes there, but those are not very efficient against military based systems in the end anyhow.
ratheralone was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
kts has joined #dri-devel
krumelmonster has joined #dri-devel
feaneron has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
adavy has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<jkhsjdhjs>
hey, I'm running arch linux and since I upgraded to linux 6.8.9 all applications that in any way use radeonsi crash very frequently, here is an excerpt of coredumpctl: https://bpa.st/raw/PVWQ I first thought that it must be a memory issue, so I ran memtest for 10 hours without errors. then I looked into the traces and because radeonsi appeared in all of them, downgraded mesa from
<jkhsjdhjs>
24.0.6 to 24.0.5 at first, with no change, applications were still crashing. finally I noticed that I updated linux on the fourth of may, which is when the crashes started occuring. since I downgraded to 6.8.8, I no longer experience any crashes. because radeonsi appears in all these traces, maybe you're already aware of such a kernel regression and can point me to the
<jkhsjdhjs>
corresponding mailing list thread? thanks in advance
itoral has quit [Remote host closed the connection]
sukuna has quit [Ping timeout: 480 seconds]
<karolherbst>
jkhsjdhjs: is this on a laptop?
<jkhsjdhjs>
nope, on a PC, 5800X3D / 6700XT
<karolherbst>
anyway "SIGBUS" basically means, that the kernel couldn't access memory in question, which might mean that something is fishy on the kernel side
<jkhsjdhjs>
yep, I also think so, as it is fine with linux 6.8.8, but not with 6.8.9
<zmike>
karolherbst: if it's the same buffer and you're doing subdata at the same offset then you need to barrier
<karolherbst>
zmike: I see
<karolherbst>
there is no way to do it in a non blocking way?
<zmike>
what do you mean by "non blocking" here
<karolherbst>
like not having to barrier at all
<karolherbst>
I really just want to launch a compute shader, update part of the buffer and the launch the same state again
<karolherbst>
like.. I'm updating a couple of bytes
<zmike>
needs a barrier
<karolherbst>
I know that e.g. nvidia gpus can do such updates from within their command buffers
<zmike>
there is no way around that
<karolherbst>
I'm wondering if there is a vulkan api for it
<zmike>
yes, nvidia is special
<karolherbst>
ahh
<karolherbst>
sad
<zmike>
if you clobber the whole buffer again you don't need a barrier because it will invalidate
<karolherbst>
I wonder what would be the better approach then besides slicing the buffer and barrier when I end up at the beginning
<zmike>
you need to overwrite the whole buffer
<zmike>
or use a new one
<karolherbst>
overwriting the whole buffer would block again, wouldn't it?
<zmike>
no because zink would internally discard it and create a new buffer
<karolherbst>
ahh
<karolherbst>
mhh
<zmike>
also stop using the term block for this
<karolherbst>
that sounds too driver specific to me
<zmike>
it's confusing and not what you mean
<zmike>
most drivers will do this
<zmike>
but you can manually trigger the effect with invalidate_resouce
<karolherbst>
invalidate_resouce?
<zmike>
it's a gallium hook
<zmike>
or just keep a stream uploader and use that
<zmike>
and upload -> bind -> upload -> bind
<karolherbst>
I don't find that hook name
<karolherbst>
ohh wait
<karolherbst>
missing r
<karolherbst>
right... don't really know what's the best approach here in terms of lowering CPU overhead
<zmike>
how big is the data
<karolherbst>
4k at most
<karolherbst>
or any other arbitrary number
<zmike>
I mean how big is the buffer in total
<karolherbst>
it's the buffer holding all inputs for a CL kernel (like think of it as a buffer holding all function arguments)
<karolherbst>
mhh
<zmike>
like could it be multiple megabytes?
<karolherbst>
no
<karolherbst>
I think I cap it at 64k
<karolherbst>
I query PIPE_SHADER_CAP_MAX_CONST_BUFFER0_SIZE and cap it
<karolherbst>
4k it seems
<karolherbst>
anyway
<karolherbst>
it's small
<zmike>
I mean it seems like just use a stream uploader
<zmike>
if you have issues with that and cpu overhead then you can try punting it to a thread with PIPE_MAP_UNSYNCHRONIZED for your subdata
<zmike>
i.e., manually create buffer + subdata all in thread
<karolherbst>
I see
<karolherbst>
the reason I moved to a buffer was to take PIPE_CAP_PREFER_REAL_BUFFER_IN_CONSTBUF0 into account, but maybe for those small ones I really shouldn't
<karolherbst>
but in the end it really just matters if a method harms GPU throughput or not when launching compute stuff back to back
<zmike>
if you don't honor that cap then you're just moving that work to the driver
<karolherbst>
(and updating the content)
<zmike>
and the driver is doing exactly what I described in its thread
<karolherbst>
ohh you mean I should use the stream uploader directly?
<zmike>
yes, as a first attempt that would be simplest
<zmike>
upload -> bind -> upload -> bind -> ...
<karolherbst>
right
<karolherbst>
yeah, maybe that's the best idea here actually
<karolherbst>
haven't considered it before
<karolherbst>
but anyway, this issue I'm hitting explains some of the flakes I was seeing with zink :)
<zmike>
seems so
<zmike>
I'm surprised you don't get flakes with radeonsi or any other gpu that has real vram
<karolherbst>
they could wait on the buffer
<zmike>
depends on the map flags you're using with subdata I think?
<karolherbst>
could be
<karolherbst>
or maybe I'm just lucky
<zmike>
I was lucky for a while
<karolherbst>
then you started zink?
<karolherbst>
wait
<karolherbst>
did you even start it
<karolherbst>
I'm bad with history
<zmike>
I didn't
<zmike>
but it's easy to be lucky when you only use intel igpus
* zmike
salutes
<karolherbst>
fair :D
<karolherbst>
yeah.. my testing I usually test native gallium + zink on CPU/Intel/AMD and sometimes nvidia if I swap the GPU
<zmike>
my experience is that stuff with nvidia "just works" unless it involves stencil or rebar
kts has joined #dri-devel
iyes has joined #dri-devel
hansg has quit [Quit: Leaving]
samuelig has quit []
kts has quit [Ping timeout: 480 seconds]
samuelig has joined #dri-devel
kj2 has quit [Remote host closed the connection]
rsalvaterra has quit [Remote host closed the connection]
kj2 has joined #dri-devel
rsalvaterra has joined #dri-devel
Calandracas_ has quit [Remote host closed the connection]
<kisak>
I've been seeing a fair bit of broad spectrum splatter caused by #3343 over here.
<kisak>
much more than is landing on the proper bug report.
<jkhsjdhjs>
pepp: thanks for linking me that! yes, sounds like it's exactly the same issue. the issue also mentions that 6.8.9 is affected, which I can confirm. I'm currently on 6.9.0-rc7 and it seems to be fine so far
<jkhsjdhjs>
nevermind, there we go again
<zmike>
DavidHeidelberg: okay I ran on icl just now in xwayland
<zmike>
Passed: 28/29 (96.6%)
<zmike>
Failed: 0/29 (0.0%)
<zmike>
Not supported: 1/29 (3.4%)
<zmike>
only the android one is skipped
kts has joined #dri-devel
tyalie has quit []
tyalie has joined #dri-devel
epoch101 has joined #dri-devel
iyes has quit [Remote host closed the connection]
Aura has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
epoch101 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
alice has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
alice has joined #dri-devel
sudeepd has joined #dri-devel
kzd has joined #dri-devel
mripard has quit [Remote host closed the connection]
alice has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
simon-perretta-img has quit [Read error: Connection reset by peer]
<cwabbott>
with "--renderer gl" refreshing is super-slow and typing on the keyboard is impossible, it sometimes (50% of the time) repeats a character dozens of times (like if debounce wasn't working)
<cwabbott>
I'll type "cd" in the terminal and get "cddddddddddddddddddd"
<DavidHeidelberg>
zmike: drop some msg into the MR, I guess if Tapali would ack it, we can try
<DavidHeidelberg>
while it's in mesa-git it shouldn't be problem, only when this won't get figured out before hitting the release
<DavidHeidelberg>
eventually we could even merge it and revert it before release if needed
<ManMower>
cwabbott: is it really display that's slow, or is input just being bursty? I've seen the mouse jump around but things like weston-simple-egl run smoothly at the same time. :/
<ManMower>
that key repeat thing will happen if weston doesn't get back to its main loop fast enough to catch the key break event before repeat starts. :/
<cwabbott>
ManMower: how would I run any commands to test anything with the key repeat thing?
<ManMower>
ssh in from another host. :(
<cwabbott>
is there a command to run something in weston from ssh?
<ManMower>
there's a readpixels to get the frame buffer, I have a hunch that's being ridiculously slow for you. I have no idea why though.
<ManMower>
you'd just set your WAYLAND_DISPLAY env var properly (probably to "wayland-1")
<ManMower>
weston's log is probably helpfully telling you that your cpu is too slow as well.
<cwabbott>
I don't see anything suspicious like that in the logs
<ManMower>
does "top" indicate that it's cpu bound?
<cwabbott>
I do see the cpu increase when I move the mouse, but only to like 20-30% on a few cpus