\Kalascus has quit [Remote host closed the connection]
luzipher_ has joined #dri-devel
OPCMatrixBot has joined #dri-devel
OPCMatrixBot has quit [Remote host closed the connection]
luzipher__ has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
ghostop14[m|gr] has joined #dri-devel
ghostop14[m|gr] has quit [Remote host closed the connection]
GloriousEggroll has quit [Quit: Death is life's way of telling you you've been fired.]
Kayden has joined #dri-devel
xp4ns3 has joined #dri-devel
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
Lightkey has quit [Ping timeout: 480 seconds]
boistordu has joined #dri-devel
luzipher__ has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
luzipher_ has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
lemonzest has quit [Quit: Quitting]
Noxturnix16 has joined #dri-devel
Noxturnix16 has quit [Remote host closed the connection]
ppascher has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
xp4ns3 has quit []
aravind has joined #dri-devel
ppascher has joined #dri-devel
<robclark>
daniels, anholt: so I think all the MR's I've been cc'd on that were marged today went thru flake-free (just wanted to say something, because normally no one says anything about CI when it is working well ;-))
khfeng has joined #dri-devel
Duke`` has joined #dri-devel
<alyssa>
woohoo! 🎉
<alyssa>
robclark: We need "days without a CI disaster" sign up
<alyssa>
😋
mbrost has joined #dri-devel
<robclark>
alyssa: tbf, at least the recent driver flakes were actually a legit issue that CI caught.. it was just the sort of issue that caused fails a fraction of the time (CI is, tbf, better at catching things that happen 100% of time).. and not pointing fingers, I've introduced that sort of problem myself, I think we all have or at least will sooner or later.. but CI found it and things were fixed within a couple days, rather than no
<robclark>
one noticing until months later.. so it gets frustrating occasionally (and that is the only time people talk about it), but turns out it works
karolherbst_ has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
tango_ has quit [Ping timeout: 480 seconds]
shankaru1 has joined #dri-devel
Reception123 has joined #dri-devel
Reception123 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-11 04:35:13)]
mbrost has quit [Remote host closed the connection]
blue__penquin has joined #dri-devel
luzipher_ has joined #dri-devel
blue__penquin has quit []
luzipher__ has quit [Ping timeout: 480 seconds]
agx_ has quit [Ping timeout: 480 seconds]
agx_ has joined #dri-devel
tango_ has joined #dri-devel
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
rlmarlow[m|gr] has joined #dri-devel
rlmarlow[m|gr] has quit [Remote host closed the connection]
camus has quit []
camus has joined #dri-devel
<daniels>
robclark: \o/ yeah, thanks for the flush fix!
camus has quit []
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
sdutt has quit [Remote host closed the connection]
ppascher has quit [Quit: Gateway shutdown]
camus has quit []
mlankhorst has joined #dri-devel
sofar has joined #dri-devel
sofar has quit [autokilled: spambot. Dont mail support@oftc.net with questions (2021-06-11 05:48:02)]
ppascher has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
NiksDev has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
pnowack has joined #dri-devel
tzimmermann has joined #dri-devel
RobertC has joined #dri-devel
mvlad has quit [Quit: Coyote finally caught me]
mvlad has joined #dri-devel
andrey-konovalov has joined #dri-devel
tango_ has quit [Ping timeout: 480 seconds]
zgrep1 has joined #dri-devel
Anorelsan has joined #dri-devel
zgrep1 has quit [Remote host closed the connection]
tango_ has joined #dri-devel
pekkari has joined #dri-devel
<MrCooper>
would be nice if there was an easy way to search for a certain failure in past job logs, to better judge if something is a pre-existing flake or might have been introduced by the MR
<MrCooper>
danvet: not sure how denying rendering for DRM master is going to work without breaking user space :)
<danvet>
MrCooper, neither do I know that, but könig brought it up somewhere
<MrCooper>
maybe boost from page flip could be almost as good as a high priority context
<MrCooper>
if it can preempt as well
andrey-konovalov has quit [Ping timeout: 480 seconds]
<MrCooper>
Prf_Jakob: some people argue that the sRGB concept only really makes sense for 8 bpc
<pq>
Prf_Jakob, sRGB space pixels are totally necessary with 8 bits, and I'd guess also necessary with 10 bits if you want any kind of HDR'ish stuff. But then with HDR it's not sRGB but some other EOTF most likely. If your display is 10 bits SDR, then you do need sRGB or another encoding to make use of it.
<pq>
so not surprised that Unreal insists on sRGB
<pq>
jekstrand, what !4037?
<pq>
MrCooper, sRGB or another EOTF is definintely necessary with 8 bpc, but with 10 bpc it depends on what you intend with it. AFAIU, 10 bpc linear is roughly equivalent to 8 bpc sRGB in color precision.
luzipher__ has joined #dri-devel
<pq>
So if you expect 8 bpc sRGB precision, 10 bpc linear may be enough. If you expect anything more, like actually driving a 10 bit display, then no.
<pq>
My personal feeling is that I probably wouldn't use anything less than half-float for linear-light pixels, and that might allow a bit of HDR too. But I also haven't actually tested yet, so this is purely a feeling without experience.
nergzd723 has left #dri-devel [#dri-devel]
<pq>
8 bpc linear is something people would complain about - like if you used rgb565 when you expect rgba8888
<pq>
not the same effect but the similar complaints
thellstrom has quit [Remote host closed the connection]
<jekstrand>
bnieuwenhuizen: An ACK from you would be nice. At least to say you've looked at it and think it won't break RADV.
<emersion>
jekstrand, i can't mark my comments as resolved, feel free to do so
<emersion>
sorry for the false alarms
<emersion>
the commits are well-split, thanks for that
tobiasjakobi has joined #dri-devel
<jekstrand>
emersion: No worries. I'm always happy to answer questions. :)
<jekstrand>
emersion: The whole errno thing in ioctl() drives me banannas. I hate writing kernel code that returns -EXXXX and then going into userspace and having to remember to look for errno == EXXX.
<emersion>
ahah yeah it's pretty confusing
<jekstrand>
We really should add a u_ioctl_ret() wrapper in src/util which returns -errno
<jekstrand>
There are a handful of ioctls which return actually useful stuff but not the vast majority.
Elijah_ has joined #dri-devel
Elijah_ has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-11 15:21:49)]
rgallaispou has quit [Read error: Connection reset by peer]
pekkari has quit [Remote host closed the connection]
pekkari has joined #dri-devel
<robclark>
alyssa: how is it that you manage to do email style code review on gitlab?
thellstrom has joined #dri-devel
<alyssa>
robclark: my mommy says I'm special
<emersion>
jekstrand, do they return useful negative integers?
<jekstrand>
emersion: Not according to the ioctl() man page
<emersion>
> Upon successful completion, ioctl() shall return a value other than -1
<emersion>
> Otherwise, it shall return -1 and set errno to indicate the error.
<jekstrand>
A few ioctl() requests use the return value as an output pa‐
<jekstrand>
rameter and return a nonnegative value on success.
<emersion>
ah, i guess i'm reading the POSIX man pages and not the Linux ones
sdutt has quit []
sdutt has joined #dri-devel
iive has joined #dri-devel
<jenatali>
jekstrand: Any chance you'd be willing to ack !10989?
<jekstrand>
jenatali: There's always a chance. :P
<jekstrand>
Why did MSFT have to go out and make their own qsort_r and make it different ?!?
<jekstrand>
*sigh*
<alyssa>
hey jenatali, why?!
<alyssa>
:-p
<jenatali>
Hey don't blame me
<jenatali>
I could say the same about Linux though :P
<alyssa>
jenatali: something something open standards
<jekstrand>
Hrm... Looks like qsort_s is actually in the C11 standard.
<alyssa>
Confession: In a decade of writing C code, I don't believe I have /ever/ called qsort.
<jenatali>
jekstrand: Hah!
blue__penquin has quit []
<jekstrand>
jenatali: BUt it uses the qsort_r semantics. Hah!
<jekstrand>
So either cppreference.com is wrong or It's just busted on MSVC
<jenatali>
Of course nobody can be consistent
pekkari has quit []
<jekstrand>
I left a comment
<jekstrand>
We need to be more careful with qsort_s if it's wonky on Windows.
<jenatali>
Yeah agreed. Good catch, thanks
<jekstrand>
yw
<jekstrand>
I'm glad I did so much googling
<jekstrand>
That' one's really thorny
<jekstrand>
jenatali: Does MSVC support C11? If so, do you know how they handle this oddity?
<jenatali>
jekstrand: it does support C11, but I don't know about that particular detail
<jenatali>
I'm out of town at the moment (just trying to help keep things moving if I can) so I can't really dig into it right now
<jenatali>
I'm sure Enrico can figure it out though
<jekstrand>
That's fair.
BlueShark has joined #dri-devel
BlueShark is now known as Guest1738
Guest1738 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-11 15:55:40)]
<jekstrand>
I wonder if we can make all the Android people build in C11 mode and get rid of my silly TLS hack.
GloriousEggroll has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<jenatali>
jekstrand: a quick search shows qsort_s is optional in C11
<jekstrand>
How can something be optional in a new C version? *sigh*
<jenatali>
"Annex K" is apparently the answer to that?
<jenatali>
At least according to a MinGW question I saw
<Lyude>
emersion: ah yeah that'd be neat to see in mst, we do need to start using epochs in mst first though
<emersion>
yea exactly
<Lyude>
if you want to do that and have any questions about it feel free to let me know
<emersion>
i haven't yet fully understood how that would look like
<emersion>
because the DP-MST helpers just invoke a callback to probe the connector
<emersion>
so i don't think we can just blindly bump the epoch in the helpers
Danct12 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<eric_engestrom>
MrCooper: ah sorry, I've been working on another project than Mesa for too long now and built up the wrong muscle memory for git commands :/
<HdkR>
`git push upstream main --force`
<eric_engestrom>
haha yeah no, that's not something that'll ever enter my muscle memory I hope ^^'
<Lyude>
emersion: yeah, wouldn't be surprised if we might need a new connector probe callback that handles a bit less of the probing process
<emersion>
hm
danvet has joined #dri-devel
MikhailK-t has joined #dri-devel
MikhailK-t has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-11 16:32:09)]
khfeng has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
GloriousEggroll has quit [Remote host closed the connection]
GloriousEggroll has joined #dri-devel
neonking has joined #dri-devel
neonking has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
neonking has joined #dri-devel
macromorgan has joined #dri-devel
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
robert_mader has quit [Quit: Leaving.]
nsneck has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
kdehl has joined #dri-devel
kdehl has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-11 19:21:04)]
shankaru1 has quit []
<airlied>
daniels: anongit okay? linus had trouble connecting
<robclark>
iirc tomeu reported something similar.. I *think* the issue is because trying to tweak things thru sysfs before gpu is actually loaded
<daniels>
airlied: kicked it
<robclark>
probably `cat /dev/dri/card0 > /dev/null` before poking at sysfs will work
<daniels>
anholt, robclark: ok cool, I'll just leave it out for now and you can enable it when it's stable
<robclark>
daniels: the root issue is that we need to defer loading gpu in order for display to probe without having to put gpu fw in initrd.. try the workaround I suggested
<robclark>
well, that issue was partially a kgsl issue, but it prompted us to tighten up a few things (see CP_WHERE_AM_I patches) around that time
<robclark>
(and APRIV on targets that support that.. basically making less things that matter writable from cmdstream that isn't kernel controlled)
<anholt>
jekstrand: I'm guessing you meant CAN_ELIMINATE rather than has_side_effects which doesn't exist?
<anholt>
maybe CAN_REORDER?
aswar002 has joined #dri-devel
aswar002 has quit []
aswar002 has joined #dri-devel
aswar002 has quit []
aswar002 has joined #dri-devel
ella-0 has joined #dri-devel
ella-0 has quit [Remote host closed the connection]
ella-0 has joined #dri-devel
ella-0 has quit [Remote host closed the connection]
<jekstrand>
anholt: Right. You need to be extra careful with CAN_REORDER
gouchi has joined #dri-devel
<anholt>
deqp at least is happy with nir_intrinsic_can_reorder
<anholt>
all the discard tests that don't involve rolled loops look like they pass
<anholt>
so something works out so we get discard_ifs.
<anholt>
:( iris has flaky qbos apparently according to piglit.
<zmike>
yep
<dj-death>
jekstrand: roger, just left a question on that last commit
fc5dc9d4 has joined #dri-devel
fc5dc9d4 has quit [Remote host closed the connection]
BlackDex27 has joined #dri-devel
BlackDex27 has quit [Remote host closed the connection]
pnowack has quit [Quit: pnowack]
<anholt>
has anyone ever looked into why deqp's flush_finish is so slow? is it just a bad test?
Duke`` has quit [Ping timeout: 480 seconds]
ArmanGrigorian-t has joined #dri-devel
ArmanGrigorian-t has quit [Remote host closed the connection]
<zmike>
is that one of the ones where there's a sleep() before glFinish() ?
danvet has quit [Ping timeout: 481 seconds]
<Venemo>
what is a good way to find the "same" NIR instruction between a shader that has had nir_cf_list_clone_and_reinsert and nir_cf_reinsert?
<Venemo>
ie. if I look at an instruction in the clone, how do I figure out which is the corresponding instruction in the resinserted code?
<jekstrand>
There's no good way
<jekstrand>
I guess we could add a version of nir_cf_list_clone that builds up a hash table mapping from one to the other.
<jekstrand>
But no such thing exists
<jekstrand>
I guess, in theory, you could also walk both lists and count
<Venemo>
I had the idea to either depend on instruction order, or the pass flags
<jekstrand>
I'm not sure if pass flags are cloned
<Venemo>
they are not? :O
<Venemo>
that would be a big bummer
<jekstrand>
that's trivial to fix
<alyssa>
anholt: ISTR flush_finish did both stupid numbers of flushes _and_ stupid numbers of draws
<alyssa>
which to me sounds a bit like bad test since they could drop some 0's on both and nothing of value would be lost ...
<Venemo>
indeed, but then I'm afraid we might find out something that depended on them not being cloned
<jekstrand>
anholt: Care to revivew the CI patch on the crocus MR?
<jekstrand>
Or not. It's trivial. I'll review it.
<Venemo>
jekstrand: fortunately, I only need to match a handful of instructions between the clones, so the pass flags could solve that nicely
<jekstrand>
Venemo: Then I'd just double-check that pass_flags get cloned and fix it if they don't and then do that.
<Venemo>
they don't seem to be cloned currently
<Venemo>
at least, Ctrl+F "pass_" doesn't find anything in nir_clone.c
<jekstrand>
Should be a 1-line fix
<Venemo>
possibly yeah
pcercuei has quit [Quit: dodo]
<Venemo>
okay, different question: when I'm analyzing a shader and looking for some information about some instructions (or their SSA defs), what is the right way to store this information if pass_flags is too small?
<jekstrand>
airlied: I know it's saturday there, but ya wanna merge crocus? :)
<jekstrand>
Merging a whole new driver on a week-end. What could possibly go wrong?
<ccr>
\:D/
<jekstrand>
Venemo: Typically, a hash_table of pointers to some info struct.
<Venemo>
mhm
<Venemo>
what would be the key to of hash table? the ssa's index?
<jekstrand>
instruction pointer or ssa def pointer works
<Venemo>
do those pointers stay valid after cf extract and reinsert?
<Venemo>
hm, well I guess I may not actually need them to be
<Venemo>
I could analyze the thing before the extract
shankaru has joined #dri-devel
<jekstrand>
Yes, instruction and SSA def pointers stay valid until the instruction is deleted.
<jekstrand>
Of course, if you clone, you have to watch out for which one is the clone and which is the original.
neonking has quit [Remote host closed the connection]
tcunha has joined #dri-devel
tcunha has quit [Remote host closed the connection]