ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<jenatali>
Ah well, found a workaround. Let's see how ugly it is...
<anholt>
imirkin, karolherbst_: any tricks for stable deqp runs on older nouveau? tried deqp on NVA8 and got "failed to idle channel 14 " leading to things being totally wedged.
<anholt>
(was halfway through a gles2/3 run when that happened)
ngcortes has quit [Ping timeout: 480 seconds]
<karolherbst_>
anholt: don't run in parallel
<karolherbst_>
although it should work (tm)
<karolherbst_>
failed to idle channel just means that the hw context crashed and nouveau starts to tear it down
<jekstrand>
That's encouraging....
<karolherbst_>
I know
<karolherbst_>
channel recovery isn't the most stable thing
ybogdano has joined #dri-devel
<anholt>
I'm guessing that making sure I have fewer GL contexts happening than some HW limit will help.
tursulin has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<anholt>
karolherbst_: well, that fail leads to a timeout in "nvkm_fifo_chan_child_fini+0x76/0xf0" and from there nothing recovers until I power off (even soft reboot stalls seemingly indefinitely in drm idling)
columbarius has joined #dri-devel
<karolherbst_>
anholt: yeah... sometimes that happens :/
co1umbarius has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
<imirkin>
anholt: also there is a range of kernels which has some unpleasant bugs ... i think 5.15 should be good though
<imirkin>
daniels: i fully believe you. but i wonder if the situation was either misrepresented to you, or you read into it too much. i'm not aware of any cohesive policy around this. mesa's a fairly big project, diff people have diff opinions. i'm not aware of there ever being a strong policy like that -- a preference, maybe, when reasonable. no need to be supporting libc.so.5 :)
<imirkin>
daniels: i think in almost any project, the preference is to avoid weird version deps. but there's also a reality of having to deal with the versions being shipped, so you sometimes have to either deal with the version stuff, or add ifdefs/whatever to make people's lives easier, with a "TODO remove this when xyz" perhaps
boistordu_ex has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
gpuman_ has quit [Remote host closed the connection]
<imirkin>
dcbaker: hey, i've somehow gotten meson into a weird state where it has cached an old version of libdrm and isn't picking up a new one. this is with a cross-file fwiw. lmk if you'd be interested in investigating further, or if i should just blow away the cache
<imirkin>
dcbaker: "Dependency libdrm found: NO found 2.4.100 but need: '>=2.4.109' (cached)"
<dcbaker>
I keep meaning to add a --clear-cache. I think you can fix that with `meson setup --reconfigure $builddir`, but for sure `meson setup --wipe $builddir` will fix that
<imirkin>
dcbaker: yeah, i'm sure it will
<imirkin>
i was just wondering if you wanted to investigate how it got into a bad state
<imirkin>
or if i should just wipe it and move on
<dcbaker>
what version of meson do you have?
<imirkin>
0.59.4
<dcbaker>
hmmm, I know there were some changes around when we cache dependencies in either 0.59 or 0.60...
<imirkin>
fwiw i did have libdrm 2.4.100 before. then i reverted the changes which required the newer version. and now i've rebased the reverts out, so back to needing 2.4.109 (after updating libdrm)
<imirkin>
perhaps the meson.build file went back in time as a result? (in terms of timestamps)
<dcbaker>
maybe... There's a number of things about the way we cache dependencies that has corners
<imirkin>
ok. i guess i'll just do a --reconfigure and move on then
<imirkin>
hrmph. --reconfigure doesn't do it...
<imirkin>
let's see if i can avoid wiping the whole thing, building is slow =/
<imirkin>
hopefully just editing build/meson-info/intro-dependencies.json works.
<imirkin>
hrmph, no =/
<imirkin>
looks like it's pickled in
<imirkin>
dcbaker: oh, heh, looks like there's a meson configure --clearcache
<imirkin>
either you added it and forgot, or someone snuck it in :)
camus1 has joined #dri-devel
<dcbaker>
nice
<dcbaker>
one more thing I don't have to write
camus has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
tarceri has quit []
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
<daniels>
imirkin: yeah that was awesomely creative
<daniels>
(in fact that's probably what made me think of it?)
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Walter has joined #dri-devel
Walter has left #dri-devel [#dri-devel]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
danvet has joined #dri-devel
guru_ has quit []
oneforall2 has joined #dri-devel
fxkamd has quit []
tursulin has joined #dri-devel
egbert has quit [Ping timeout: 480 seconds]
egbert has joined #dri-devel
pnowack has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
shashank_sharma has quit [Ping timeout: 480 seconds]
adjtm has quit [Quit: Leaving]
jkrzyszt has joined #dri-devel
thellstrom has joined #dri-devel
kevintang has joined #dri-devel
kevintang has quit [Read error: Connection reset by peer]
kevintang has joined #dri-devel
rasterman has joined #dri-devel
<kevintang>
mripard: sorry for disturbing you again, please help to review my patch v7 when you are free, thks.
Company has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
<mripard>
kevintang: done
gawin has joined #dri-devel
shashanks has joined #dri-devel
aravind has joined #dri-devel
camus has joined #dri-devel
<pq>
jljusten, thanks for "dependency"!
camus1 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
March-123 has joined #dri-devel
mszyprow_ has quit [Read error: Connection reset by peer]
mclasen has joined #dri-devel
<kevintang>
mripard: thks~
Danct12 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
frieder has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.3]
adjtm has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
nsneck has joined #dri-devel
lemonzest has joined #dri-devel
nchery has joined #dri-devel
vivijim has joined #dri-devel
nchery is now known as Guest7457
nchery has joined #dri-devel
Guest7457 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
camus has quit []
mattrope has joined #dri-devel
sdutt has joined #dri-devel
fxkamd has joined #dri-devel
Peste_Bubonica has joined #dri-devel
jewins has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
dllud_ has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
dllud has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
Duke`` has joined #dri-devel
March-123 has quit [Ping timeout: 480 seconds]
<imirkin>
dcbaker: yeah, something definitely weird going on with the dependency caching in meson. in another tree where i never had the reverts, i ran into the same problem
<imirkin>
gah! llvmspirvlib. ok, that one might be my bad :)
<imirkin>
grrrr. no llvm 13 ebuild for that. <--- mattst88
<dcbaker>
imirkin: i *think* 0.60 is the version with the cache changes. I know we recently made it vaccine strategy more conservative
<imirkin>
dcbaker: ok
Peste_Bubonica has quit [Quit: Leaving]
<jekstrand>
Does this mean we're going to delete classic today?
* jekstrand
crosses his fingers
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
ella-0 has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
<imirkin>
daniels: let's hope that does it! that was a weird error, i think it's the first time i had personally encountered it
tzimmermann has quit [Quit: Leaving]
jhli has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.3]
<dcbaker>
jekstrand: I'm down to one failing test, and fixing that is my priority for today
<jekstrand>
\o/
ybogdano has joined #dri-devel
aravind has joined #dri-devel
<mattst88>
imirkin: llvmspirvlib. interesting, that's presumably something that is part of upstream llvm?
<karolherbst_>
mattst88: not really
aravind has quit []
karolherbst_ is now known as karolherbst
<karolherbst>
it's more or less a khronos project atm
<imirkin>
mattst88: it's a separate package
<mattst88>
ah, okay
<imirkin>
i made an ebuild update
<imirkin>
but did it in ... a non-upstream-acceptable way
<imirkin>
they now want to know where the spirv-headers are at, and i don't know how to find that out. but they're in /usr for me, so just stuck that in ;)
<karolherbst>
I think Intel also helped out a lot or something.. anyway.. it was a full llvm fork in the past and I helped convincing them to make it a lib instead
<imirkin>
dcbaker: but to repro locally, just stick an assert in _mesa_half_to_float
<imirkin>
dcbaker: and/or otherwise cause it to get the cpu caps even though it doesn't need to for your cpu type
<dcbaker>
I'm just trying to figure out why this changed... the only call to util_cpu_detect that was removed was in i965… I sure hope that wasn't the reason it was succeeding...
<daniels>
imirkin: that’s one for tanty/jasuarez - bcm is all theirs
<imirkin>
daniels: seems like it's not even getting that far though
<imirkin>
errors getting the container, or nothing in the job...
<daniels>
right, but the thing which does that is on-prem too
<imirkin>
oh.
<daniels>
network problems Chez Igalia I’d guess
<imirkin>
shows you what i know about how CI works.
<imirkin>
(very very little)
<imirkin>
no output = bad is about as far as i go i guess :)
<imirkin>
daniels: how does a runner find out that there's a job to run? does it poll the Central Authority? or is it an active dispatch where the central thing knows how to reach each runner?
<jekstrand>
dcbaker: That's an awesome bug. "Detected zero CPUs"
<imirkin>
dcbaker: perhaps it was in an i965 function that was getting called by the loader always?
<dcbaker>
possibly?
<imirkin>
(i haven't looked at where it was, just making complete guesses)
<dcbaker>
I'm thinking I'll just throw util_detect_cpu into the test function and be done with it
<dcbaker>
it doesn't seem to affect anything else, so it may well be the tests just probing an odd path
<imirkin>
dcbaker: maybe into the test setup logic? seems like all tests should have it.
March-123 has quit [Ping timeout: 480 seconds]
<dcbaker>
well, I would really prefer to use something like a global constructor so that it's just always detected…
<imirkin>
right
<imirkin>
i think the test framework has some capability to run stuff "globally" like that
<dcbaker>
git log shows quite a few "oh, we need to call util_detect_cpu here too"
<jekstrand>
Yeah, util_detect_cpu gets called a bunch of places.
March-123 has joined #dri-devel
<dcbaker>
anyone object to my patch to add util_detect_cpu?
<dcbaker>
I think otherwise it's actually ready for marge now
mlankhorst has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
March-123 has quit [Remote host closed the connection]
March-123 has joined #dri-devel
gawin has joined #dri-devel
danvet has joined #dri-devel
<dcbaker>
nope, no objections? off to marge then
Duke`` has quit [Ping timeout: 480 seconds]
<HdkR>
dcbaker: What's all this about CPUs then?
<HdkR>
I can't seem to find an MR
<dcbaker>
HdkR: one test on armv7 (but not aarch64) is failing after deleting mesa_classic because util_detect_cpu isn't getting called
<HdkR>
ah, in the classic mesa mr
<dcbaker>
some side effect of loading i965 we think
<HdkR>
Looks reasonable to me, a random bystander
<HdkR>
:)
<dcbaker>
:)
Walt has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
<Walt>
How do I create a port of Mesa for a non-UNIX Operating system, Im creating an Operating System which doesnt support any POSIX calls.
<Walt>
The problem is I havent created a cross compiler for it
<Walt>
So I just use gcc
<Walt>
so compiling and checking for errors will not work
<HdkR>
You need a sane compiler or cross-compiler setup before thinking about bringing up mesa
<HdkR>
also likely need some libc support on your end first
<HdkR>
either glibc, or musl?
<Walt>
does Mesa mainly interface with libc?
<HdkR>
It does very few raw syscalls, most everything comes from libraries
<HdkR>
so libc and libdrm
<Walt>
So, port glibc before Mesa, got it
Walt has quit [Quit: Page closed]
<jenatali>
Are you just looking to have a software GL implementation? Or did you actually want drivers? Are you trying to do offscreen rendering, or displaying through a window system?
<anarsoul>
jenatali: they just left
<jenatali>
Oh
<jenatali>
That's what I get for turning off join/leave notifications :P
<anarsoul>
I really wonder what they were trying to do with mesa without libc...
<imirkin>
jenatali: know offhand if clip distances were required for D3D 11_1?
<imirkin>
(i sorta assume they were since it was a d3d10 feature, but who knows)
<jenatali>
imirkin: Offhand, no, but I can find out pretty easily
<imirkin>
well, don't want to make you do a bunch of research
<imirkin>
but if you're volunteering, i'll take it :)
<jenatali>
imirkin: Looks like required in 10.0+ at least
<imirkin>
ok cool
<imirkin>
and would that include cull as well?
<jenatali>
Pretty sure
<jenatali>
I'm trying to find a definitive one-liner
<jenatali>
Yeah they weren't added in SM5, so they're in D3D10
<imirkin>
yeah, it definitely existed there
<imirkin>
my question is about it being required
<imirkin>
vs "here's a neat little optional feature"
<jenatali>
There's no caps to check. If it's in SM4 it's required I'm pretty sure
<imirkin>
gotcha
<imirkin>
thanks!
<imirkin>
(the relevance is to adreno, which claims DX11 11_1 feature level)
<imirkin>
jenatali: yeah, i knew it was d3d10 when it came in. wasn't sure if there was a way to indicate that they're available or not
<jenatali>
Nope, it'd be tied to shader model pretty sure. All hardware has to support 4.0 to be able to support D3D10
<imirkin>
yeah, but like SV_ClipDistance is an array
<imirkin>
The combined clip and cull distance values are at most D3D#_CLIP_OR_CULL_DISTANCE_COUNT components in at most D3D#_CLIP_OR_CULL_DISTANCE_ELEMENT_COUNT
<imirkin>
for all i know you can set that to 0 somehow
<jenatali>
No, those caps are defined in a header, not queried at runtime
<imirkin>
ah ok
rpigott has quit [Remote host closed the connection]
robertfoss has quit [Ping timeout: 480 seconds]
rpigott has joined #dri-devel
fxkamd has quit []
<Lynne>
jekstrand: sorry, just found your email, responded
<Lynne>
from the sound of things, having to carry around an offset is just something that we'll have to live with
gouchi has quit [Remote host closed the connection]
March-123 has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]