<donaldrobson>
Hello all. I'm quite new to this, so please forgive the question if it should be obvious. Should there be a 1:1 relationship between vulkan semaphores and drm_syncobj?
<ishitatsuyuki>
probably, not sure what are you asking for though
<ishitatsuyuki>
vk_semaphore should back the VkSemaphore if the driver uses the common impl
<donaldrobson>
I'm trying to debug test failures we have with dEQP-VK.synchronization.op.multi_queue.binary_semaphore tests where it seems the kernel isn't waiting for the write to finish before submitting the read. I put extra traces in the kernel to track the drm_syncobj that go with the signals and waits, but they have different addresses. I'm wondering is this means that the read is actually waiting for a different semaphore than is signalled by the write
<tjaalton>
dcbaker: why is staging/23.2 rewriting history, it's missing half of rc3?
xzhan34 has quit [Ping timeout: 480 seconds]
ohmltb^ has quit [Remote host closed the connection]
<mripard>
tzimmermann: thanks ):
<mripard>
* :)
cmichael has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
sre has joined #dri-devel
itoral has quit [Quit: Leaving]
kasper93 has quit [Remote host closed the connection]
yyds has quit [Remote host closed the connection]
Daanct12 has quit [Quit: WeeChat 4.0.4]
kasper93 has joined #dri-devel
tristianc6704 has joined #dri-devel
sgruszka has joined #dri-devel
psykose has quit [Remote host closed the connection]
<karolherbst>
I decided that backends have to do it, but the new pass will clean up some remaining stuff
<austriancoder>
karolherbst: thanks .. will give it a try
<karolherbst>
I think it's the same code you tested already as I don't think I've changed it, I just moved from rusticl into zink. But yeah... you might have to write your own callback or improve what you already have
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
aravind has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
cmichael has quit [Quit: Leaving]
cmichael has joined #dri-devel
bmodem has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
dwlsalmeida has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Company has joined #dri-devel
rgallaispou has joined #dri-devel
<dcbaker>
tjaalton: bisecting regressions I cannot reproduce locally
yuq825 has left #dri-devel [#dri-devel]
<dcbaker>
Which are caused by multiple commits, so once I figure out which commits to remove I’ll put it all back and revert those commits
<tjaalton>
okay
mripard has quit [Remote host closed the connection]
<pq>
I suspect the other one is mostly found only in real-time TV production/broadcasting equipment, though I have some vague recollection that JPEG was supposed to use it but no-one actually did
<pq>
would be nice to see what HDMI and DP use, but I'm not *that* bored :-)
<dcbaker>
karolherbst: we need to rebuild the CI images, I haven't done that in a while, let me check with Eli who's done it more recently
<karolherbst>
okay, cool
jkrzyszt has quit [Ping timeout: 480 seconds]
eukara has quit []
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
ahajda has joined #dri-devel
ahajda has quit []
mripard has quit [Quit: mripard]
<karolherbst>
dcbaker: and any ideas what I can use instead of `version_compare`?
cmichael has quit [Quit: Leaving]
Cyrinux9474 has quit []
Cyrinux9474 has joined #dri-devel
<anholt>
DavidHeidelberg[m]: I'm concerned about the ci-deb-repo plan -- so on every merge to main of that repo, every package gets rebuilt and a new copy of it uploaded into LFS forever? Even if that package wasn't modified by that MR?
vyivel has quit [Read error: Connection reset by peer]
jmondi has quit [Read error: Connection reset by peer]
dviola has quit [Quit: WeeChat 4.0.4]
mvlad has quit [Remote host closed the connection]
vyivel has joined #dri-devel
rasterman has joined #dri-devel
mbrost has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<dcbaker>
karolherbst: hmmm, it's a really annoying problem. You might for now just assume that if `bindgen` is an Executable it's of an appropriate version, but with a TODO comment
<dcbaker>
it isn't actually possible to hit that path ATM, because that would require rust subprojects
sima has quit [Ping timeout: 480 seconds]
<karolherbst>
couldn't Executable also get a get_version function instead though?
<karolherbst>
ehh
<karolherbst>
I guess it's not compiled at that point if it's coming from a subproject :'(
<dcbaker>
Yes, it should. It's just non-trivial to plumb trhough
<dcbaker>
we do this already for dependencies
<dcbaker>
but we need to do it for exectuables as well
<karolherbst>
ahh
<dcbaker>
But currently it isn't possible for it to actually happen, so we could just ignore it it, and I'd be okay with that. I'd even be fine with an assertion and consider it something that needs to be fixed as part of the cargo subproject bringup
<karolherbst>
okay.. how would I check for the actual type in python?
sima has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<dcbaker>
if isinstance(exe, Executable): (or ExternalProgram), whatever makes more sense
<karolherbst>
dcbaker: do I have to do anything to make the linter happy on top of the isinstance check?
<karolherbst>
maybe I should just run the linter locally...
JohnnyonFlame has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
<gfxstrand>
alyssa: RE gl_LayerID, ugh...
<gfxstrand>
alyssa: I really hate that we have all these "is it a sysval?" flags.
<gfxstrand>
alyssa: nir_lower_sysvals_to_varyings is your friend, I think.
<gfxstrand>
alyssa: If we need to add more flags to it, we can do that.
<DavidHeidelberg[m]>
anholt: only if the package is changed. So every other packages remains as it was before, just deb indexes are updated
<anholt>
how is package change being detected? It looked like you're just stuffing all the new debs in the repo.
<DavidHeidelberg[m]>
anholt: by chamge of $package.yml
<DavidHeidelberg[m]>
If it'a not touched, package build is skipped and existing .deb packages will be used
<anholt>
oh, you're enabling jobs conditionally, and using that to only change those debs. interesting.
habernir has joined #dri-devel
habernir has quit []
tursulin has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
eukara has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
KitsuWhooa has quit [Ping timeout: 480 seconds]
xxmitsu has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Kayden has joined #dri-devel
<alyssa>
gfxstrand: that pass is the wrong direction, though
<alyssa>
both glsl and spirv produce varyings for layerid
<alyssa>
it's just vk meta which is producing different nir from vtn
<alyssa>
I think?
<alyssa>
ir3_nir_lower_layer_id does the sysval->varying lowering
<alyssa>
hm
<alyssa>
..how is this supposed to work?
<alyssa>
both glsl and vtn produce a varying, I have no idea where the sysval comes in..
<alyssa>
FFS
<alyssa>
nvk_shader.c turns the sysval back into the varying!!
<alyssa>
this whole thing is a mess
<alyssa>
gfxstrand: can we whack the sysval? who actually wants it?!
<gfxstrand>
Yes, it's a mess
<gfxstrand>
Intel wants it
<gfxstrand>
I'd really rather whack the varying
<alyssa>
Why?
<gfxstrand>
For things like meta, it's SO much easier to just do nir_load_foo
<alyssa>
We can add helpers for that
<alyssa>
But it's logically a varying
<gfxstrand>
Yeah.... IDK.
<gfxstrand>
By what logic?
<alyssa>
VS writes a value and the FS reads whatever the VS wrote
<gfxstrand>
Yeah...
<alyssa>
If you treat it as a varying you'll get the write behaviour
<gfxstrand>
The fact that it's also an output makes that one a bit different...
<gfxstrand>
IDK
<alyssa>
(and Intel could do that, it's just less efficient)
<gfxstrand>
I hate builtins in general. :-P
<alyssa>
The fact that everyone BUT intel wants it as a varying is telling
<simon-perretta-img>
(We also want/would prefer it as a sysval heh)
<alyssa>
and both nvk and ir3 have different code to produce varyings of the sysval due to common code being inconsistent
<alyssa>
simon-perretta-img: >:)
<Kayden>
hang on
<gfxstrand>
So, Intel actually has two things (which is probably why Kayden is confused)
<Kayden>
gfxstrand, alyssa: Sachiel and zmike recently worked with Piers to get the spec for layer-id/viewport-index changed
<alyssa>
at any rate I don't think vk_meta necessarily needs a knob.. but something is inconsistent here
<Kayden>
It's now undefined to pass out of bounds values from one stage to the next
<Kayden>
and the piglit tests are going away
<Kayden>
I believe Sachiel is deleting our code to use generic varyings and we can just read the payload fields as a system value
<gfxstrand>
Cool
<gfxstrand>
Because it's a system value. :)
<gfxstrand>
hehe
<Sachiel>
I'll get back to that after I come back from vacations
<Kayden>
I don't think we've gotten there yet but yeah I think that's where we want to go, and we can probably make the varying go away with a bit of tidying.
<Kayden>
it is definitely weird that it has the dual behavior :/
<gfxstrand>
Broadly speaking, though, this is one of those areas where I'd weight consistency in NIR over drivers having to do a tiny translation, precisely to avoid these issues..
<gfxstrand>
Like the translation I'm doing in NAK costs me virtually nothing from a code maintenance PoV.
KitsuWhooa has joined #dri-devel
junaid has joined #dri-devel
xxmitsu has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
<jessica_24>
hey koike, abhinav__ and I have been working on adding a new Gitlab runner to the drm/msm CI (https://gitlab.freedesktop.org/drm/msm/-/merge_requests/76). However, we've been facing a yaml parse issue after upreving the mesa commit sha. It seems to be related to this commit
<jessica_24>
do you have any ideas on how to resolve this (hopefully without having to add a lot of extra dependencies to drm/ci/gitlab-ci.yml)?
<zmike>
the piglit tests are already deleted
<jessica_24>
this part of an ongoing discussion on #freedreno, so feel free to join there too
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
An0num0us has quit [Ping timeout: 480 seconds]
rz has quit [Remote host closed the connection]
rz has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonF has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
simon-perretta-img_ has quit [Read error: Connection reset by peer]
simon-perretta-img_ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
<alyssa>
gfxstrand: sure. I don't care whivh way we g
<alyssa>
go
<alyssa>
but right now varyings are somehow canonical and the sysvals are driver-translated
<alyssa>
seems less work to go that route to make things consisyent
<gfxstrand>
Except there's nothing "canonical" about gl_Layer. It's a built-in. It's magic.
<gfxstrand>
IDK what you even mean by "varyings are somehow canonical". What's a varying and what's a sysval is a giant tangle.
<gfxstrand>
Built-ins that end up as outputs somewhere typically have a VARYING_SLOT. That's about all the canonicalizaiton there is
<gfxstrand>
But inside a fragment shader, many of those (including gl_Layer) are very much not varyings, depending on hardware.
<gfxstrand>
Any more than gl_Position and gl_FragCoord are the same
<gfxstrand>
The fact that there are dozens of nir_intrinsic_load_foo which don't have a SYSTEM_VALUE_FOO enum and therefore don't get recorded in system_values_read is, admittedly, quite problematic.
<alyssa>
fair enough
<alyssa>
I don't really care how the tangle is resolved. I just have a nagging feeling Ill end up being the one detangling :v
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
eukara has quit []
<gfxstrand>
lol
libv has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
eukara has joined #dri-devel
<dcbaker>
zmike: I'm giving up. I've tried to bisect the zink-lvp job. I've come up with two commits that seem to cause a massive number of regressions, I've reverted them both. I'm still seeing huge numbers of fails on the job. Would you be able to help? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49306532
<zmike>
sure
<zmike>
I'll look first thing tomorrow
<dcbaker>
thanks
<zmike>
whoa that is huge numbers
libv has joined #dri-devel
<zmike>
dcbaker: do you have any completed pipelines for this?
<zmike>
and/or have you looked at any of the test logs to see if there's anything useful
JohnnyonFlame has joined #dri-devel
<dcbaker>
I looked at the logs when I startedand I think it was an assert of some kind, of course the rebase lost all of the pipelines :(
<zmike>
and obviously it would be too easy if I could repro any of this locally...