<airlied>
jenatali: yeah maybe once I kill the bugs I know about :-)
<airlied>
jenatali: did we talk about some recent regression on const inputs?
<jenatali>
airlied: Don't think so. What's up?
<airlied>
clGetKernelArgInfo tests are failing because the const is getting lost somehwere
<airlied>
CL_KERNEL_ARG_TYPE_QUALIFIER
<jenatali>
Ugh. I haven't tried a full conformance pass on a new Clang/LLVM
<airlied>
jenatali: I'm mostly concentrating on the headers fixes for cl3 in clang first, but once I get those done I'll go into tracking down the damage
<jenatali>
airlied: much appreciated. I don't have a ton of time to put into CL at the moment but if you need help, let me know
<airlied>
anyone remember offhand what the magic to make gputest run is?
<airlied>
oh one of the shader ones
gpoo has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
anujp has joined #dri-devel
<airlied>
nope can't remember, if anyone does let me know :)
<airlied>
oh maybe it was just slow seems to run now
sdutt has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
sdutt has quit [Remote host closed the connection]
gpoo has quit [Ping timeout: 480 seconds]
reductum has quit [Quit: WeeChat 2.8]
vivijim has quit [Remote host closed the connection]
reductum has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
dv_ has quit [Quit: WeeChat 2.8]
mattrope has quit [Read error: Connection reset by peer]
anujp has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
tzimmermann has joined #dri-devel
heat has quit [Ping timeout: 481 seconds]
itoral has joined #dri-devel
xcube has quit [Ping timeout: 480 seconds]
Hi-Angel has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
anujp has joined #dri-devel
frieder has joined #dri-devel
Hi-Angel has quit [Remote host closed the connection]
Hi-Angel has joined #dri-devel
phomes has joined #dri-devel
nchery has quit [Remote host closed the connection]
anujp has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
anujp has joined #dri-devel
pendingchaos has quit []
pendingchaos has joined #dri-devel
bcarvalho has quit [Quit: Leaving]
mlankhorst has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Read error: No route to host]
Ahuj has joined #dri-devel
rasterman has joined #dri-devel
silver has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
camus has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
camus has joined #dri-devel
pcercuei has joined #dri-devel
dv_ has joined #dri-devel
JTL has joined #dri-devel
anujp has joined #dri-devel
anujp has quit [Ping timeout: 482 seconds]
pnowack has joined #dri-devel
pnowack has quit []
pnowack has joined #dri-devel
tursulin has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
<airlied>
I kinda knew about stats query being broken, and asked for some CTS tests
<kusma>
OK, so pretty close, mod multidraws ;)
<kusma>
Nice nice :)
illwieckz has joined #dri-devel
<airlied>
kusma: yeah the multi draw mr i put up is necessary just to avoid cts dying
gouchi has joined #dri-devel
pendingchaos has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
imirkin has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
vivijim has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
Company has joined #dri-devel
<pq>
If I change HDR_OUTPUT_METADATA connector property value from non-zero blob id to zero, will it send an infoframe to the sink telling "legacy gamma, SDR"?
<pq>
Or do I need to create a blob that sets eotf to "legacy gamma, SDR" explicitly?
nirmoy has joined #dri-devel
<pq>
uh, I'm so full of questions about this property I'll have to email whoever introduced it.
<glennk>
pq, just quickly perusing the kernel code it looks like the latter
<pq>
glennk, that's... ugh.
<vsyrjala>
if you set the blob to zero we shouldn't transmit the infoframe at all. is there an actual difference between not sending it vs. sending one w/ sdr gamma?
<pq>
so if the property exists, it must always be programmed with a real blob, or the monitor might be in arbitrary state
<vsyrjala>
i would assume no infoframe == no hdr stuff enabled
<pq>
vsyrjala, err.. I dunno? I assumed the sink would keep the state it was last told.
<vsyrjala>
iirc usually things should reset back to defaults if you stop transmitting some infoframe
<pq>
aha
<vsyrjala>
assuming it's one of those infoframes that are supposed to be transmitted every frame
<pq>
ok, reading very carefully: "the Source shall send the Dynamic Range and Mastering InfoFrame once per Video Field while it is sending data associated with the dynamic range of the video stream."
<pq>
so, sounds like it is sent every frame indeed
<pq>
What if userspace frees the blob while it is set on the KMS property? Nothing changes?
<vsyrjala>
kernel has a copy
camus1 has joined #dri-devel
<vsyrjala>
ie. nothing changes as long as the prop value remains set
<pq>
ok, thanks
<vsyrjala>
hmm. the spec doesn't seem to explicitly state what happens when you stop sending the infoframe :(
silver has quit []
* vsyrjala
wouldn't be surprised if some sinks get it wrong
camus has quit [Ping timeout: 480 seconds]
<pq>
*snif*
<vsyrjala>
apparently there were already some sinks that fail to do the 3d vs. 2d switch when you stop sending the hdmi infoframe
<vsyrjala>
so i changed the kernel to always send it
<vsyrjala>
the new spec recommendation was to transmit it at least a few times after the switch iirc
<pq>
"a few times"?
<glennk>
more than thrice, fewer than a gross
<pq>
so, as a userspace dev, should I assume that just setting the KMS property no zero will reset the sink to SDR? And if it requires sending infoframes, the kernel will do that for me.
<pq>
*to zero
iive has joined #dri-devel
<pq>
what I'm slightly more worried about is that no-one will reset that KMS property to zero/SDR after Weston quits, leading to blinding fbcon, garbage, or other on screen. :-P
gouchi has quit [Remote host closed the connection]
<vsyrjala>
that seems like a reasonable assumption to me. otherwise userspace that doesn't know how to do anything except zero it probably wouldn't work
Lucretia has quit []
* vsyrjala
crosses fingers that buggy sinks aren't going to be a thing
<vsyrjala>
though i alreayd know how that's going to go
<pq>
urr...
Lucretia has joined #dri-devel
<pq>
why are both struct hdr_output_metadata::metadata_type and hdr_output_metadata::hdmi_metadata_type1.metadata_type defined as "Static_Metadata_Descriptor_ID"?
<pq>
also these public UAPI struct names are not namespaced
<pq>
there is no hdmi_metadata_type1.metadata_type equivalent in CTA-861-G
gouchi has joined #dri-devel
<vsyrjala>
maybe the higher level one was just there for the software to avoid having to dig into the union to figure out what said union actually contains
<vsyrjala>
can't remember anymore
<pq>
sure, but why would the union contain the same field?
<pq>
not the same field, but a copy
<vsyrjala>
just because it's in the on-wire format i think
<pq>
wouldn't that have problems with CPU endianess?
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
<vsyrjala>
not sure what you mean. the code knows how to pack/unpack the stuff correctly
<pq>
the struct uses __u16 types. Doesn't CPU endianess change the memory layout? So you can't just stream that struct out as-is.
<pq>
it also has two __u8, so doing a 16-bit byteswap over the whole struct wouldn't work either
<pq>
..to get into the "HDMI byte order"
itoral_ has quit [Remote host closed the connection]
<pq>
but if you manually pack/unpack each field separately, then why does the struct layout need to match the spec and duplicate that type field?
itoral_ has joined #dri-devel
<vsyrjala>
i suppose it doesn't. but i guess we just wanted to keep it matching the spec
<pq>
as a userspace dev needing to set the same thing in two different places confuses me :-)
gouchi has quit [Remote host closed the connection]
hanetzer1 has joined #dri-devel
hanetzer has quit [Ping timeout: 480 seconds]
hanetzer1 is now known as hanetzer
gpoo has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
<danvet>
pq, we could also patch this up in the kernel
<danvet>
and make one field just always match the other one when decoding
<pq>
danvet, that would not remove the fields from the UAPI structs which are what confused me.
<pq>
might want to ensure the fields agree though
<danvet>
pq, yeah or that
xexaxo has quit [Remote host closed the connection]
<danvet>
and definitely make sure there's some solid kerneldoc for this
<danvet>
maybe emersion is bored?
xexaxo has joined #dri-devel
agd5f_ has quit [Remote host closed the connection]
agd5f has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
jcline has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
silver has joined #dri-devel
heat has joined #dri-devel
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
Hi-Angel has quit [Remote host closed the connection]
jernej_ has joined #dri-devel
jernej has quit [Remote host closed the connection]
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
Hi-Angel has joined #dri-devel
Ahuj has joined #dri-devel
xcube has joined #dri-devel
mattrope has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
heat has quit [Remote host closed the connection]
NiksDev has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tango_ has quit [Ping timeout: 480 seconds]
NiksDev has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
macromorgan has joined #dri-devel
ngcortes has joined #dri-devel
gouchi has joined #dri-devel
sdutt has joined #dri-devel
anujp has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
NiksDev has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
alyssa has left #dri-devel [#dri-devel]
nchery has joined #dri-devel
sravn_ has quit []
sravn has joined #dri-devel
frieder has quit [Remote host closed the connection]
pochu has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
valentind has quit [Read error: No route to host]
<dcbaker>
venemo: awesome! I'm going to start the branching process now
valentind has joined #dri-devel
<dcbaker>
PSA: I just pushed the 21.3 updates to the main branch, marge might get cranky
<dcbaker>
err, 21.2->21.3 updates
quantum5 has quit [Remote host closed the connection]
quantum5 has joined #dri-devel
FluffyFoxeh has quit [Quit: Close the World, Open the nExt]
FluffyFoxeh has joined #dri-devel
NiksDev has joined #dri-devel
<jekstrand>
Is anongit working for other people?
<kisak>
cgit.fd.o is timing out here
<jekstrand>
I pinged on #freedesktop
<jekstrand>
daniels: ^^
illwieckz has quit [Ping timeout: 480 seconds]
<daniels>
unfortunately I’m out on a long walk, so it can have a couple of hours on the naughty step to think about what it’s done and then I’ll give it a comprehensive speaking-to when I’m back home
<jekstrand>
We really need a systemd job that kicks both those services every few hours.
<jekstrand>
But then someone'll complain that the kicking service is down. ¯\_(ツ)_/¯
<Sachiel>
it's kicking services all the way down
<bl4ckb0ne>
you need a kicking service kicker that kicks the kicking service every other few hours
<bl4ckb0ne>
then make the first kicking server kick the kicking service kicker after kicking the service
<dcbaker>
It's pretty low to kick a service while it's down
<bl4ckb0ne>
and you'll reach full kicking redudancy
illwieckz has joined #dri-devel
<daniels>
jekstrand: it’s not systemd - the NFS implementation in the kernel dives and sends everything into infinite I/O wait
<jekstrand>
daniels: Well, that's just awesome
<daniels>
but yeah, a check to see if the loadavg is above, say, 700, would do the trick
<daniels>
jekstrand: innit
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<rsalvaterra>
Uhh… Just noticed now, but you guys are surely aware already… [ 0.612747] nouveau 0000:03:00.0: DRM: failed to initialise sync subsystem, -28
<rsalvaterra>
Broken NVAC on Linux 5.14-rc1
<jekstrand>
jljusten: I'm going to let the NIR image indices MR (!11849) bake at least over the week-end in case cwabbott, pendingchaos, alyssa, anholt, or any of the other usual interested parties want to have opinions.
<jekstrand>
jljusten: I kind-of wonder if we'll eventually want a nir_lower_image pass similar to nir_lower_tex. It seems like the divide-by-6 thing might be something other people want too.
<jekstrand>
And I can imagine there might be interest in other common lowering, maybe.
<jljusten>
jekstrand: ok, but maybe you could take a quick look at what !9466 adds on top of those patches? it does seem somewhat simpler now.
<jekstrand>
sure
anujp has quit [Ping timeout: 480 seconds]
<jekstrand>
jljusten: Left you a few nits. Otherwise, I think it looks good
<jekstrand>
jljusten: Looks like AMD needs exactly the same workaround
<jekstrand>
jljusten: And turnip
<jekstrand>
jljusten: I'm thinking we should make this a generic pass.
<jekstrand>
And maybe r600? It's hard to tell
<jekstrand>
jljusten: The idea behind the generic pass would be a new nir_lower_image() pass similar in shape to `nir_lower_tex()` with a `nir_lower_image_options` struct etc. It would have one option: lower_cube_size. Then we could use it on AMD, turnip, and Intel.
<jekstrand>
If we called it before our lowering pass, we could even drop the cube handling from the current lower_image_size helper which does the uniform thing.
mbrost has joined #dri-devel
<jljusten>
jekstrand: so, we'd be back to having 2 passes? :)
jernej_ is now known as jernej
Ahuj has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
<jekstrand>
jljusten: Yup. But one of them would be shared across 4 drivers so that's a good thing, I think. :)
<jekstrand>
jljusten: We could possibly even move some of our format lowering code into the generic pass at some point in the future to make it easier for mobile people to implement image support.
<jekstrand>
But that's in future land
<jekstrand>
jljusten: Sorry for the churn. You just hit one of those "there are N ways to do this" things.
<jekstrand>
jljusten: I could write it up if you want or do it as a refactor later but I also want to give you the opportunity if you're willing.
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
<jljusten>
jekstrand: I'll give it try
Ahuj has joined #dri-devel
anujp has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<pscoe2>
Has anyone seen this error while trying to mesonbuild mesa?
<pscoe2>
..\meson.build:21:0: ERROR: Value "c11" (of type "string") for combo option "C language standard to use" is not one of the choices. Possible choices are (as string): "none", "c89", "c99", "gnu89", "gnu90", "gnu9x", "gnu99".
<pscoe2>
This is windows with llvm built as per the ci instructions
anujp has quit [Remote host closed the connection]
<jekstrand>
pscoe2: How old is your MSVC?
<jekstrand>
pscoe2: Or are you building with clang?
<jekstrand>
Or maybe your meson is ancient?
<pscoe2>
16.7.4 (VS 2019)
<pscoe2>
just installed meson from pip3
<pscoe2>
that is why I suspected that i was missing something in my llvm build
<jekstrand>
I'm excited to hear the results. I'd love it if we could rely on c11 accross the board
sarnold has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<airlied>
jekstrand: it builds in CI with c11 I assume
<jekstrand>
airlied: Probably, I guess.
<pscoe2>
I remember there were some build errors with 16.8 when it was first released. So i stalled my VS updates to ensure I dont run into those again
pscoe2 has quit [Remote host closed the connection]
gpoo has quit [Ping timeout: 480 seconds]
gpoo has joined #dri-devel
rsalvaterra_ has joined #dri-devel
pscoe2 has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
<dcbaker>
I think Meson 0.59 will have actual MSVC C11 support wired up (that should be out next week)