sdutt has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Duke`` has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
mvlad has joined #dri-devel
kts has quit [Read error: Connection reset by peer]
jewins has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
anholt has quit [Server closed connection]
anholt has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
kisak has quit [Server closed connection]
kisak has joined #dri-devel
genpaku has quit [Server closed connection]
fab has quit [Quit: fab]
genpaku has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
ahajda has joined #dri-devel
aswarup_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
kts has joined #dri-devel
fab has joined #dri-devel
gio has joined #dri-devel
tursulin has joined #dri-devel
jkrzyszt has joined #dri-devel
srslypascal is now known as Guest1653
srslypascal has joined #dri-devel
Guest1653 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
Dr_Who has quit [Server closed connection]
<daniels>
whilst we're handing out perms, I went back and looked at GitLab API last night, and we can actually have some proactive runner health monitoring & alerting if we use a different API endpoint. that one does require maintainer permissions on the project though - would anyone have any objection to upgrading the ci-bot user to a maintainer so it can also shout & ping when runners are down + eventually file its own disable MRs?
zehortigoza has quit [Server closed connection]
zehortigoza has joined #dri-devel
Daanct12 has joined #dri-devel
lynxeye has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
kurufu has quit [Server closed connection]
kurufu has joined #dri-devel
oneforall2 has quit [Server closed connection]
oneforall2 has joined #dri-devel
Lyude has quit [Server closed connection]
Lyude has joined #dri-devel
Daaanct12 has joined #dri-devel
pa has joined #dri-devel
pa- has quit [Ping timeout: 480 seconds]
tursulin has quit [Quit: Konversation terminated!]
pcercuei has joined #dri-devel
Daaanct12 has quit [Remote host closed the connection]
Daaanct12 has joined #dri-devel
Haaninjo has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Remote host closed the connection]
rsripada has quit [Server closed connection]
rsripada has joined #dri-devel
Daaanct12 has joined #dri-devel
sarnex has quit [Server closed connection]
sarnex has joined #dri-devel
Daaanct12 has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
mangix has quit [Server closed connection]
mangix has joined #dri-devel
nchery has quit [Server closed connection]
nchery has joined #dri-devel
rsalvaterra has quit []
<kusma>
daniels: sounds like a great idea!
rsalvaterra has joined #dri-devel
warpme___ has joined #dri-devel
kts has joined #dri-devel
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
garrison has quit []
<eric_engestrom>
mattst88: if you're asking if I want you to make a release, I don't have any need for it, but if you're asking me to make a release I can :)
i-garrison has joined #dri-devel
pjakobsson has quit [Remote host closed the connection]
<javierm>
airlied: when sending emails to airlied@linux.ie, I get an error about the mail failing to be delivered to airlied@skynet.ie
bluetail215 has joined #dri-devel
kts has joined #dri-devel
fahien has joined #dri-devel
<Venemo>
emersion: it still mentions freenode
<Venemo>
ah sorry, needed to refresh again
bluetail2151 has joined #dri-devel
<emersion>
:P
<Venemo>
looks good now. thanks! :)
bluetail215 has quit [Remote host closed the connection]
<emersion>
np
<Venemo>
emersion: while we are at it, it seems #dri doesn't really exist anymore and neither does #radeonhd so maybe remove the mention of those from that page and the Who's who page
<emersion>
good idea
<Venemo>
with that in mind, should we actually set up some channel for end user support? or should we just tell them to come here?
<emersion>
i am not sure what "end user support" means
<Venemo>
end users coming to irc complaining about their issues in the hopes of getting help
<emersion>
right, but… in general they come to a downstream project first
<Venemo>
if we don't want that, we should recommend them to use the channel for their downstream project or distro or whatever
<emersion>
i think it's perfectly fine to provide end-user support for Mesa issues here
<Venemo>
then just replace #dri with #dri-devel in the text
<emersion>
but, e.g. for #wayland, we get a lot of "i have a black screen" end-user bug reports
<emersion>
which are off-topic
<emersion>
i guess it's the reverse for #dri-devel, so nbd
dreda has joined #dri-devel
bluetail2151 has quit [Read error: Connection reset by peer]
_whitelogger has joined #dri-devel
itoral has quit [Remote host closed the connection]
cengiz_io has joined #dri-devel
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
jekstrand: Do you still need me to look at agx lod clamps?
<alyssa>
Looks like the MR was merged.
<alyssa>
I guess if Marge merged it, then CI was green, and the Asahi unit tests run in CI, and you didn't change the test cases meaningfully, so it must be right :-)
yang has joined #dri-devel
<yang>
I tried getting the (kernel?) crash output over serial console, and 10 sec. before crash this dmesg appears. It looks like it's related to a graphic driver? https://paste.debian.net/plain/1252281
<yang>
with kernel 4.x works normal, with 5.x it started to freeze, I am using Debian bookworm (testing)
<vsyrjala>
that should not cause any sewrious issues, though those frame counter vs. scanline numbers don't smell right at all
<yang>
vsyrjala: thanks, I will do provide the bug
<yang>
vsyrjala: so I need to change the /etc/default/grub line to GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty0 log_buf_len=4M drm.debug=0xe" ?
fab has quit [Quit: fab]
fab has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
sdutt has joined #dri-devel
jewins has joined #dri-devel
lkw has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
lkw has joined #dri-devel
<vsyrjala>
yang: yeah, soemthing like that
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
<jekstrand>
alyssa: I merged it by reverting back to the older LOD code that clamps to 14 and uses util_bitpack_uint(). Feel free to start using util_bitpack_ufixed at any time.
fxkamd has joined #dri-devel
<alyssa>
jekstrand: OK, fair enough :)
bluetail2151 has quit [Ping timeout: 480 seconds]
* ccr
rubs his head in wonder
<ccr>
does one need some special permission to assign tags to issues in gitlab?
<jekstrand>
hakzsam: Yeah, I was running it through CI because my first attempt at adjusting the clip broke the universe
<hakzsam>
ok
<mattst88>
I think maybe we shouldn't include valgrind in Requires.private, since AFAIK, it's not a transitive dependency?
fxkamd has joined #dri-devel
cengiz_io_ has joined #dri-devel
<jekstrand>
hakzsam: Well, that was the intent but I forgot to kick off ci. 😂😭
<hakzsam>
:D
<hakzsam>
I think it should be in good state now
<emersion>
mattst88: hm i think some driver tests depend on it for some reason…
<emersion>
maybe they messed up and added it to the lib deps or something?
<emersion>
libdrm has a "valgrind" option
<emersion>
and indeed depends on it when enabled
cengiz_io has quit [Ping timeout: 480 seconds]
<jekstrand>
hakzsam: I kicked it off. If that comes back ok (should only take 30 min or so), I'll push my rework for VRS -> HTILE copies and test that. Then do another full CI run with everything. I'll ping you when it's ready for review again.
<emersion>
hm intel and freedreno have special code for valgrind
<emersion>
and intel includes it
<jekstrand>
Yeah, ANV does lots of valgrind magic
<jekstrand>
And, now that other drivers are sharing util_bitpack.h, they get valgrind too.
<hakzsam>
jekstrand: sounds good thanks
rkanwal has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<mattst88>
emersion: right, libdrm should definitely on valgrind when valgrind support is enabled
alyssa has left #dri-devel [#dri-devel]
<mattst88>
the problem here is, that apparently things that depend on libdrm are told they also require valgrind when they depend on libdrm
<mattst88>
and I think all the valgrind use in libdrm is statically compiled in. e.g., linking with libdrm built with valgrind support doesn't link against any valgrind shared objects
<jekstrand>
airlied: I'll let !18324 sit another day or so to give dj-death and someone from turnip a chance to look at it. If I don't get any replies by tomorrow, I'll drop the unreviewed patches and land the core stuff. Both you and hakzsam have reviewed the common code now so it's probably in good shape.
jkrzyszt has quit [Ping timeout: 480 seconds]
<jekstrand>
Time to write some docs, I guess.
danielbriggs[m] has joined #dri-devel
fahien has quit [Remote host closed the connection]
fahien has joined #dri-devel
tobiasjakobi has joined #dri-devel
ybogdano has joined #dri-devel
tobiasjakobi has quit []
khfeng has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
* alyssa
debates removing ctx->set_debug_callback from gallium
<alyssa>
I see exactly 2 implementations in tree:
<alyssa>
1. set pipe->debug to the argument. frontends can do that themselves trivially.
<alyssa>
2. finish the shader compile queue and then do ^
<alyssa>
if we stick the shader compiler queue on the pipe_screen then frontends could do that too, even have a helper for frontends to use for it
<alyssa>
or, if we add the queue to the screen (and debug cb to the ctx) in gallium but don't change the frontend/backend ABI, we could then use a single u_default_set_debug_callback implementation for every driver
lkw has quit [Ping timeout: 480 seconds]
<alyssa>
anholt: Kayden: mareko: ^^
luc4 has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
<alyssa>
i think I'll carry on with #1 and convert over drivers that don't use a compile queue, if people like that we can follow on moving the queue and converting the rest of the drivers
pcercuei has joined #dri-devel
LexSfX has joined #dri-devel
nchery has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<alyssa>
or make the queue-based drivers flush the queue and tail call u_default_set_debug_callback
<alyssa>
it seems set_debug_callback is a pointless bit of boilerplate, that's all
<alyssa>
figure I'd clean it up instead of copypasting the impl for panfrost
luc4 has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: we have the same pattern for context loss thingies
Peste_Bubonica has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
gouchi has joined #dri-devel
<zmike>
alyssa: some drivers have multiple queues, so exposing that directly is probably not feasible
lkw has joined #dri-devel
jeeeun8413 has quit []
jeeeun8413 has joined #dri-devel
<robclark>
daniels: re: ci-bot perms, wfm
<daniels>
robclark: ta!
<lina>
Question about the gem shmem helpers: If the GPU uses 16K pages and the kernel 4K pages, how painful is it going to be to get the shmem backend to allocate 16K-aligned physical page blocks? (something something memory folios?)
<lina>
This isn't a problem right *now* since most people use 16K kernel builds, but at some point we need to support 4K builds...
frieder has quit [Remote host closed the connection]
<alyssa>
zmike: yeah, that's a fair point
<alyssa>
zmike: I guess "tail call into u_default_set_debug_callback if you have queues" is still better than the copypaste mess we have now
lygstate has quit [Remote host closed the connection]
idr has joined #dri-devel
<zmike>
alyssa: see also my async pbo MR
JoniSt has joined #dri-devel
lkw has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
sdutt has quit [Remote host closed the connection]
<JoniSt>
I've got a small question about how bugfixes get into Mesa stable... If I have a merged bugfix MR that contains multiple commits (17338), is there anything I have to do to make sure that it gets included in the next stable releases?
<zmike>
if it has backport tagging it will happen automatically
<karolherbst>
JoniSt: add Fixes: tags or CC: mesa-stable?
<JoniSt>
It has a Fixes: tag, yeah, but only on the last commit... Did I mess that up or will that work too?
<karolherbst>
all need to
<JoniSt>
Well, then I did an oopsie there and now I'm not sure how I can fix it, it's been through Marge already, hmm
<JoniSt>
The commits in question are 6718bff75b4d3823df5f9c1d66eace07d37e9c92, aa878030690d4354da7574a2c7536d2308b2d0ca, 8f159a8576efbb7bb3755d215a54b87c4c99a0d2
<karolherbst>
JoniSt: best case the top commit depends on the prev ones and fails to apply so you get bugged. In that case you should open an MR against staging/*
<JoniSt>
karolherbst: Will there be more 22.1 releases? (So, do I need two MRs or just one for 22.2?)
<karolherbst>
not sure
<karolherbst>
maybe?
kts has joined #dri-devel
<karolherbst>
check with dcbaker
<dcbaker>
there will be at least one more 22.1 release
<JoniSt>
Okay... So two backport MRs?
<dcbaker>
Sure
<JoniSt>
Alright! Sorry for the trouble!
<idr>
Hrm...
<dcbaker>
no worries! I like backport PRs
<idr>
How do I get the first block after a loop in NIR? The block that would be targeted by the loop's break.
<dcbaker>
karolherbst: BTW, how is the nouveau ntt thing looking?
<karolherbst>
terrible
jeeeun8413 has quit []
<anholt>
what are you doing with ntt?
<karolherbst>
anholt: it's broken
<karolherbst>
or maybe nv50 is
<karolherbst>
who knows
<karolherbst>
anyway.. since we use NIR, we have artifacts
<karolherbst>
doesn't matter if we use ntt or nir directly
<anholt>
I had tested it with nv50 on our test suites at one point.
<karolherbst>
yeah and deqp has literally no regression
<pendingchaos>
idr: nir_block_cf_tree_next(nir_loop_last_block(loop)) or nir_cf_node_as_block(nir_cf_node_next(&loop->cf_node))
<karolherbst>
I checked as well
<idr>
pendingchaos: Ah! I was so close... but so far away.
<karolherbst>
anholt: though I don't think it's ntt directly though.. it could also be a more complex CFG or _something_
<karolherbst>
but the GPU doesn't even throw errors
jeeeun8413 has joined #dri-devel
lkw has joined #dri-devel
JohnnyonF has joined #dri-devel
luc4 has joined #dri-devel
<HdkR>
airlied: DemiMarie: Looks like I was lied to. The Radeon Pro doesn't support SR-IOV at all.
<karolherbst>
dcbaker: when were you planning to do the next 22.2 release?
<dcbaker>
today, I'm pulling patches ATM
<dcbaker>
I'm happy to make it another RC
<karolherbst>
dcbaker: I might be able to tell tomorrow if postponing makes sense or if we have to think of something else. Given that it pretty much breaks nv50 and it's due to ripping out the GLSL to TGSI path... :(
JohnnyonFlame has quit [Ping timeout: 480 seconds]
* alyssa
tries to understand how shaderdb + vulkan is expected to work
<dcbaker>
okay, I can wait till tomorrow to make the release. That gives things more time to settle in CI anyway
<karolherbst>
okay, cool
<anholt>
alyssa: README tells you how to fossilize_replay.sh.
<alyssa>
anholt: OK. I was noticing the shaderdb callback is routed to /dev/null in both anv and v3dv (but a pile of code is used to ensure that callback exists as opposed to using util_debug_message in the compiler)
<anholt>
vkGetPipelineExecutableStatisticsKHR is the thing the driver implements
<alyssa>
Oh... but KHR_pipeline_statistics is structured output, while the debug callback is all strings
<alyssa>
Yes, I see the problem now.
<JoniSt>
dcbaker: Done for 22.2 (!18349) - if everything's alright there I'll also make the 22.1 one real quick :)
<alyssa>
Ostensibly the "cleanest" approach is structured shaderdb stats reported by the compiler, stringified in the GL driver for shaderdb and Vulkanified in the VK driver for KHR_pipeline_stats
<alyssa>
However, today's goal is just to get util_debug_callback wired up to sharedb in GL, not Vulkan
<karolherbst>
anholt: btw, I am seeing that deqp behavior jekstrand was telling about. If processes get reaped there is a time where deqp doesn't spawn new processes
<alyssa>
so I guess passing util_debug_callback into the backend and using that instead of stderr is good enough..
<alyssa>
it's not like util_debug_callback is Gallium specific
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
warpme___ has quit []
tursulin has quit [Quit: Konversation terminated!]
Dr_Who has joined #dri-devel
Boxst has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
Boxst has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
warpme___ has joined #dri-devel
Haaninjo has joined #dri-devel
pa has joined #dri-devel
pa- has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
pa- has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
pa has quit [Ping timeout: 480 seconds]
jvesely has joined #dri-devel
pa has joined #dri-devel
lkw has quit [Quit: leaving]
bluetail21514 has quit []
bluetail21514 has joined #dri-devel
jvesely has quit []
pa- has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<jekstrand>
airlied: Updated !16918 for command buffer status recording. It'd be good if you re-reviewed the first two. That plus my review and CI is probably enough to land it, I think.
<jekstrand>
Oh, and if bbrezillon wanted to look quick, that'd be good too.
nchery has joined #dri-devel
nchery is now known as Guest1686
nchery has joined #dri-devel
pa- has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.5]
pa has quit [Ping timeout: 480 seconds]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Guest1686 has quit [Ping timeout: 480 seconds]
<alyssa>
austriancoder: thanks for review on the gallium thing :)
<alyssa>
any update on the idiv stuff?
<alyssa>
eric_engestrom: ^^ too
bluetail21514 has quit []
bluetail21514 has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
gio has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
danielbriggs[m] has left #dri-devel [#dri-devel]
bluetail215145 has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
bluetail215145 has quit [Read error: Connection reset by peer]
bluetail21514 has quit [Ping timeout: 480 seconds]
bluetail21514 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
bluetail21514 has quit [Read error: Connection reset by peer]
bluetail21514 has joined #dri-devel
mbrost has joined #dri-devel
bluetail21514 has quit [Read error: Connection reset by peer]
bluetail21514 has joined #dri-devel
bluetail21514 has quit [Remote host closed the connection]
ahajda has joined #dri-devel
bluetail21514 has joined #dri-devel
flto has quit [Read error: Connection reset by peer]
bluetail215142 has joined #dri-devel
bluetail21514 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
bluetail215142 has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
bluetail21514 has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<robclark>
karolherbst, anholt, tomeu: jfwiw I've seem nouveau shader-db crash flakes a couple of times now in the debian-build-testing job, not sure if that is known issue
<karolherbst>
though I am trying to figure out an annoying bug with nv50 atm...
<karolherbst>
oh well.. if in doubt throw libasan into the mix
mbrost has quit [Ping timeout: 480 seconds]
<robclark>
yeah
flto has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<anholt>
not a known issue to me
<karolherbst>
I suspect you broke it :P
<karolherbst>
dunno
<karolherbst>
can't trigger it on main
<robclark>
karolherbst: 2nd time I've seen in in last month or so.. both times it passed if I re-ran the job.. so if I broke it, I broke it a long time ago :-P
<karolherbst>
odd
<karolherbst>
libasan doesn't show anything here either
<karolherbst>
ohh
<karolherbst>
now it crashed
<robclark>
maybe tsan is actually the thing needed? I guess it doesn't happen _all_ the time or we'd have seen it more
<karolherbst>
maybe
luc4 has quit [Quit: Konversation terminated!]
<karolherbst>
robclark: maybe it's the same bug I am trying to track down
mbrost_ has quit [Read error: Connection reset by peer]
<karolherbst>
well.. I'll run it a few times in gdb and hope I'll get it to point me to a stack or something
<robclark>
cool
<karolherbst>
okay got it.. it's something else
<robclark>
doh.. would have been nice if was same bug ;-)
<karolherbst>
uhhh... why does it have to be in the most annoying place of the driver
<karolherbst>
ahh I fixed it on main I think :).. let me check
<karolherbst>
robclark: I blame broken threading, but I merged the fix like yesterday
<karolherbst>
let me do a couple of runs just to be sure
<karolherbst>
in doubt, rebase your stuff on main...
<karolherbst>
yeah.. your branch doesn't contain the MT fixes
<karolherbst>
though not quite sure why that's relevant... at least I don't think it was a problem before
<karolherbst>
does shader-db reuse the same GL context or create one for each thread?
<robclark>
ahh, I'm like a whole 1.5 day behind ;-)
<robclark>
karolherbst: I _think_ it is creating a ctx per thread and then re-using that for N shaders.. assuming I'm understanding the openmp magic bits properly
<karolherbst>
mhhh
<jekstrand>
robclark: Has isaspec been used with 96-bit instructions before?
<robclark>
austriancoder has a branch somewhere for etnaviv isaspec.. which is 128b (IIRC)
<karolherbst>
128 already works afaik
<robclark>
he was the one who make it support >64b
<jekstrand>
Ok, if 128 works, 96 should be fine.
<karolherbst>
96 is npot, I can see it failing in weird ways :P
<jekstrand>
Let's just hope it rounds up to 128 or something. :D