<bluetail>
I mean, disabling without working on the kernel, perhaps even something simpler? Forcing performance mode to true didnt help
stuarts has quit []
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
LuckyKnight has quit [Ping timeout: 480 seconds]
ybogdano is now known as Guest7113
Guest7094 is now known as ybogdano
krushia has quit [Quit: Konversation terminated!]
krushia has joined #dri-devel
avocicltb^ has joined #dri-devel
FireBurn has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
smiles has quit [Ping timeout: 480 seconds]
<agd5f>
bluetail, I doubt you are using MPO. Not many desktops use overlays at this point
Zopolis4 has joined #dri-devel
Guest7113 has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
ybogdano is now known as Guest7126
ybogdano has joined #dri-devel
camus1 has quit []
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
agd5f_ has joined #dri-devel
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
wooosaiii has quit [Remote host closed the connection]
wooosaiii has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
bmodem has joined #dri-devel
camus has joined #dri-devel
agd5f has joined #dri-devel
lemonzest has joined #dri-devel
camus has quit []
bmodem has quit [Ping timeout: 480 seconds]
sgruszka____ has joined #dri-devel
bmodem has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
sgruszka____ has quit [Remote host closed the connection]
sgruszka has joined #dri-devel
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
a-865 has quit [Quit: ChatZilla 0.15 [SeaMonkey 2.53.15/20230108172623]]
a-865 has joined #dri-devel
kzd has quit [Quit: kzd]
a-865 has quit []
camus has quit [Remote host closed the connection]
heat has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
bmodem has quit [Read error: Connection reset by peer]
agd5f has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
bmodem has joined #dri-devel
bgs has joined #dri-devel
a-865 has joined #dri-devel
wind has joined #dri-devel
windleaves has quit [Ping timeout: 480 seconds]
jaganteki has quit [Remote host closed the connection]
ahajda_ has joined #dri-devel
bluetail has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
bluetail has joined #dri-devel
bgs has quit [Remote host closed the connection]
sgruszka has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
itoral has joined #dri-devel
Duke`` has joined #dri-devel
tzimmermann has joined #dri-devel
danvet has joined #dri-devel
fab has quit [Quit: fab]
avocicltb^ has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
windleaves has joined #dri-devel
rszwicht has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
rszwicht has quit []
wind has quit [Ping timeout: 480 seconds]
wind has joined #dri-devel
MajorBiscuit has joined #dri-devel
windleaves has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
MajorBiscuit has quit []
MajorBiscuit has joined #dri-devel
windleaves has joined #dri-devel
fab has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
wind has quit [Ping timeout: 480 seconds]
ice9 has joined #dri-devel
JohnnyonF has joined #dri-devel
hansg has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
vliaskov has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
tursulin has joined #dri-devel
ice9 has quit [Read error: Connection reset by peer]
lynxeye has joined #dri-devel
Scorpi has left #dri-devel [#dri-devel]
ice9 has joined #dri-devel
jkrzyszt has joined #dri-devel
rasterman has joined #dri-devel
kode548 has joined #dri-devel
cmarcelo has quit [Remote host closed the connection]
kode54 has quit [Read error: Connection reset by peer]
wind has joined #dri-devel
rszwicht has joined #dri-devel
<eric_engestrom>
is there a way to get deqp to print its version? there's no `--version`
<vliaskov>
jadahl ajax gnome-shell/x11-backend mutter crashes on intel using Mesa 23.0.0 https://pastebin.com/52uFkWp5 , the culprit Mesa commit is "19c57ea3 glx: Remove pointless GLX_INTEL_swap_event paranoia". Is that event really supposed to be handled differently by mutter as that commit suggests, or did Mesa glx drop the ball here?
<eric_engestrom>
I'm asking because it looks like hakzsam's cts update wasn't applied to the debian/armhf_test container as it doesn't have some tests, but printing the version would confirm that
<jadahl>
vliaskov: that'd mean we got a glx swap buffer event without doing a swapbuffer, which seems to be what that commit was being (seemingly rightfully) paranoid about
<vliaskov>
thanks jadahl, let's continue in the bug
smiles has joined #dri-devel
<MrCooper>
lina: the deadlock described by Christian is real, though very subtle
<MrCooper>
I'd advise saving the time & energy arguing against that
kode548 has left #dri-devel [#dri-devel]
kode54 has joined #dri-devel
<kode54>
how useful, my client can't auto recover my name due to registration quiet rules
<MrCooper>
what registration quiet rules?
<kode54>
+M moderation of unregistered users
<MrCooper>
that was an issue for me before on FreeNode, not here though
<kode54>
network somehow didn't decide to match my client cert because the name didn't match
<kode54>
oh well
<MrCooper>
authenticating with NickServ works for me even while I'm on channels with +M
<kode54>
this network is set to client cert sasl rather than nickserv
<emersion>
kode54: yeah i've hit this as well, this is so annoying
<emersion>
OFTC for the win :S
<emersion>
MrCooper: happens when the client degrades to an alt-nick
<kode54>
I mean, libera and freenode had the same rule with nick degrading to an alt nick on registration only moderated channels
<emersion>
libera has SASL
<MrCooper>
right, but in contrast to FreeNode before, authenticating with NickServ works after that and changes to the proper nick
<kode54>
freenode never changed your nick automatically
<kode54>
though some clients, notably peter pawlowski's client, would forcibly do the full auth handshake before rejoining channels
ice9 has quit [Remote host closed the connection]
ice9 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
<MrCooper>
lina: FWIW, the deadlock doesn't happen in any of the code touched by your series, but deep down in the core kernel MM code
kts has quit [Quit: Konversation terminated!]
lemonzest has joined #dri-devel
jaganteki has joined #dri-devel
jaganteki has quit [Remote host closed the connection]
MajorBiscuit has quit [Quit: WeeChat 3.6]
lanodan has quit [Ping timeout: 480 seconds]
rszwicht has quit []
ruper has joined #dri-devel
rszwicht has joined #dri-devel
lanodan has joined #dri-devel
frieder has joined #dri-devel
rszwicht has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #dri-devel
robert_mader has joined #dri-devel
robert_mader has left #dri-devel [#dri-devel]
Zopolis4 has quit []
lanodan has quit [Ping timeout: 480 seconds]
lanodan has joined #dri-devel
ice9 has quit [Remote host closed the connection]
ice9 has joined #dri-devel
<eric_engestrom>
hakzsam: I think f775873f81d1b8dd01e9b should have bumped DEBIAN_BASE_TAG as well?
<eric_engestrom>
we really need some way to document this
<eric_engestrom>
perhaps at the top of each file we could list the image tags that need to be updated
windleaves has joined #dri-devel
<mupuf>
+1 for that
wind has quit [Ping timeout: 480 seconds]
wind has joined #dri-devel
windleaves has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
<hakzsam>
did I make a mistake?
<zmike>
gasp
LuckyKnight has joined #dri-devel
srslypascal is now known as Guest7167
srslypascal has joined #dri-devel
LuckyKnight has quit []
LuckyKnight has joined #dri-devel
Guest7167 has quit [Ping timeout: 480 seconds]
pa has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
gerddie has joined #dri-devel
<eric_engestrom>
I think? but it's basically impossible to know which deqp version is running so I'm not sure
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
itoral has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
<javierm>
jfalempe, tzimmermann: do you know why virtgpu doesn't advertise FB_DAMAGE_CLIPS ?
<javierm>
AFAICT it already has a .dirty callback and calls drm_atomic_helper_damage_merged() in it's primary plane update callback
<tzimmermann>
javierm, it should
<javierm>
tzimmermann: yeah, that's what I thought. A colleague mentioned to me and I suggested him to post patch to call drm_plane_enable_fb_damage_clips()
<javierm>
I believe that should be enough
<tzimmermann>
but i recently had a discussion about this with danvet. and it sounded like it was deliberatly doing things differently. i just don't really remember if this was part of it
<tzimmermann>
maybe post that patch and wait for feedback
<javierm>
tzimmermann: maybe your discussion was about why it was not using the GEM shmem helpers ?
ice9 has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, no IIRC the discussion was about the use of shadow planes. but i don't remember the details. and now that i think about it, i might be confusing virtgpu with vkms here
<danvet>
tzimmermann, I think "forgot to enable the atomic property for damage update" is just lack of userspace using that
<danvet>
I don't have any memories why a driver would not do that
<danvet>
maybe we should have a check that if you have a ->dirty callback, are atomic but didn't enable atomic property, then WARN()
<danvet>
but would need a check to make sure drivers do this
<tzimmermann>
me neither. maybe i'm really confusing things between virtio and vkms here
<danvet>
vkms is the other way round
<tzimmermann>
danvet, we have a check in the damage helpers already. virtgpu already warns
<danvet>
it can enable the property, but it still needs to compute the crc over the entire thing
<tzimmermann>
danvet, right. i think that's what the discussion was about
<danvet>
tzimmermann, yeah that discussion I remember, but nothing about virtio
<danvet>
probably just a virtio oversight to not enable that
<danvet>
btw where's that warning?
<tzimmermann>
javierm, cirrus and a bunch of others also warned. it's just that no one cared much, because it's an optimization that it not immediately recognizable
<danvet>
there's much less atomic userspace that supports damage than legacy dirtyfb damage
<javierm>
tzimmermann: Ok, I'll tell him then to post a patch
<javierm>
danvet, tzimmermann: thanks for the confirmation. It looked to me that was just missing that but wondered why was missing
<javierm>
"nobody cared" is a good answer :)
<danvet>
lol I even wrote that
<danvet>
and yeah I didn't find it because I was looking in the helpers
<danvet>
tzimmermann, thx
hansg has quit [Quit: Leaving]
<tzimmermann>
danvet, and we had that same conversation just a few weeks ago where you asked me about this warning :D
<javierm>
haha
junaid has quit [Remote host closed the connection]
<danvet>
sometimes I'm a bit too stateless
<javierm>
I also noticed that the virtgpu driver is using drm_atomic_helper_damage_merged()
<javierm>
wonder when that is the correct thing to do over iterating over the damage areas
<javierm>
I guess if doing a big rectangle update is more efficient that doing many small updates
<javierm>
but probably not the case for virtgpu and more for small I2C/serial panels?
<tzimmermann>
javierm, that would be my guess as well
<javierm>
tzimmermann: Ok. I'll suggest him to look at that as well. Thanks!
<tzimmermann>
but it probably depends on the exact size of the big retangle and the number of extra pixels
<javierm>
tzimmermann: yeah, in general should be about the same. But I remember jfalempe had some perf issues on some old gfx cards
<javierm>
because the damage clips where too far away so the resulting rectangle was quite big
<tzimmermann>
javierm, IIRC i had this dicussion with jfalempe wrt mgag200. he mentioned that damage_merged() was always slower than individual updates
<javierm>
tzimmermann: right, that's the discussion I was remembering
<jfalempe>
javierm, yes it matters on mgag200, the graphic memory is very slow
<tzimmermann>
my take is to remove damage_merged() entirely and leave it to compositors. they can track how much overlap updates have and merge areas in userspace already
<javierm>
tzimmermann: 100%
<jfalempe>
and I had the case where you move the pointer at one corner of the screen, and the date/or some UI element updates at the other corner, triggering a full repaint.
dtmrzgl has quit []
<javierm>
jfalempe: that's an excelent example indeed
<javierm>
tzimmermann, jfalempe: should we add that item to the TODO ?
<tzimmermann>
javierm, sure why not
<javierm>
tzimmermann: Ok
dtmrzgl has joined #dri-devel
<tzimmermann>
there aren't too many users of the function
<javierm>
tzimmermann: right. Then we can just address it in a patch series
<tzimmermann>
javierm, i know of one exception in ast: the cursor code needs to update the full 64x64 rectangle. damage_merged is used to test if there are any image updates at all. maybe other drivers have a similar requirement
<tzimmermann>
i do have an update for cirrus already. i just need to preapre another patchset
<javierm>
tzimmermann: I see. And then maybe makes sense to just disable damage clips for the cursor plane?
<javierm>
and only keep it enabled for the primary plane
<tzimmermann>
javierm, no. please keep it as-is. we don't want to update the cursor image unconditionally. the damage helpers are there for this situation
<tzimmermann>
ast cannot update only a sub-image of the cursor because there's some checksum computation involved. this needs the whole image. but it's only 64x64
kts has quit [Quit: Konversation terminated!]
<javierm>
tzimmermann: right. So the damage helpers are used to determine whether the cursor has to be updated or not, but when it does is the full 64x64 rectangle
<tzimmermann>
right
<javierm>
hmm, for this case the helper does fit quite well
<javierm>
tzimmermann: I think that won't touch anything then, as it seems that whether using a merged rectangle or iterating over the damage areas is really on a case by case basis
<tzimmermann>
javierm, it might make sense to review all instances. i think ast is a bit of a special cases here
fxkamd has quit [Remote host closed the connection]
<lina>
MrCooper: Sorry, I wasn't checking IRC... but I'm kind of confused now, I thought he was talking about the signaling logic for forward progress of the scheduler, not MM/alloc related deadlocks...?
<lina>
I know there's a lot of subtlety around the MM stuff I don't understand yet, and we did touch on that in the thread, but I don't think that's what the argument was about...
MrCooper has quit [Remote host closed the connection]
<javierm>
lina: is pretty amazing the work you are doing, thanks a lot for paving the road for future rust DRM drivers :)
Haaninjo has joined #dri-devel
jaganteki has joined #dri-devel
MrCooper has joined #dri-devel
<lina>
Thank you! ^^
fab has quit [Quit: fab]
<ccr>
=)
MrCooper has quit [Quit: Leaving]
aravind has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
kzd has joined #dri-devel
ajhalaney[m] has joined #dri-devel
vliaskov has quit [Quit: Leaving]
tursulin has quit [Ping timeout: 480 seconds]
phasta_ has joined #dri-devel
fab has joined #dri-devel
fxkamd has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
<danylo>
In Freedreno (partially) and Turnip we are thinking about moving to C++ to use templates instead of genX macros to share code between gens (Turnip currently works only on a single gen, Freedreno just duplicated code), and to have nice c++ things. Anyway, there are no troubles with gallium driver, but with Turnip I'm not so sure, since e.g. previously Dozen used C++ for a bit but went back to C afterwards. Though it was done, from what I saw,
<danylo>
for reasons mostly not relevant to us (like older msvc compiler and lack of CI testing). After silencing a number of warnings, putting a big '-fpermissive', some changes to Turnip, and a few small changes to common code - Turnip compiled as C++. Templated entrypoints look good enough, works like this: https://godbolt.org/z/hf5rPE1E1.
<danylo>
Any downsides of going this way?
<zmike>
gallium drivers have been doing template functions for a while
<zmike>
seems fine
hazl has joined #dri-devel
<danylo>
It's probably less about whether driver would be fine and a bit more about whether common code would be fine. Dozen returning to C was almost a year ago, now I had to make only a few small changes to common code, so from my POV it would be fine, but I have a terrible overview of things =)
<hazl>
hooray, another bit of useful info found on the dark souls 3 front: wined3d has no problem, so i guess I'm going to figure out where to take that info
frieder has quit [Remote host closed the connection]
<danylo>
@gfxstrand probably you would have a thought or two on this matter
<hazl>
i'm launching elden ring to see if it does the same thing, and if it does, i'm just going tot stop trying things for now out of fear of working myself up into etching a crucifix into this deck to try to remove the curses
<hazl>
oh wait, i can't, dx12 wouldn't allow that. it has the same issues i was finding in ds3 with not wanting to get past 40-50fps and being unstable on frame pacing
cphealy has quit [Quit: Leaving]
LuckyKnight has joined #dri-devel
LuckyKnight has quit []
Scorpi has joined #dri-devel
bgs has joined #dri-devel
<anholt_>
Looks like mesa-swrast-* got owned last night. it'll be a bit until I can make new vms and upgrade and such so it hopefully doesn't happen again.
cmarcelo has joined #dri-devel
lstrano_ has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
ahajda_ has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
cphealy has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
phasta_ has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
smiles has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.6]
neobrain has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
neobrain has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
ddavenport has joined #dri-devel
idr has joined #dri-devel
<idr>
So.... are we just not able to have MRs land?
<cmarcelo>
?
<idr>
Because now DavidHeidelberg[m] has manually unassigned my MR from marge, so... what's the deal?
<daniels>
idr: they can land, just exceptionally painfully
<swiftgeek>
it says tracker, so I would assume it's somewhere inside mesa?
<swiftgeek>
ah thaks
<swiftgeek>
*thanks
<swiftgeek>
> should investigate sharing the loadig mechanism with the EGL gallium frontend.
<swiftgeek>
that's a typo isn't it
Cyrinux9 has quit []
alanc has quit [Remote host closed the connection]
<robclark>
sounds like it
alanc has joined #dri-devel
Cyrinux9 has joined #dri-devel
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
<anholt_>
daniels: so, I don't see an equivalent thing to metal's userdata for gcloud instance creation?
khfeng_ has joined #dri-devel
<hazl>
i just realized (for the dark souls 3 issue) that with wined3d it shouldn't (??) be able to use the steam shadercache that dxvk uses but there isn't any noticable stuttering loading in or running around and that means it's either generating shaders very fast or managing to use the compatdata vulkan cache
kts has quit [Quit: Konversation terminated!]
<anholt_>
I do like the idea of this script that brings up the instance, rather than building them from disk snapshots I've incrementally built up, but I think I'd have to write my own init?
khfeng has quit [Ping timeout: 480 seconds]
<anholt_>
something something instance metadata and maybe a specific boot os and it works?
<daniels>
anholt_: yeah, set the metadata field of the VM, and at least Debian expected that (if it started with '#cloud-config') to contain cloud-init stuff
Thymo has joined #dri-devel
<DemiMarie>
anholt_: do you know how they got pwned?
Ahuj has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
ngcortes has joined #dri-devel
Kayden has quit [Quit: to office]
ngcortes has quit [Ping timeout: 480 seconds]
<anholt_>
DemiMarie: no
<anholt_>
but we run arbitrary code from users, so :shrug:
<DemiMarie>
anholt_: do you spin up a new VM for each run?
<anholt_>
no, that's too slow.
<DemiMarie>
do the CI runs need access to the GPU?
<anholt_>
no, this is swrast.
<DemiMarie>
first suggestion would be to make sure your containers are unprivileged (uid 0 on host not mapped in container) and that you have SELinux enforcing
<DemiMarie>
Also check your host kernel; kernels from distros like RHEL are often out of date
<kisak>
This is probably not the best channel to do a brain dump of every hypothetical security best practice.
<DemiMarie>
kisak: fair
<anholt_>
also, you lack a lot of context, so generic suggestions are not very helpful.
ybogdano has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Guest7036 has quit [Ping timeout: 480 seconds]
Zopolis4 has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
nchery is now known as Guest7203
nchery has joined #dri-devel
ngcortes has joined #dri-devel
gouchi has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
linkmauve has joined #dri-devel
<demarchi>
mattrope: do you know if we have a drm_printer that is equivalent to drm_dbg()?
<demarchi>
I see we have drm_debug_printer, but that is not the same
<demarchi>
all the callsite decoration is gone with that one
Duke`` has quit [Ping timeout: 480 seconds]
psykose has joined #dri-devel
ybogdano has joined #dri-devel
fab has quit [Quit: fab]
nchery has quit [Ping timeout: 480 seconds]
<mattrope>
demarchi: I don't think we have drm_printers equivalent to the drm_device-centric drm_dbg/drm_err/etc. print calls yet.
<demarchi>
the drm_info_printer() is the closest one since it receives the device as param
<demarchi>
but even that is not the same
Ryback_ has joined #dri-devel
bgs has quit [Remote host closed the connection]
nchery has joined #dri-devel
Cyrinux9 has quit []
Cyrinux9 has joined #dri-devel
<robclark>
the drm_printer thing is mainly intended to have something to share code between things like debugfs and other things.. not sure if call-site annotation makes sense for that, but if there is a use-case you can add drm_print_dbg() or something along those lines
stuarts has joined #dri-devel
<demarchi>
robclark: my use case is exactly for that. There is the debufs file that dumps the content of a table, and during the driver probe we also print entry by entry while applying
<demarchi>
robclark: I will take a look into adding a drm_print_dbg() later if I have a few more users
<demarchi>
thanks
gouchi has quit [Remote host closed the connection]