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 ...
<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>
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.
<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]
<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).
<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: 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
<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
<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 :)