ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
bolson has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
illwieckz has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
leizhou has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
yuq825 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
alane has quit []
alane has joined #dri-devel
tristianc67048 has quit [Read error: Connection reset by peer]
tristianc67048 has joined #dri-devel
apinheiro has quit [Quit: Leaving]
LeviYun has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
vedran has joined #dri-devel
vedranm has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
RAOF has quit [Remote host closed the connection]
RAOF has joined #dri-devel
tristianc670482 has joined #dri-devel
sukuna has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
tristianc67048 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
tristianc670482 has quit [Read error: No route to host]
LeviYun has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
tristianc670482 has joined #dri-devel
LeviYun has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
LeviYun has joined #dri-devel
sukuna has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
glennk has joined #dri-devel
mwalle has quit [Quit: WeeChat 3.8]
sima has joined #dri-devel
bmodem has joined #dri-devel
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
ity1 has joined #dri-devel
ity has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
LeviYun has joined #dri-devel
aravind has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
smaeul has quit [Ping timeout: 480 seconds]
<airlied> zzoon: did you ever look at intel av1?
LeviYun has joined #dri-devel
zzoon[m] has joined #dri-devel
<zzoon> airlied: yes.. a bit long ago though.
<zzoon> film grain support is the high priority for this branch.
Duke`` has quit [Ping timeout: 480 seconds]
<airlied> zzoon: I'm just playing with zink video support, and was going to look into trying it on some other hw
<zzoon> I think you can use this branch with av1 video that doesn't require filmgrain.
<airlied> I was pondering if we should do filmgrain with shaders at the vaapi level here
fab has quit [Quit: fab]
bmodem has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
itoral has joined #dri-devel
rasterman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
smaeul has joined #dri-devel
fab has joined #dri-devel
warpme has joined #dri-devel
tzimmermann has joined #dri-devel
frieder has joined #dri-devel
bmodem has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.3.4]
lemonzest has joined #dri-devel
warpme has quit []
LeviYun has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
vliaskov__ has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
vedran is now known as vedranm
simon-perretta-img has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
smpl has joined #dri-devel
LeviYun has joined #dri-devel
lynxeye has joined #dri-devel
warpme has quit []
mripard has joined #dri-devel
mwalle has joined #dri-devel
jkrzyszt has joined #dri-devel
vliaskov__ has quit [Read error: Connection reset by peer]
warpme has joined #dri-devel
Haaninjo has joined #dri-devel
pcercuei has joined #dri-devel
kode54 has quit [Quit: The Lounge - https://thelounge.chat]
KDDLB has quit [Quit: The Lounge - https://thelounge.chat]
kode54 has joined #dri-devel
frankbinns1 is now known as frankbinns
tanty has quit [Remote host closed the connection]
tomaw has quit [Quit: Quitting]
JoshuaAshton has quit [Remote host closed the connection]
tomaw has joined #dri-devel
FLHerne has quit [Remote host closed the connection]
Plagman has quit [Remote host closed the connection]
Plagman has joined #dri-devel
FLHerne has joined #dri-devel
fab has quit [Quit: fab]
tanty has joined #dri-devel
nchery is now known as Guest549
nchery has joined #dri-devel
<sima> mripard, I wonder whether that'll lead to some test gaps
<sima> like do we want to guarantee that single zpos is immutable?
JoshuaAshton has joined #dri-devel
<sima> mripard, typed some reply
Guest549 has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
smpl has quit [Ping timeout: 480 seconds]
<sima> tzimmermann, jfalempe I'm wondering whether we could use the fb_info flag for no panic support to eventually decide whether fbcon will be registered as one of the new kernel consoles (not vt consoles) with the new locking
<sima> so that we get the guarantee that our console printing code is always run from process context
<sima> the issue is a bit that this decision is another layer away in the vt code ...
<tzimmermann> sima, the fb_info flag?
fab has joined #dri-devel
<jfalempe> tzimmermann: the fb_info->skip_panic flags I added with https://patchwork.freedesktop.org/series/136182/
<sima> tzimmermann, yeah
<tzimmermann> jfalempe, sima. i'm out of the loop
<sima> but one step further so that we decide in the vt console code
<jfalempe> But I think it's a good idea, if panic is the only case where the new console won't fit.
<sima> tzimmermann, ah I think that discussion was with javierm, not you maybe
<tzimmermann> jfalempe, can we unregister panic support for a DRM device when we register fbdev support?
<tzimmermann> such that panic is on by default and the fbdev code actively replaces it?
<jfalempe> tzimmermann: that should be possible.
Company has joined #dri-devel
<jfalempe> sima: I'm also considering writing a drm_log, to be able to log the early boot message, without relying on VT_CONSOLE and fbcon
<sima> tzimmermann, other way round, we should make sure fbdev panic doesn't work because at least with the current locking it's terminally broken
<jfalempe> I think it would be one of the last piece to push for disabling VT on Linux distor.
<tzimmermann> sima, taking away panic messages from the console might not sit well with everybody
<jfalempe> tzimmermann: with the kmsg panic screen, you will get the exact same message on the drm panic screen.
<sima> tzimmermann, oh I mean only for drm drivers that do have panic
<sima> *native panic support
<tzimmermann> jfalempe, we know that. :) but people have their working setups and expectations
<javierm> tzimmermann: yeah, we have seen that when pushing for a change proposal to use DRM panic + plymouth kernel log instead of fbcon panic + vt console
<sima> yeah it would maybe make this transition a bit more gradual
<javierm> there's also confusion because VT_CONSOLE only means that the kernel will use a VT as a system console (and use it to print its messages) but people thought that this would meant not having a VT console at all
<sima> kinda like the current patch set from jfalempe is great since it doesn't require compile-time decision anymore for at least enabling drm panic
<javierm> we had to clarify in the fedora-devel thread that with jfalempe
<javierm> sima: exactly, that was based on the feedback from the fedora users
<sima> javierm, the naming with both vt console and kernel console being abbreviated to console doesn't help :-/
<javierm> yeah...
<javierm> jfalempe: drm log could be useful indeed to close the gap of not having kernel messages between earlycon and plymouth (or systemd) redirecting /dev/kmsg to the fbcon
<javierm> jfalempe: the idea would be to implement as a DRM client (like the fbdev DRM emulation) and then detach once the fbdev DRM emulation is attached ?
<jfalempe> I think you won't need fbdev emulation, if you use drm-log.
<javierm> jfalempe: but you do need for fbcon right ?
<javierm> otherwise you will take from users their precious VT console
<jfalempe> the final goal is to have user-space console. but it could be better to do that step by step.
<jfalempe> so yes drm-log will stop logging when the first userspace apps open the drm device, or when fbcon attach to fbdev emulation.
<javierm> jfalempe: agreed on final goal to completely disable CONFIG_VT
<jfalempe> it should also be disabled when quiet is on the kernel command line.
sukuna has quit [Remote host closed the connection]
davispuh has joined #dri-devel
<mripard> sima: great, thanks :)
kts has joined #dri-devel
lucaceresoli has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
itoral has quit [Remote host closed the connection]
karenw has joined #dri-devel
karenthedorf has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
karenw is now known as karenthedorf
<tzimmermann> jfalempe, i'm going to send out an update to the vblank patch immediately
<jfalempe> tzimmermann: yes you can remove the iclear write ;)
<jfalempe> if it's the only change, you can keep my review-by, no need to send a new version.
<tzimmermann> jfalempe, i see
<tzimmermann> jfalempe, i intend to just write the VLINE bit. the reserved bits are supposed to be zero, so i don't want to write 0xffffffff. and if we ever use another of those interrupts, we'll have the necessary clear op already in place
<jfalempe> tzimmermann: that's fine for me too.
<zmike> eric_engestrom: or maybe best to just talk here since I don't think the resolution will be so simple
<eric_engestrom> ack
<eric_engestrom> but also I'm kinda lost so not sure how much I can help :]
<zmike> yeah it's not a simple problem
<zmike> maybe one thing that's easier to focus on is the loader changes
<zmike> src/loader/loader.c now has a function which directly calls symbols from targets/dri
<zmike> so it needs linkage there
<zmike> but libloader is used by a ton of different components, which leads to undefined symbols in all those cases
<zmike> I think dlsym(NULL, "symbolname") to pull from the current process's symbol table would be better, but then even though the dri frontend symbols are declared PUBLIC they aren't accessible
<eric_engestrom> `gnu_symbol_visibility : 'hidden',`
<eric_engestrom> zmike: sounds like you need to change this? ^
<zmike> that explains it
Company has quit [Quit: Leaving]
<zmike> though like I said
<zmike> the functions are declared with PUBLIC
<zmike> which explicitly sets visibility("default")
<zmike> so shouldn't that override -fvisibility=hidden?
<eric_engestrom> I'm not sure what overrides what
<zmike> I'm reasonably sure the compiler flag just sets the default visibility and it's up to the code to explicitly make things public
<zmike> which also makes sense considering the current loader dlsyms them
paulk-bis has quit []
paulk has joined #dri-devel
<eric_engestrom> > With -fvisibility=hidden, you are telling GCC that every declaration not explicitly marked with a visibility attribute has a hidden visibility.
<zmike> yeah
<zmike> ugh I guess maybe the best solution maybe IS trying to split this code out of libloader again
<zmike> I made an attempt last night and it...didn't go well
<karolherbst> does it work if you declare everything PUBLIC in the linker script?
<zmike> the symbols are already PUBLIC in the code
<karolherbst> so you haven't tried it
<zmike> I'm not sure what you're proposing
<karolherbst> checking the linker script, because I think it can overwrite whatever you specify in code
<zmike> what is the linker script in this context?
<karolherbst> -Wl,--version-script
<karolherbst> e.g. dri.sym for target/dri/
<zmike> ah
<zmike> the symbols are public in that already
<zmike> so I guess I have tried it
<karolherbst> okay
<karolherbst> yeah, then it's odd
riteo has joined #dri-devel
<karolherbst> though I also don't know how much you've reworked. that script needs to be passed and correct when linking the final so file
<zmike> I haven't changed anything related to that
<zmike> oh dlsym fails because libgallium isn't loaded
<zmike> tremendous
<zmike> htf...
<zmike> ah right, because doing dlsym removes the linkage
<zmike> fml I hate build systems
<karolherbst> uhhh... pain
<karolherbst> there was this linker flag...
<karolherbst> --whole-archive?
<zmike> maybe I'm thinking about this wrong
<zmike> maybe this will work
<zmike> pray for me
u-amarsh04 has quit []
yuq825 has quit []
u-amarsh04 has joined #dri-devel
<daniels> oh no, I need jenatali
<daniels> especially given that it works just fine in the piglit build https://gitlab.freedesktop.org/mesa/piglit/-/jobs/61195851#L3817
<daniels> though that is using python 3.10 rather than 3.12
kts_ has joined #dri-devel
jenatali has joined #dri-devel
<daniels> of course, an actual error message would be helpful ...
kts has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
vliaskov has joined #dri-devel
u-amarsh04 has joined #dri-devel
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
<jenatali> Oh you probably didn't see my messages because NickServ didn't tell me I lost connection
<jenatali> I see some overflows due to negation later on in the log, but they're just warnings afaict
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
epoch101 has joined #dri-devel
kzd has joined #dri-devel
<daniels> yeah, I just tagged you in the MR with the actual failures pulled out
<daniels> though it seems like it’s always missing the final line which tells you the most interesting detail, which is cool
<daniels> sorry to punt this on you but my Windows machine is long gone
nchery has quit [Remote host closed the connection]
<jenatali> Yeah I understand
<jenatali> It's the price I pay for keeping Windows in CI and it's worth it
bmodem has quit [Ping timeout: 480 seconds]
<daniels> jenatali: <3
lynxeye has quit [Quit: Leaving.]
<mairacanal> mripard, tzimmermann: have you had the time to take a look at this e-mail? https://lore.kernel.org/dri-devel/0f5cf733-7f22-4b93-b13e-08916aa3f152@igalia.com/ I was wondering if we could get those patches cherry-picked
<tzimmermann> mairacanal, hi. in cases like this it's better to first merge all fixes into drm-misc-fixes; then backmerge into drm-misc-next and apply the rest of the patchset on top
<tzimmermann> if we cherry-pick them now, we'll likely run into merge conflicts in drm-tip and drm-next
<mripard> mairacanal: to add to what tzimmermann said, is it actual fixes (like, do they fix a bug that was reported somewhere), or are they just to improve the current code without a clear bug?
<tzimmermann> sima, airlied, ^
<mripard> in the latter case, there's no need for them to go through drm-misc-fixes
<tzimmermann> mripard, will someone pick them up for drm-fixes?
kts_ has quit [Ping timeout: 480 seconds]
<mripard> tzimmermann: what do you mean?
<tzimmermann> AFAIU these are fixes for upstream. they will now sit in drm-misc-next or drm-next for a while
<tzimmermann> and they should go via drm-misc-fixes->drm-fixes->upstream instead
<sima> tzimmermann, yeah backmerge would have been better, but since they're already in drm-misc-next cherry-pick with the dim wrapping is the way to go
<sima> mairacanal, ^^
<mripard> tzimmermann: not necessarily
<mripard> if they don't fix bugs, they are better off in drm-misc-next anyway
<tzimmermann> mairacanal, right, what sima said.
<sima> and yeah if it's just polish, no need to put into -fixes
<sima> but at least from the summaries doesn't sound like that
<tzimmermann> do a 'dim cherrypick' to get them into drm-misc-fixes. the dim command will add additional information
<mripard> tzimmermann: also, we're supposed to do the cherry-picks ourselves :)
<sima> ah yes that too, in the past it resulted in some fun when commmitters did that
<tzimmermann> ok, i'll volunteer :)
<mripard> tzimmermann: but really, if there's no bug associated to it, they shouldn't be in drm-misc-fixes at all, so we should clear that up first
<tzimmermann> mairacanal ^ you what patches 1 to 5 cherry-picked ?
<mairacanal> yeah, if possible
<tzimmermann> mripard, they have fixes tags AFAICT
<tzimmermann> mairacanal, processing...
<mripard> which means that there was something to fix in the original commit, not that there's a bug.
Company has joined #dri-devel
<mairacanal> those patches are avoiding memory leaks and avoiding userspace to perform invalid actions
nchery has joined #dri-devel
<tzimmermann> mripard, i don't understand what you mean. the commit message says "drm/v3d: Prevent out of bounds access in performance query extensions" and the fixes tag refers to a patch that is in v6.9. that is clearly material for drm-misc-fixes
<mairacanal> currently, userspace can access out of bounds memory, which I don't believe is ideal :(
<mripard> mairacanal: I guess the question is, does it?
<mripard> it can do that, sure, but if it doesn't, there's no rush to merge it anyway
<mairacanal> I don't have control over userspace
<mairacanal> I cannot guarantee that every process using this IOCTL is passing a valid number of perfmons
kts has joined #dri-devel
<mripard> let me rephrase then. What's the reproducer?
<sima> they all look like real -fixes material to me
<sima> maybe an evil igt would be nice, maybe that even exits
<mairacanal> mripard, it is just a matter of submitting the IOCTL with a invalid number
<mairacanal> Mesa isn't doing it, because I coded the implementation for this IOCTL (and this is probably why I didn't think about this verification)
nerdopolis has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<mairacanal> But I can't guarantee that every user space program using this IOCTL knows about this and it would end up with a invalid address access
LeviYun has quit [Ping timeout: 480 seconds]
kts has quit []
<mripard> my point is: is a theoretical bug that we haven't seen anywhere in real life is worth creating merge conflicts, history and bisection mess that will frustrate people. it's a judgement call.
<mripard> especially since it's going to be backported to every relevant stable kernel anyway, so it's just a matter of weeks
LeviYun has joined #dri-devel
guludo has joined #dri-devel
<mairacanal> I could understand this point if we were talking about a theoretical race condition
<mairacanal> But it's not the case, it is a bug that allows userspace to pass a number of perfmons bigger than the array we allocate in memory
<mairacanal> Also I believe those 5 commits apply fine in -next-fixes and -fixes
kts has joined #dri-devel
<zmike> jenatali: good news, I think my MR is okay on Windows now
<jenatali> zmike: great
<mairacanal> sima, mripard, tzimmermann: so, it won't be possible to cherry-pick the commits, right? or they can be cherry-picked?
<mripard> mairacanal: again, these patches should probably have been applied to drm-misc-fixes indeed. I'm not discussing whether the fault is there. I'm discussing whether it's worth cherry-picking.
<tzimmermann> mairacanal, i cherry-picked and built them. i'm going to push them in a minute. there's possible upside and little downside to it
<jenatali> zmike: after that change goes in I think we might be able to de duplicate some of the egl backends
<zmike> jenatali: yes, I'm planning to slowly delete all the interfaces
<zmike> and eventually glx/egl/gbm will just be symlinks to libgallium
<jenatali> Wonderful
<zmike> and maybe the code will even be readable
<jenatali> Well, on Windows we'll still want egl to be a separate dll
<zmike> you do you
<mairacanal> mripard, i didn't apply them to -fixes because they are the beginning of a 11 patches series. if they were applied at -fixes, i wouldn't be able to have the rest of the series on -next
<mripard> mairacanal: of course you would have been
<mripard> not at once, though
<mairacanal> i was a bit in doubt about what to do, but i read "If you’re unsure, apply your patch here, it can always be cherry-picked to one of the -fixes branches later on" from the maintainers docs
<mairacanal> and i thought that cherry-picking could be a reasonable approach
<mairacanal> sorry about the disturbance, i'll try to approach such situations differently in the future
<mairacanal> tzimmermann, thanks about it!
<mripard> mairacanal: sorry, I'm not trying to be picky about it. cherry-picking has real downsides though, so for bugs/regressions we have a clear reproducer, it's a clear call
<mripard> for issues that *might* be there, it's less clear
<mripard> and I guess we're in that grey area
<mairacanal> i also apologize, this is my first time dealing with such situation and i didn't know about the cherry-picking downsides
nerdopolis has quit [Ping timeout: 480 seconds]
<rodrigovivi> mairacanal, the drm-tip rebuild is broken on some v3d conflicts... could you please help there?
<mairacanal> checking now
smpl has joined #dri-devel
<tzimmermann> rodrigovivi, i'm working on it
<rodrigovivi> thanks
<mairacanal> thanks tzimmermann
<tzimmermann> rodrigovivi, should be good now
<tzimmermann> mairacanal, done
<mairacanal> thanks tzimmermann, sima, and mripard for all the help
<tzimmermann> mairacanal, no worries
vliaskov has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
aissen_ has quit []
aissen has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Duke`` has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
warpme has quit []
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
coldfeet has joined #dri-devel
Company has quit [Quit: Leaving]
Duke`` has quit []
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
Duke`` has joined #dri-devel
<jenatali> daniels: "OverflowError: Python integer -2147483648 out of bounds for uint32"
epoch101 has quit [Ping timeout: 480 seconds]
<jenatali> Looks like we're pulling in a new version of numpy
<daniels> I wonder why that doesn't trigger on arm32
<daniels> right, so I get endless spam of:
<daniels> /home/daniels/mesa/piglit/generated_tests/gen_intel_shader_integer_functions2_tests.py:321: DeprecationWarning: NumPy will stop allowing conversion of out-of-bound Python integers to integer arrays. The conversion of -9223372036854775808 to uint64 will fail in the future.
<daniels> np.array(value).astype(dtype)
<daniels> will give the desired result (the cast overflows).
<daniels> For the old behavior, usually:
<daniels> return [np.uint64(x) for x in srcs]
<jenatali> What numpy version do you have?
<eric_engestrom> zmike, daniels: do we want to merge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27607 now?
<eric_engestrom> /me feels weird about pushing changes to someone else's MR and then merging it, feels like someone else should do the second part 🫣
<jenatali> daniels: Looks like NumPy 2.0 just hit stable a month ago
<daniels> jenatali: numpy 1.26.4 on python 3.12
<jenatali> Yeah that'll do it
<daniels> eric_engestrom: there you go, no need to feel weird ;)
<jenatali> If I set up a new Python locally, without specifying explicit versions, I get NumPy 2.0
<eric_engestrom> daniels: ta!
checkfoc_us has quit []
<zmike> eric_engestrom: I've been doing it to ajax's MRs for years
<zmike> it's the only way
<eric_engestrom> haha
<jenatali> daniels: We can either try to fix piglit for numpy2.0 or we can freeze numpy in the Windows container builds to 1.26.x
checkfoc_us has joined #dri-devel
<daniels> jenatali: yeah, should we freeze to 1.26.2 for now and then figure out how to fix the tests? I was poking around a little bit but have just realised I have no 32-bit system to check anything on rn
<jenatali> Do we need a 32-bit system? These VMs are x86-64?
Haaninjo has joined #dri-devel
guludo has quit [Quit: WeeChat 4.3.3]
guludo has joined #dri-devel
<daniels> just re-read the notes and indeed it shouldn't really be material; I was worried that NumPy changing its precision and not preserving through bigint may have been an issue on 32-bit, but I don't think it should be
<jenatali> daniels: As for the build container failure... C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\yvals_core.h(898,1): error: static assertion failed: error STL1000: Unexpected compiler version, expected Clang 17.0.0 or newer.
LeviYun has quit [Ping timeout: 480 seconds]
<jenatali> Apparently the latest minor VS version includes new headers that are incompatible with the older clang we're using. Upgrading LLVM/Clang is probably doable but might be problematic due to the typed pointer stuff karolherbst has been fighting with...
<daniels> jenatali: oh no.
<daniels> jenatali: is there any way to pull an older msvc?
<jenatali> Probably. I'm also looking to see if we can suppress this error
<jenatali> Ah: _ALLOW_COMPILER_AND_STL_VERSION_MISMATCH
aravind has quit [Ping timeout: 480 seconds]
<jenatali> daniels: Workarounds pushed
<daniels> jenatali: did you just push to my branch?
<jenatali> Yep
<daniels> nice! thanks so much
warpme has joined #dri-devel
LeviYun has joined #dri-devel
<jenatali> daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61220681 didn't rebuild the container. You'll need to re-bump the tag for it, or else delete the image so it gets rebuilt. That's where numpy is getting pulled in
riteo has quit [Ping timeout: 480 seconds]
<daniels> jenatali: yeah, literally just re-pushed that
i-garrison has joined #dri-devel
<daniels> jenatali: mm, libclc still unhappy :( https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61220682
tzimmermann has quit [Ping timeout: 480 seconds]
<eric_engestrom> zmike: !29771 is breaking llvmpipe/softpipe (and virgl but I think it runs on llvmpipe so that would be why)
<jenatali> daniels: :(
<jenatali> Oh, weird, it's using actual MSVC instead of clang-cl? One sec...
<daniels> the only thing I can think of that's weird is that we have 'z.lib' on the command line and does that actually exist, or is it zlib handling being somehow broken?
<daniels> that comes in via LLVM system libs in libclc's cmake
<jenatali> I'm trying to reproduce the CI environment. My local build was using clang-cl
macromorgan has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
macromorgan has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
warpme has quit []
<jenatali> Nope even when I switch to MSVC it still passes for me...
<daniels> hngh
<daniels> I really wonder why ninja doesn’t bother capturing the salient errors
<daniels> ‘how is line ending formed’, I guess
<zmike> eric_engestrom: ffffffffff so close
<eric_engestrom> haha
<daniels> it is objectively funny that you broke zink-lvp
karenthedorf has quit [Ping timeout: 480 seconds]
<eric_engestrom> daniels: zink-lvp works though
<eric_engestrom> (which is weird since most of llvmpipe is broken)
<daniels> oh, maybe that was the other MR
<daniels> (the DRI3 one)
<eric_engestrom> wait that's the thing though, lavapipe works but llvmpipe/softpipe is broken
* eric_engestrom got confused with acronyms for a minute
<eric_engestrom> I'm talking about !29771 "glx/egl/gbm: link directly to gallium"
sarnex has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
<jenatali> daniels: It's a gitlab bug that's causing the errors to be missing. The raw view has it: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61220682/raw
<jenatali> LINK : fatal error LNK1181: cannot open input file 'z.lib'
<jenatali> Looks like maybe LLVM_ENABLE_ZLIB ?
Guest313 has quit []
yrlf has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
yrlf has joined #dri-devel
<jenatali> I don't understand what changed but I can work around it at least
<jenatali> Oh cool
<daniels> eric_engestrom: yeah, I’m talking about a DRI3 MR
simon-perretta-img has quit [Read error: Connection reset by peer]
<daniels> jenatali: oh! I didn’t even think of looking at the raw view … how bizarre
frieder has quit [Remote host closed the connection]
<jenatali> daniels: I pushed an alternate workaround to your MR and kicked off the first container build
simon-perretta-img has joined #dri-devel
<daniels> jenatali: thankyou so much
LeviYun has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<Lynne> is there's anyone here who's truly pedantic about the vulkan spec, is dedicated allocation meant to work with host mapping?
<Lynne> because with host mapping, you're required to use the memoryTypeBits given by vkGetMemoryHostPointerPropertiesEXT, which disregards the bits that vkGetBufferMemoryRequirements2 returns and you're also meant to use
<Lynne> or are you supposed to take the AND of the flags?
rasterman has joined #dri-devel
LeviYun has joined #dri-devel
riteo has joined #dri-devel
glennk has quit [Remote host closed the connection]
coldfeet has joined #dri-devel
nerdopolis has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
<eric_engestrom> daniels: the log viewer is quite buggy, and gitlab is not going to fix it, instead they're working on a replacement once (which also won't have the 500KiB log limit); you can already try it by adding `/viewer` to a job log url (the same url you would add `/raw` to, to get the raw log)
<jenatali> Oh looks to be a problem with stdout vs stederr
<jenatali> stderr*
rasterman has quit [Quit: Gettin' stinky!]
<zmike> eric_engestrom: I did a test pipeline and I think it should merge this time
<zmike> hopefully
<eric_engestrom> zmike: 29771?
<zmike> yes
<eric_engestrom> 💪
<zmike> 🙏
jkrzyszt has quit [Remote host closed the connection]
<daniels> eric_engestrom: this is really good to know, thanks
Company has joined #dri-devel
LeviYun has joined #dri-devel
<jenatali> daniels: libclc and piglit both built successfully in !29649
LeviYun has quit [Ping timeout: 480 seconds]
tiagocandido has joined #dri-devel
tiagocandido has left #dri-devel [#dri-devel]
tiagocandido has joined #dri-devel
tiagocandido has left #dri-devel [#dri-devel]
q66 has quit [Quit: WeeChat 4.0.2]
sima has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
gouchi has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
<karolherbst> jenatali: well.. you can carry the spirv-tools patch and the MR
<karolherbst> maybe we should just merge the mesa MR
<karolherbst> worst case the method name changes
LeviYun has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<zmike> eric_engestrom: !!!
<eric_engestrom> for 29771? I was monitoring it :)
<eric_engestrom> congrats!
<eric_engestrom> that said... radeonsi job (https://gitlab.freedesktop.org/mesa/mesa/-/jobs/61229674) filled with hundreds of `MESA-LOADER: failed to open radeonsi: driver not built!)`... looks like something's wrong :(
<zmike> hmmmmm
* eric_engestrom needs to go to sleep now though
<zmike> seems like that has to be spurious though considering all the baselines are still valid
<zmike> something for tomorrow for sure
<eric_engestrom> daniels: jenatali's windows changes look reasonable to I'm sending !29649 to Marge
heat has quit [Remote host closed the connection]
<eric_engestrom> zmike: thanks for having a look, but yeah the tests are sill passing so it's likely just that we shouldn't print the message
<eric_engestrom> if I don't see anything else in https://gitlab.freedesktop.org/mesa/mesa/-/milestones/47#tab-merge-requests tomorrow morning I'll make the branchpoint :)
<zmike> it seems like it isn't harmful, at the least, but it's confusing how it's reaching that point
<eric_engestrom> agreed
<zmike> sidebar: any idea what's going on with llvm updates?
<zmike> 15 is so old I can't even install it on my distro
heat has joined #dri-devel
<jenatali> What about llvm updates?
LeviYun has joined #dri-devel
<airlied> do we rely on the base distro to update it?
<eric_engestrom> zmike: I assume you mean bump the version used by CI? can you create an issue for this?
<zmike> ok
<eric_engestrom> we can use whatever debian has, so check there too
* eric_engestrom is off for real this time
q66 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Stary has quit [Quit: ZNC - http://znc.in]
Stary has joined #dri-devel
guludo has quit [Quit: WeeChat 4.3.3]
LeviYun has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
cef has quit [Quit: Zoom!]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
cef has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
Company has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
pcercuei has quit [Quit: dodo]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
sukuna has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]