<robclark>
airlied: hmm, the power relays were clicking earlier today.. I can check on it tomorrow morning..
<anholt>
already submitted the mr to marge
<robclark>
hmm, it might be the fault that suspend works on my new threadripper workstation where it didn't on my old intel workstation ;-)
<robclark>
(ie. it might have suspended and killed the network bridge to the fd-farm.. oopps)
<anholt>
robclark: it was right at end of day, so seems likely
<robclark>
guess I need to figure out how to disable suspend
onox[m] has joined #dri-devel
bluetail21 has joined #dri-devel
<jenatali>
They were down early this morning for a little while too
<jenatali>
So, someone not at their workstation seems like a pretty likely culprit for why they'd be down in morning and night :)
heat_ has quit [Ping timeout: 480 seconds]
<anholt>
this morning was probably rob configuring the new workstation
<anholt>
(the lab network in our new building has been a mess, so fd-farm is hanging off of a dev workstation currently)
<robclark>
yeah, this am was probably me juggling things around.. sorry, I completely forgot fd-farm was hanging off a bridge on my workstation because of network issues
<robclark>
I guess we need to come up with a better solution than me being at my desk 24/7
aravind has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
yshui` has joined #dri-devel
Company has quit [Quit: Leaving]
mbrost__ has joined #dri-devel
nielsdg has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
<mareko>
anholt: I've given up on 16-bit support in radeonsi due to no perf gain and a lot of work remaining
<mareko>
anholt: 16-bit tess and GS and transform feedback IO wasn't even started for radeonsi, an int16 loop counter causes an infinite loop (I don't know why), FP16 is mostly OK
<mareko>
anholt: on the hw side, the 16-bit support is solid
Duke`` has joined #dri-devel
<mareko>
I don't think it's humanly possible to do lower_precision fully and correctly in GLSL IR
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
tleydxdy has joined #dri-devel
kts has joined #dri-devel
itoral has joined #dri-devel
Mis012[m] has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<pq>
kchibisov, I tought you *can* do transparent X11 windows on EGL if you choose the EGLConfig based on the NativeVisualId and run a compositing manager? Specifically with Mesa (only?).
<pq>
all the hassle around that was about which EGLConfig to return first in eglChooseConfig() for apps who do not bother checking NativeVisualId but just blindly pick the first config.
kts has quit [Remote host closed the connection]
<MrCooper>
Shibe: FWIW, OBS' FFMPEG VAAPI encoder works, maybe you can take a look at that
FireBurnUK has quit [Read error: Connection reset by peer]
FireBurnUK has joined #dri-devel
<MrCooper>
emersion: FWIW, drivers/gpu/drm/amd/amdgpu/dce_v*.c is the non-DC display code (which doesn't support atomic KMS); DC supports DCE display blocks as well though
<emersion>
hmm
<emersion>
then i think my patch enables it on DC
mbrost__ has quit [Ping timeout: 480 seconds]
<kchibisov>
pq: I've tried to go through all the configs and check whether the visual has alpha mask and none of them had.
<pq>
kchibisov, that's odd.
<kchibisov>
But there's MR to fix that in mesa, there was a way to pick that before.
<kchibisov>
I'm not sure what happens now if you try to choose config with a visual that has alpha.
<pq>
sounds like Mesa EGL simply doesn't list any such currently
<kchibisov>
I know that if you try to choose without passing visual and check all configs afterwards you won't get any of them with alpha.
<pq>
NativeVisualId is explicitly ignored by eglChooseConfig, you cannot avoid checking it manually
<kchibisov>
Ah, ok.
lynxeye has joined #dri-devel
<pq>
reading the hints there, I suppose the transparent visual configs were dropped because many apps blindly pick the first config from eglChooseConfig, and ordering those configs after the configs that naive apps expect was against the EGL spec...
<emersion>
ew
<emersion>
that isn't great
<emersion>
i was about to say that i still have alpha channels on X11, but then i remembered that i don't use EGLConfig
<pq>
this is just my guess, I was hoping the MR or patches would point to the original commits that removed the transparent configs, but I haven't found any reference.
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
<pq>
I have a really hard time understanding the code in that commit. It is adding a condition to return NULL more, but the description says it allows more.
CME has quit []
<pq>
oh well.
MrCooper has quit [Read error: Connection reset by peer]
MrCooper has joined #dri-devel
pcercuei has joined #dri-devel
pinchart1 has left #dri-devel [#dri-devel]
pinchartl has joined #dri-devel
kts has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
saurabhg has quit [Read error: Connection reset by peer]
fahien has joined #dri-devel
dakr has joined #dri-devel
pixelclu- has quit []
pixelcluster has joined #dri-devel
mvlad has joined #dri-devel
bl4ckb0ne_ has left #dri-devel [#dri-devel]
bl4ckb0ne has joined #dri-devel
pq has quit [Quit: brb]
Haaninjo has joined #dri-devel
pq has joined #dri-devel
ayaka_ has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
camus has quit []
TMM_ has quit []
TMM has joined #dri-devel
camus has joined #dri-devel
devilhorns has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
kts has joined #dri-devel
dv_ has quit [Quit: WeeChat 2.8]
fahien has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
itoral has quit [Remote host closed the connection]
i-garrison has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
<emersion>
oh damn this dri3_find_back() is a bit of a mess :/
i-garrison has joined #dri-devel
<kisak>
morning karolherbst, is #7117 bad enough to be considered getting tagged with the 22.2 Release Blocker milestone, or is VirtIO off the beaten path?
off^ has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
kts has quit [Quit: Konversation terminated!]
fahien has quit [Quit: fahien]
fahien has joined #dri-devel
kts has joined #dri-devel
hch12907_ has joined #dri-devel
hch12907_ has quit []
aravind has quit [Ping timeout: 480 seconds]
fahien has quit [Quit: fahien]
devilhorns has quit [Remote host closed the connection]
<karolherbst>
kisak: 7117 breaks all nv50
devilhorns has joined #dri-devel
<karolherbst>
ehh wait
<karolherbst>
well "breaks"
sdutt has joined #dri-devel
<karolherbst>
it's caused by moving to nir or ntt in nv50
<karolherbst>
but it's just some artifacts... still annoying
sdutt has quit [Read error: Connection reset by peer]
<karolherbst>
mhh looks not that bad with gnome e.g.
<karolherbst>
but I honestly have no idea what's broken...
<kisak>
^functional part of my question was if you wanted to tag some things release blocker so that it triggers a discussion between you and dcbaker before 22.2.0 is released without consideration to the state of nouveau.
<karolherbst>
kisak: I suspect that 7117 _could_ break other drivers as well
<karolherbst>
nv50 isn't the only one which moved to nir/ntt
<karolherbst>
so... maybe?
fxkamd has joined #dri-devel
<karolherbst>
but it's breaking nv50 alright, so normally I'd consider it a blocker
<karolherbst>
r600 also moved to nir, right?
<kisak>
if I was paying attention, yes, that got turned on by default.
<karolherbst>
might make sense to check if gnome and other desktops show the same behavior with r600
<karolherbst>
because atm it's a bit odd that we are hitting it
<karolherbst>
nvc0 uses the same code path to go from nir to our backend compiler (which is shared between nv50 and nvc0) and I didn't
<karolherbst>
I'll look into this issue today anyway so maybe I'll figure something out, but given that TGSI vs NIR is the regression...
kts has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
kts has joined #dri-devel
sdutt_ has quit []
sdutt has joined #dri-devel
warpme___ has joined #dri-devel
sarnex has quit [Quit: Quit]
sarnex has joined #dri-devel
<karolherbst>
kisak: heh.. it seems to only happen with the modesetting DDX here... nouveau and wayland are both fine
<karolherbst>
do we have tests for glamor or something? Or a solid way of identifying issues with glamor?
bluetail21 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
heat_ has joined #dri-devel
devilhorns has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
<MrCooper>
karolherbst: Xwayland also uses glamor, does it happen with that as well?
LexSfX has joined #dri-devel
Duke`` has joined #dri-devel
fxkamd has quit []
ybogdano has joined #dri-devel
<jekstrand>
hakzsam: Done! The radv rebase was trivial, just dropping patches. The feedback loop one hit a "real" conflict with your adding of AMD sample locations but was easy to sort out.
<hakzsam>
thanks
kts has quit [Ping timeout: 480 seconds]
khfeng has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
Company has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
<jekstrand>
anholt: Does deqp-runner have any weird serialization points? I'm looking at top for my current run and I'm seeing long (multi-second) periods where there are only a couple deqp-vk instances or none at all even though I'm running on a 36-thread machine.
<jekstrand>
Maybe it's blocking on I/O recording results and stderr dumps?
<karolherbst>
MrCooper: indeed
<anholt>
jekstrand: interesting, not something I've caught. there are 36 deqp-runner threads looping spawning deqp processes, so you shouldn't have any starvation unless, yeah, i/o starvation before starting the next process. another thought would be if the channel for reporting results to the display/results management thread wasn't getting drained, but that seems real unlikely.
<anholt>
you aren't swapping, are you? ;)
<jekstrand>
I shouldn't be
<jekstrand>
I've got 64GB of ram in that box
kts has joined #dri-devel
<karolherbst>
jekstrand: top is probably not reliable here
<jekstrand>
lol, aparently I have an 8G swap partition on my machine with 64G of ram. (-:
<karolherbst>
jekstrand: on fedora? yeah....
<karolherbst>
fedoras partition layout comes straight from hell
<karolherbst>
but it might also be zram
<karolherbst>
where... having just 8GB of zram is a bit odd
<karolherbst>
but it might be capped or something
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
<karolherbst>
could check with the tab completion of swapoff :D
idr has quit [Quit: Leaving]
<jekstrand>
It may also be I/O buffering because it's running inside of screen (in case my SSH connection dies) and spewing piles of data to stderr.
<karolherbst>
or it's when the kernel cleans up dead processes and they are in Z/D state or something and it just takes a while
<jekstrand>
yeah
sobkas_ is now known as sobkas
soreau has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
soreau has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
devilhorns has quit []
<cwabbott>
jekstrand: is it important that vk_pipeline_cache_add_object returns the old object instead of replacing it with the new one? I kind of want to change it
<cwabbott>
some background: for turnip I added a one-step cache similar to radv that goes straight from shaders + layout -> binaries
<cwabbott>
I'm now implementing GPL and in the process I need to store the NIR as well when RETAIN_LINK_TIME_OPTIMIZATION_INFO is set
ybogdano has quit [Ping timeout: 480 seconds]
<cwabbott>
so far, it seems like the easiest way to implement it is to save off the NIR directly after linking and make it an (optional) part of the cache entry
<cwabbott>
the only problem is when someone compiles a pipeline without the bit and then again with the bit, we'd need to then notice that the cache entry doesn't contain the NIR we need, recompile the pipeline and then "upgrade" the cache entry
<cwabbott>
that seems easier than having another type of cache entry - we'd have to duplicate all the boilerplate to set it up, free it, etc.
ybogdano has joined #dri-devel
CME has joined #dri-devel
<jekstrand>
cwabbott: The original idea was that such conflicts only arise if you lose a race in which case, since other threads/objects area already using the one in the cache, it's better to use the same one everywhere rather than potentially ending up with two copies burning memory.
ngcortes has joined #dri-devel
Dr_Who has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lemonzest has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
mbrost has joined #dri-devel
kts has joined #dri-devel
Dr_Who has joined #dri-devel
Dr_Who has quit []
<dcbaker>
kisak, karolherbst would you prefer another rc today, to have another week to look into that?
Dr_Who has joined #dri-devel
<karolherbst>
dcbaker: yeah
<dcbaker>
sounds good
<karolherbst>
also because of 18236, which I probably just merge today... :( seems like nouveau went into "merge patches without review" phase :/
<dcbaker>
I've been in the woods of failed critical infrastructure all week anyway :/
<karolherbst>
ouch
<dcbaker>
don't let your employer turn off the power, lol