ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nchery has joined #dri-devel
nchery is now known as Guest1628
nchery has joined #dri-devel
jewins has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Guest1628 has quit [Ping timeout: 480 seconds]
JoniSt has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
ella-0 has joined #dri-devel
ella-0_ has quit [Remote host closed the connection]
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
sockless has joined #dri-devel
sockless has quit [Remote host closed the connection]
heat_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
idr has quit [Read error: Connection reset by peer]
Company has quit [Quit: Leaving]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
srslypascal is now known as Guest1643
srslypascal has joined #dri-devel
fxkamd1 has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
Guest1643 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
Daanct12 has joined #dri-devel
chrisf has joined #dri-devel
chrisf has quit []
Duke`` has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
cengiz_io_ has quit [Ping timeout: 480 seconds]
fxkamd has quit []
aswarup_ has joined #dri-devel
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]
rkanwal has joined #dri-devel
<Venemo> hey guys
<Venemo> can someone update this page to mention OFTC instead of freenode? https://dri.freedesktop.org/wiki/IRC/
<emersion> done
lkw has joined #dri-devel
dakr has joined #dri-devel
<knr> airlied: Any comments on https://lore.kernel.org/dri-devel/20220823210612.296922-1-michal.winiarski@intel.com/ (expanding device numbers)? You mentioned on this channel that there are "other discussions", could you elaborate?
kts has quit [Quit: Konversation terminated!]
lemonzest has joined #dri-devel
bluetail215 has quit []
<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: I use a dual-monitor setup
<yang> How could I get these values right?
<vsyrjala> to investigate those more best to file a bug at https://gitlab.freedesktop.org/drm/intel/issues/new
<vsyrjala> then boot with "log_buf_len=4M drm.debug=0xe" passed to kernel cmdline, and attach the resulting dmesg to the bug
fab has quit [Read error: No route to host]
<yang> okay
<yang> # lspci -> 00:02.0 VGA compatible controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller (rev 35)
fab has joined #dri-devel
<yang> this is the GPU I think
<yang> vsyrjala: thanks will do
<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]
Jeremy_Rand_Talos__ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
pjakobsson has joined #dri-devel
bluetail2151 has joined #dri-devel
<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?
<ccr> I mean labels
kts has joined #dri-devel
<jenatali> ccr: Yes, the "reporter" permission
<ccr> ah, okay.
fab has quit [Quit: fab]
bluetail2151 has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
bluetail21514 has joined #dri-devel
<hakzsam> jekstrand: can you update your dyn MR again? it's missing the most important commit it seems :-)
bluetail2151 has quit [Ping timeout: 480 seconds]
<yang> vsyrjala: now the last message, 10 seconds before freeze was this -> https://dpaste.org/dDErV/raw
kts has quit [Read error: Connection reset by peer]
<mattst88> eric_engestrom: sure, seems like a good time to tag a new release, if you don't mind and have the time
fahien has joined #dri-devel
<emersion> i can do that
nchery has quit [Read error: Connection reset by peer]
<Ristovski> yang: that one is harmless and most likely unrelated
<eric_engestrom> mattst88: sure, but it sounds like emersion wants to, I wouldn't want to take that away from him :P
<emersion> and done
<mattst88> thanks!
<emersion> yeah, i happen to have a commit i want to use in there
fab has joined #dri-devel
heat_ has joined #dri-devel
fxkamd has quit []
<mattst88> emersion: any clue about https://bugs.gentoo.org/856754 ?
<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/*
fahien has quit []
<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> robclark: huh.. let me check
nchery has joined #dri-devel
mbrost_ has joined #dri-devel
<karolherbst> robclark: strange... doesn't crash locally :/
<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
<karolherbst> I have a few isaspec patches here, but nothing for 128 bit stuff: https://gitlab.freedesktop.org/karolherbst/mesa/-/commits/nvk/nc/
warpme___ has quit []
<karolherbst> robclark: huh... those openmp pragmas look.. strange
<karolherbst> but yeah.. it uses multiple contexts I would say
<karolherbst> just that those jump between threads quite a bit
<karolherbst> mhh maybe not
<karolherbst> if I read that correctly, you get one context per thread, and the for loop gets dynamically scheduled across all threads
<karolherbst> but yeah.. I can see that the threading fixes might fix this bug :)
<karolherbst> lina: before you go too much into writing bindings.. did you take a look at bindgen?
<karolherbst> or did you mean wrapper when you wrote "bindings"?
pcercuei has quit [Quit: dodo]
mbrost has joined #dri-devel
<jekstrand> ugh... This mme format reverses all the bits :sob:
<karolherbst> jekstrand: the heck?
<jekstrand> Yup, bit 0 is in dw 2
<jekstrand> :D
<karolherbst> ....
<jekstrand> It's extra special. :D
<jekstrand> I'm sure this magic XML format has some way of letting me remap
<karolherbst> you can combine fields
<karolherbst> but that's ugly
<jekstrand> I mean, I can go through and triswap everything first
<karolherbst> jekstrand: I guess this only matters for fields across 32 bit boundaries
<jekstrand> karolherbst: Yup and, of course, it has those!
<karolherbst> so you could define field_lo at 63:61 and field_hi at 2:0 and make a new type || those values
<karolherbst> *|
<jekstrand> I'm gonna just tri-swap everything
<jekstrand> Unless robclark wants to tell me the magic invocation. :D It's not obvious from the docs
<karolherbst> jekstrand: probably tells you to use derived :P
<karolherbst> though that can become very ugly
<karolherbst> jekstrand: we have two instruction in those 96 bits, right?
<jekstrand> karolherbst: Ish? Two ALUs, two OUTs, one predicate
<karolherbst> are they.. "same" or differently encoded
<karolherbst> ahh
<jekstrand> And there is something crossing both dword boundaries
<karolherbst> sounds like VLIW and that's something I don't want to have to deal with :P
<jekstrand> ALU0_IMMED and ALU0_SRC1
<jekstrand> ALU1_SRC1, rather
<karolherbst> mhhh
<karolherbst> "annoying"
<jekstrand> I'm gonna swap in C code
<karolherbst> yeah...
<karolherbst> could have a field on the isa tag
<karolherbst> at least now those -64 and -32 thingies make sense
mbrost has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Quit: Leaving]
sdutt has joined #dri-devel
<jekstrand> I really don't get these predicates. I guess maybe each "slot" controls one of ALU0, ALU1, OUT0, and OUT1?
<jekstrand> Probably
<jekstrand> I feel the need to write an emulator for this
<karolherbst> maybe?
<jekstrand> Maybe not
<karolherbst> you might know more than I do already
<karolherbst> all I know is you can do fancy stuff with it :P
<karolherbst> okay.. in regards to that nv50 issue, I know I get broken shaders executed, but I have no idea _why_ :(
Haaninjo has quit [Quit: Ex-Chat]
<robclark> jekstrand: if it is universally swap the three dwords around after encoding / before decoding.. probably easiest to do it that way
<jekstrand> robclark: Yup, that's what it is. :-/
<jekstrand> Because sort-of-bit-endian 96-bit words are, aparently, a thing. :-(
<karolherbst> isn't that middle endian?
<jekstrand> 🤷
<robclark> I guess intel gpu designers were envious of apple and decided to "think different" :-P
<jekstrand> robclark: This isn't Intel. This is NVIDIA's MME format.
<jekstrand> It's their command streamer macro language
<robclark> ahh.. s/intel/nv/ then :-P
<robclark> gotcha
<jekstrand> I'm tempted to write a NIR back-end for it.
<robclark> :-P
<jekstrand> The advantage to doing it that way is that I can run the same programs through both a Turing back-end and a Kepler back-end
The_Company has joined #dri-devel
<jekstrand> Totally different ISAs but I wouldn't be hand-coding everything twice.
<jekstrand> But then I'd have to debug compiler bugs, so...
CME_ has joined #dri-devel
<karolherbst> I want to know this engineer who was thinking "yep, that totally does make sense"
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
<karolherbst> robclark: I know it's tempting, but you can't blame on evil hw things on intel :P
<jekstrand> No, but they do take more than their fair share. :D
<karolherbst> :D
<karolherbst> I am sure MME was invented, so engineers could say "even for us not eveertying is perfect"
<karolherbst> okay but seriously.. what's up with that NIR stuff :(
Company has quit [Ping timeout: 480 seconds]
<jekstrand> ?
CME has quit [Ping timeout: 480 seconds]
<karolherbst> jekstrand: getting random trashed shaders on nv50 when nir is in the mix
<jekstrand> IDK
<karolherbst> me neither
<karolherbst> I wanted to blame my nir to codegen translation code, but same happens when doing nir -> TGSI -> codegen
* jekstrand blames TGSI
<karolherbst> does also happen if there is no TGSI involved
<jekstrand> :(
<karolherbst> maybe I should check the commit nuking glsl to TGSI just to be sure
Daanct12 has joined #dri-devel