kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined #dri-devel
Company has quit [Quit: Leaving]
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
pH5 has joined #dri-devel
srslypascal has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
djbw has quit [Read error: Connection reset by peer]
srslypascal has joined #dri-devel
lemonzest has joined #dri-devel
dcz_ has joined #dri-devel
jfalempe has joined #dri-devel
fab has quit [Quit: fab]
sgruszka has joined #dri-devel
samuelig has joined #dri-devel
samuelig is now known as Guest2189
Guest2189 has quit []
samuelig_ has joined #dri-devel
samuelig_ has quit []
samuelig__ has joined #dri-devel
tursulin has joined #dri-devel
mwalle has joined #dri-devel
frieder has joined #dri-devel
pochu has joined #dri-devel
jlawryno_ has joined #dri-devel
tzimmermann has joined #dri-devel
jkrzyszt has joined #dri-devel
fab has joined #dri-devel
YuGiOhJCJ2 has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
rasterman has joined #dri-devel
clever has joined #dri-devel
MrCooper__ is now known as MrCooper
<MrCooper>
alyssa: 1000 open MRs is a totally arbitrary and meaningless number; case in point, I've seen a similar discussion multiple times on #gnome-shell, except it was about 100 open MRs :)
mvlad has joined #dri-devel
danvet has joined #dri-devel
arnd_ has quit []
arnd has joined #dri-devel
<jadahl>
MrCooper: and we started having bitweekly calls to get that number down, and now we have 50% more open. success?
MajorBiscuit has joined #dri-devel
<MrCooper>
my advice is to stop wasting time worrying about that :)
<HdkR>
I've had those discussions with <20 open MRs. Worrying about the number doesn't matter all that much in the end
<jadahl>
indeed
sarahwalker has joined #dri-devel
Lucretia has joined #dri-devel
<MrCooper>
jadahl: I do think those bi-weekly calls are useful though, helps move forward some MRs which might otherwise be stuck
swalker_ has joined #dri-devel
swalker_ is now known as Guest2195
<jadahl>
MrCooper: yepp
MajorBiscuit has quit []
jfalempe has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
samuelig_ has joined #dri-devel
samuelig_ is now known as samuelig
samuelig__ has quit []
sarahwalker has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
Haaninjo has joined #dri-devel
jfalempe has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #dri-devel
pcercuei has joined #dri-devel
ElementW has quit [Quit: -]
Haaninjo has quit [Quit: Ex-Chat]
sgruszka has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
apinheiro has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
FireBurn has joined #dri-devel
<daniels>
eric_engestrom: the kernel comes from us - it’s built as part of the container build
<eric_engestrom>
I'm not entirely clear on how/where we do this override though, I'll look into that this afternoon or tomorrow
phire has quit []
phire has joined #dri-devel
phire has quit []
jkrzyszt has joined #dri-devel
phire has joined #dri-devel
<daniels>
eric_engestrom: oh ... it would be good if they were part of the CI environment like everything else
<daniels>
both LAVA and the other bare-metals have kernels built as part of that environment
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
xroumegue has quit [Ping timeout: 480 seconds]
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #dri-devel
phire has quit []
apinheiro has quit [Quit: Leaving]
xroumegue has joined #dri-devel
yuq825 has quit []
arisu has joined #dri-devel
Andy[m]1 has joined #dri-devel
Grillo[m] has joined #dri-devel
aura[m] has joined #dri-devel
bluepqnuin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
dcbaker has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest2208 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
EricCurtin[m] has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
eballetbo has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gallo[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest2224 has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
i509VCB has joined #dri-devel
ids1024[m] has joined #dri-devel
jasuarez has joined #dri-devel
Jean[m]1 has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
MayeulC has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
Nirvin[m] has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
swick[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest2238
yuq825 has joined #dri-devel
<gawin>
on topic 1000 MRs: some of them are hanging, because reporters aren't testing patches.
<gawin>
DavidHeidelberg[m]: would it be possible to make CI builds downloadable and usable by end user? I remember it's possible for end apps (binary) using stuff like conan.
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
Dr_Who has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
phire has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
phire has quit []
phire has joined #dri-devel
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #dri-devel
itoral has quit []
phire has quit []
phire has joined #dri-devel
apinheiro has joined #dri-devel
phire has quit []
phire has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
glennk has joined #dri-devel
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #dri-devel
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #dri-devel
aravind has joined #dri-devel
phire has quit [Quit: No Ping reply in 180 seconds.]
phire has joined #dri-devel
<DavidHeidelberg[m]>
gawin: I would love that too, but TBD :)
<DavidHeidelberg[m]>
we could have job which copies exact Debian packaging and just export .deb into artifacts (or whole repository as I think Salsa do)
<daniels>
there is stuff like oibaf's PPA which does that ... the danger is being on the hook for end-user support for distro integration, as well as having to build binaries for $n versions of every latest distro, which aren't necessarily what we're building against in CI
phire has quit []
<gawin>
iirc if you want to have build working everywhere you need to include all dependency, yeah it becomes large, but works
phire has joined #dri-devel
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
yuq825 has quit []
Akari has joined #dri-devel
<eric_engestrom>
daniels: agreed, it makes sense to build our kernel in the fdo ci like everyone else; I'll look into that (but it's not a priority yet)
apinheiro has quit [Ping timeout: 480 seconds]
<eric_engestrom>
gawin: I think for apps it's something that can be done, but for system libs it's way too dependent on the system/distro, especially with the number of build options we have
<eric_engestrom>
I think it's best to leave it to each distro to know how things should be done
<eric_engestrom>
what we could do is have a docs page pointing to distros that have something like that in place, eg. oibaf's ppa that was mentioned
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
kts has joined #dri-devel
<DavidHeidelberg[m]>
btw. we still don't have oibaf for the Debian, which would be cool since our CI is so Debian-based already :)
pochu has quit []
fxkamd has joined #dri-devel
<DavidHeidelberg[m]>
personally I mix Debian testing (main system) with mesa* from unstable and it feels weird
JohnnyonFlame has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
sul has joined #dri-devel
janusz has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<alyssa>
MrCooper: touche
Company has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
<jenatali>
Cool. I am on vacation though. If you were looking for a review I can take a look in December
<karolherbst>
fine by me
<eric_engestrom>
anholt: on deqp-runner, I've added about a dozen `-v` to make sure it's as verbose as possible (haha), but that doesn't print the tests as they are being run; is there another way to do that? I'm trying to determine which tests are being run when everything crashes
<anholt>
eric_engestrom: nope, nobody's done that. given that the project started from deqp, and you run a single deqp with 500 tests at a time or so, it wasn't useful. there's a bit of logging in piglit, and I think igt, but not deqp.
<eric_engestrom>
I'm not sure I understand the "it wasn't useful" ?
<anholt>
well, the only point that deqp-runner would have for logging things before a whole-system crash would be to list the caselist before invoking deqp
<anholt>
so you'd get "we're about to kick off these 500 tests, hope it goes well!"
<eric_engestrom>
but it's not "run these 500 tests and wait for all of them, then run the 500 next", right? so over multiple runs you'd get a narrower list
<eric_engestrom>
(but also, 500 would already be better than 3000 which I have right now)
<anholt>
I'm not sure what you mean? We do start deqps with like a 500-entry caselist.
<anholt>
unless you crank down tests_per_group manually
<anholt>
so, I think what you'd want is logging before/after when there was one test in the group, like piglit does. then you can run your suspicious big group of cases, and poke through those logs to see which tests started but didn't finish.
<anholt>
(I don't think it would be too useful to log test start/end from the result parser, because if you're trying to debug a whole system crash then you've got the result parser racing vs the failing test)
<anholt>
deqp startup gives you a lot more time for the logging to win the race against the test
<eric_engestrom>
yeah the print/run race is an issue but it would still narrow down the list of possibilities
vliaskov_ has joined #dri-devel
<anholt>
so, my thought would be top lift piglit's debug!() for test begin/end from prepare/clean to the core run(), gated on tests.len() == 1.
<eric_engestrom>
my issue right now is that I have a deqp-vk run of 20k tests that sometimes (rarely) crashes via an OOM, and I've narrowed it down to 3k tests that are actually running and not being skipped for whatever reason, but whenever I try to skip tests at the beginning of that list it messes up which tests end up running in parallel and the crash no longer occurs
<anholt>
or maybe you even want to figure out a way to reasonably debug!() log a whole caselist.
heat_ has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
ybogdano has joined #dri-devel
fab has quit [Quit: fab]
gawin has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: soo.. I want to add a "has_variable_shared_mem" to shader_info, but obviously there is no good way of figuring out if a shader even has that.. any ideas? The main indication would be kernel args to shared mem, but we will lose that info on the way
<karolherbst>
I was planning on gather_info to set it, but... maybe we want to do something different
JohnnyonFlame has joined #dri-devel
<jekstrand>
¯\_(ツ)_/¯
<jekstrand>
Depends on what you're trying to accomplish with it.
<karolherbst>
some drivers need to know this in order to properly set how many threads a block can have
<karolherbst>
and if it's variable, we have to assume the worst case
<jekstrand>
If it's just "does the shader ever access nir_var_mem_shared?", that's probably doable unless they've mapped it to global and converted them to load/store_global.
<karolherbst>
yeah.. no...
<karolherbst>
more like is "shared_size" actual what gets used or can there be more shared mem
<karolherbst>
I need to add a new gallium API for clGetKernelWorkGroupInfo and that's one of the things drivers need to know
<jekstrand>
I don't think we can get you an accurate maximum.
<karolherbst>
that's not what I need to know
gawin has joined #dri-devel
<karolherbst>
just _if_ there is additional shared memory
<karolherbst>
because if there is, drivers just have to assume the worst case anyway
<jekstrand>
I mean, you can probably figure that out based on whether or not there are any * local parameters
<karolherbst>
yeah...
<karolherbst>
of course
<karolherbst>
it's just hard to do in gather_info
<jekstrand>
Yeah, NIR really doesn't have that information.
<jekstrand>
spirv_to_nir could produce it
<karolherbst>
I could make it part of the new interface...
<karolherbst>
because in rusticl I do have that info
<jekstrand>
don't have what info?
<karolherbst>
mhh?
<jekstrand>
I'm confused what info you need where.
<jekstrand>
If you want the back-end compiler to know if shared_size is the actual size or just a hint, we can add something to shader_info that's produced by spirv_to_nir by looking at storage classes on kernel parameter pointers as it builds the wrapper.
mbrost has joined #dri-devel
<karolherbst>
if there are any *local args. I know that in rusticl, so that's fine if I add a "has_variable_shared_mem" to that new "get_compute_state_info" API I'm planning to add
<karolherbst>
nah... the backend compiler doesn't have to care