ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
T_UNIX has quit []
lplc has joined #dri-devel
alpalcone has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
Eighth_Doctor has quit []
columbarius has joined #dri-devel
zzoon_holidays_till_21th[m] has quit []
co1umbarius has quit [Ping timeout: 480 seconds]
<alyssa>
psykose: Seemingly no regressions
<alyssa>
But in addition to the pixmark-piano hash changing (which I think we agreed is fine), there seems to be a legit regression iris-whl to the freedoom trace
<alyssa>
Not sure I can figure that one out without hardware..
<alyssa>
(Also weird to me that it's only happening on WHL, the other iris jobs are fine?)
<alyssa>
Maybe one of the Intel people has an idea why Whiskeylake is special?
<alyssa>
(is it drunk)
Leopold___ has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Leopold_ has quit [Ping timeout: 480 seconds]
smiles_1111 has joined #dri-devel
penguin42 has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
Celmor[m] has quit []
samueldr has quit [Quit: Client limit exceeded: 20000]
ngcortes has quit [Read error: Connection reset by peer]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
gallo[m] has quit []
benjamin1 has quit [Ping timeout: 480 seconds]
pac85[m] has quit []
benjamin1 has joined #dri-devel
cwfitzgerald[m] has quit [Quit: Client limit exceeded: 20000]
idr has quit [Quit: Leaving]
benjamin1 has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
q4a has quit []
Weiss-Fder[m] has quit []
bmodem has joined #dri-devel
doras has quit []
simon-perretta-img_ has joined #dri-devel
Company has quit [Quit: Leaving]
simon-perretta-img__ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest3906
rsalvaterra_ is now known as rsalvaterra
benjamin1 has quit [Ping timeout: 480 seconds]
Guest3907 has quit [Ping timeout: 480 seconds]
sumoon has quit [Remote host closed the connection]
kchibisov has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
ella-0 has quit [Remote host closed the connection]
rpigott has quit [Read error: Connection reset by peer]
kennylevinsen has quit [Remote host closed the connection]
ella-0 has joined #dri-devel
kennylevinsen has joined #dri-devel
ifreund has joined #dri-devel
kchibisov has joined #dri-devel
sumoon has joined #dri-devel
rpigott has joined #dri-devel
rosefromthedead has joined #dri-devel
benjamin1 has joined #dri-devel
JosExpsito[m] has quit [Quit: Client limit exceeded: 20000]
benjamin1 has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
reactormonk[m] has quit [Quit: Client limit exceeded: 20000]
vidal72[m] has quit []
<kurufu>
Is it legal to call vkDestroySurfaceKHR twice with the same handle? The usages say the handle must be valid, but not that a destroyed handle is invalid...
bgs has joined #dri-devel
fab has joined #dri-devel
jewins has quit [Remote host closed the connection]
<cmarcelo>
kurufu: spec in section 3.3 talks a bit about it but not a definitive answer. I'd expect once you destroyed the same amount of times you got that handle, it will become invalid. have you tried using the validation layer to see if it complains about it?
<kurufu>
Thats a good idea, i have not.
jewins has joined #dri-devel
<cmarcelo>
(if its not an unique kind of handle, if it is unique, then you can get and destroy only once *that particular one*)
<kurufu>
I imagine surfaces are unique... hopefully the validator just calls it bad.
pallavim__ has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
bgs has quit [Remote host closed the connection]
agd5f_ has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
aravind has joined #dri-devel
fab has quit [Quit: fab]
rasterman has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
alanc has quit [Remote host closed the connection]
sima has joined #dri-devel
alanc has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
AndrewR has quit [Remote host closed the connection]
Cyrinux9 has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
Cyrinux9 has joined #dri-devel
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
frankbinns has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<mairacanal>
Is it possible to call copy_to_user() inside a run_job() DRM sched callback? I'm trying to do this and copy_to_user() is sometimes failing...
deathmist1 has quit [Remote host closed the connection]
deathmist1 has joined #dri-devel
kts has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
deleting nir_registers+abs+negate+sat is going to make nir soooo nice
<doras>
It worked fine with older kernel versions (can't say exactly which, though). Cursor movement was matching the update rate of the primary plane.
<doras>
This issue actually results in a "violation" of the atomic promise of KMS commits regardless of VRR; both the cursor and primary planes are committed together, but only the state of the primary plane is applied.
<doras>
I added this information to the issue just in case.
alyssa has left #dri-devel [#dri-devel]
JohnnyonFlame has joined #dri-devel
<hwentlan_>
doras, thanks for the regression info. might be good to try 5.18 and then bisect if it's not reproducible there
<hwentlan_>
I agree it is a violation of the atomic promise
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
<bbrezillon>
dakr: Are we sure drm_gpuva_remap() will never allocate stuff for the maple tree insertion of prev/next?
<bbrezillon>
feels like we should pre-allocate for those too
<bbrezillon>
and if not, it probably deserves a comment
fab has joined #dri-devel
<bbrezillon>
nevermind, if we end up remapping, that means the range was allocated in the maple tree, so we're not allocating
<dakr>
bbrezillon: correct, drm_gpuva_remap() will re-use the nodes of the old mapping. There is no allocation while storing the entry, see mas_store() vs. mas_store_gfp().
<dakr>
Maybe worth noting, there are also cases where we call mas_store() with a 'NULL' entry which possibly frees up nodes which are not needed any longer.
<sima>
emersion, rb:me
<dakr>
While we could potentially re-use them in a subsequent drm_gpuva_map() call, drm_gpuva_map() should carry pre-allocated nodes anyway, plus we could also fail before and hence leak memory otherwise.
<emersion>
thanks!
<emersion>
sima: hmm, dim complains about missing Link
<sima>
emersion, yeah need to submit it and pick it up from the m-l
<sima>
that check is to make sure patches get at least dumped there
<emersion>
ack
pallavim has joined #dri-devel
heat_ has joined #dri-devel
jewins has joined #dri-devel
<bbrezillon>
dakr: sounds good
kzd has quit [Quit: kzd]
<karolherbst>
jenatali: soo yeah.. the flame graph of hashcat I showed you with the massive spvtools::Link thing is indeed caused by linking a single spirv file... I think it's probably better to handle this as a special case inside spirv-tools though and just shortcut it by skipping unneeded things or something
<jenatali>
Yeah probably
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
greenjustin has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
bgs has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
djbw_ has quit [Read error: Connection reset by peer]
djbw_ has joined #dri-devel
cmichael has quit [Quit: Leaving]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
mvchtz is now known as Guest3966
mvchtz has joined #dri-devel
Guest3966 has quit [Ping timeout: 480 seconds]
pallavim has quit [Remote host closed the connection]
pallavim has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
mbrost has joined #dri-devel
krushia has quit [Ping timeout: 480 seconds]
<dcbaker>
karolherbst: the -I stuff should go away when I finish splitting includes from non-includes in all dependencies (currently that's only true for declare_dependency() objects)
<dcbaker>
which, actually, I need to get back to that
kzd has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
APic has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
sgruszka has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
heat__ has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
gouchi has joined #dri-devel
gouchi has quit []
mvlad has quit [Remote host closed the connection]
phasta has quit [Quit: Leaving]
agd5f_ has joined #dri-devel
agd5f has quit [Remote host closed the connection]
gouchi has joined #dri-devel
gouchi_ has joined #dri-devel
gouchi has quit [Read error: Connection reset by peer]
<jenatali>
Not sure if it's identical, honestly this one goes above my head and I haven't looked at the Vulkan one at all
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<cmarcelo>
jenatali: tks
alyssa has joined #dri-devel
<alyssa>
eric_engestrom: interesting case I just hit
pcercuei has quit []
<alyssa>
there's a bug (?) with the vim clang-format integration that if you add a #define above another #define, nothing is formatted but clang-format wants to align them
<alyssa>
my `pub` hook caught this, trivial to fix (modify the second #define in any way whatsoever and the whole block gets fixed up)
<alyssa>
but if I didn't have the whole-file check, I would've missed it and suffered a CI failure
<alyssa>
I imagine git clang-format is susceptible to similar bugs
pcercuei has joined #dri-devel
ngcortes has joined #dri-devel
<dcbaker>
karolherbst: that C++/Rust bug is the bug that keeps on giving. Did you know that rustc on windows unconditionally links to the default MSCRT runtime? Which means if Meson compiles those libraries as debug and links them with the debug runtime linking explodes?
<karolherbst>
uhhhhhhhhhh
<karolherbst>
pain
<dcbaker>
the solution? inject the correct /MDd /MD /MT etc before linking any libraries...
<alyssa>
what if not windows
<dcbaker>
well, then there is not MSCRT...
<dcbaker>
:D
<jenatali>
Wow
<alyssa>
jenatali: sorry 2-1
<karolherbst>
granted the stuff I'm doing inside mesa with rust is also a bit wild
<dcbaker>
The original bug report for this issue is from 2017
<karolherbst>
oh wow
* alyssa
looks for test coverage for multisampled images (incl writes and atomics)
<alyssa>
I see some in Vulkan but I don't have a Vulkan driver yet :O
<alyssa>
s/Vulkan/dEQP-VK/
<jenatali>
alyssa: MSAA storage images are pretty new I think
<jenatali>
I doubt you'll find great GL coverage, if it's even supported there
<alyssa>
right :|
* alyssa
puts on the blindfold
<alyssa>
zink seems to support..
<alyssa>
oh well
<alyssa>
this will be for next week
* alyssa
weekends~
<HdkR>
Weekends, for when real work needs to get done
* alyssa
thinking
Danct12 has quit [Quit: How would you be so reckless with someone's heart!?]
<bluetail>
HdkR idk. I've recently been relaxing a bit more cause I tend to not stop working all the time :D
sima has quit [Ping timeout: 480 seconds]
<bluetail>
I started to finally take a week off...
<HdkR>
Time off? Feels weird
<karolherbst>
what's a time off
<bluetail>
vacation
<bluetail>
its pretty boring but if you are that tired you are basically either on a health checkup at the doc or sleeping all day
jkrzyszt has quit [Remote host closed the connection]
<bluetail>
I never had vacation outside... idk, I am an introvert
<HdkR>
I think I heard about those from fictional stories
* alyssa
thinking
dviola has joined #dri-devel
Danct12 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
jfalempe has quit [Quit: Leaving]
ngcortes has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
dviola has left #dri-devel [WeeChat 3.8]
dviola has joined #dri-devel
kts has joined #dri-devel
<karolherbst>
anholt_: soo.. looking at v3d again. Is there a simple way for me to guarentee I have a compiled shader before launch_grid? The problem I'm seeing is that binding a cso forces a recompile, which... I don't think is a great idea, at least from a CL perspective
<karolherbst>
ehh wait.. v3d_get_compiled_shader would just return a compiled one, okay, no, so that's fine I guess
bgs has quit [Remote host closed the connection]
<karolherbst>
mhh.. not having PIPE_CAP_SHAREABLE_SHADERS also hurts a lot
<karolherbst>
ehh wait, the default is 1 anyway
nielsdg has quit []
jkrzyszt has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<karolherbst>
mhh, it might not be needed in the end, but that kinda depends if all CSOs can be launched wiht 256 threads or not
lemonzest has quit [Quit: WeeChat 3.6]
APic has joined #dri-devel
lemonzest has joined #dri-devel
tanty has quit [Quit: Ciao!]
tanty has joined #dri-devel
frankbinns has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
<alyssa>
eric_engestrom: mupuf: I have circumstantial evidence suggesting that freedoom/freedoom-phase2-gl-high.trace relies on undefined behaviour, reading from uninitialized variables in the shader.
<alyssa>
I have not yet identified the specific issue. But CI (and only CI, not a non-CI machine of the same type, and only WHL despite non-WHL jobs running the same trace) is getting random fails with my register MR
<alyssa>
goes away if GLSL_ZERO_INIT is forced
<alyssa>
It is extremely friday night so I'm not going to pinpoint what's going wrong right now, but taken together this reeks of application bug
<alyssa>
that trace only runs on iris and a6xx... the above is a good argument for removing it (especially if I can figure out next week exactly where it's collapsing)
<alyssa>
Also we should strongly consider forcing GLSL_ZERO_INIT in the premerge trace-based CI, because app bugs here are a dime a dozen
<alyssa>
(Or, frankly, forcing GLSL_ZERO_INIT globally because this is a stupid game of whackamole and the shaders it hurts are usually broken in the first place.)