ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
a-865 has quit [Remote host closed the connection]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
adavy has quit [Ping timeout: 480 seconds]
shashanks_ has joined #dri-devel
heat has quit [Remote host closed the connection]
adavy has joined #dri-devel
heat has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
Daanct12 has joined #dri-devel
<mareko>
alyssa: you can still make it parallel within a single compute workgroup, but it can only be 1 workgroup
<DavidHeidelberg>
eric_engestrom: "Please split the AMD common revert into its own MR, so that it gets tested on all the farms 😉" can we assume it's still working same way as few commits before?
<DavidHeidelberg>
while I'm the person who was yelling "never mix farm enable/disable", this saves one pipeline without side-effects
<mareko>
alyssa: specifically, a loop within a compute shader that runs as 1 workgroup processing the whole index buffer, executing e.g. 1024 invocations for that workgroup
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<mareko>
a single workgroup likely has 128 execution SIMD lanes, that's a lot of parallelism outside the reduce op you need for primitive restart
<mareko>
or prefix sum
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
<alyssa>
mareko: sure :)
heat has quit [Quit: Leaving]
yuq825 has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Leopold__ has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
a-865 has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
Marcand has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
yyds has quit [Read error: Connection reset by peer]
yyds_ has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Leopold_ has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
Duke`` has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
lplc has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
sima has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
macslayer has quit [Remote host closed the connection]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
frieder has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
rasterman has joined #dri-devel
Company has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
<eric_engestrom>
DavidHeidelberg: yeah, it's a revert of a revert commit, and it was originally merged in its own MR, so the chances of reverting that commit causing issues are low, but I think it's better to test it anyway
<eric_engestrom>
sorry for being annoying 🙃
<eric_engestrom>
*revert of a recent comit
<eric_engestrom>
*commit (/me is clearly not awake enough to type yet)
itoral has joined #dri-devel
<MrCooper>
tango_ karolherbst: yeah that's not a kernel issue, GPU virtual addresses are assigned by user space
<MrCooper>
tango_: BTW, isn't ROCm OpenCL open source as well? Thought so, not sure though
<any1>
It can't be a software issue unless the HDMI signal actually depends on scheduling in the kernel, and that's not the case, right?
<emersion>
any1: anything in dmesg?
<any1>
emersion: nope
<emersion>
in particular, underrun errors?
<any1>
none
mvlad has joined #dri-devel
<any1>
Another, perhaps interesting, data point is that if I force enable the hdmi connector (so it thinks it's always connected), yanking and plugging the cable back in is much likelier to result in blank display.
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
anon has joined #dri-devel
vliaskov has joined #dri-devel
anon has quit []
kts has joined #dri-devel
hansg has joined #dri-devel
kts has quit [Quit: Leaving]
apinheiro has joined #dri-devel
mripard has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
<dolphin>
airlied, sima: Any ETA for pulling the last drm-intel-gt-next PR, we could then move towards drm-intel-next-fixes?
<airlied>
oh did I miss that? I thought I'd caught them all
<airlied>
okay sorry, not sure how I missed it, will pick it up tomorrow
<dolphin>
sounds good
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
jlawryno has joined #dri-devel
samueldr has quit []
<jlawryno>
Hi, can someone help me out with dma-buf cache coherency?
<jlawryno>
there is this line in drm_gem_shmem_helper: `shmem->map_wc = false; /* dma-buf mappings use always writecombine */`
<jlawryno>
that seems a little confusing
<jlawryno>
are dma-bufs really always WC?
<jlawryno>
looks like dma-buf system heap is cache coherent
<tango_>
MrCooper: I know some parts are open source, but don't know how much of it. the big question remains if I should report the issue to Mesa or not given that it seems to arise from a conflict with ROCm
<tango_>
my last report about issues with Clover + ROCm wasn't exactly enthusiastically received
simondnnsn has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
uajain has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
yyds_ has quit [Remote host closed the connection]
yyds has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
jlawryno has quit [Quit: Leaving]
hansg has quit [Quit: Leaving]
uajain has joined #dri-devel
<karolherbst>
tango_: it sounds like a kernel bug to me honestly
<karolherbst>
and if it used to work, it' even a proper regression
<karolherbst>
so you could either git bisect it to pin point the commit breaking it or simply report that something broke it
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
yyds has quit [Remote host closed the connection]
iive has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<pepp>
tango_: the "bo conflict" issue sounds like a recent kernel regression
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
apinheiro has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.1.2]
itoral has quit [Quit: Leaving]
apinheiro has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
dsrt^ has joined #dri-devel
heat has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Dr_Who has joined #dri-devel
<Lynne>
Venemo mareko: have you had time to look at the mesh shader issue yet?
<Venemo>
Lynne: which one?
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Leopold_ has joined #dri-devel
<javierm>
sima: I just noticed that msm basically does the same to what I wanted to do in my alternative patch and they even have a comment mentioning to avoid having the firmware in the initrd
<sima>
javierm, the thing is, what do you do if the fw is still not there?
<sima>
I think msm goes with "can I offer you an Oops in these trying times" ...
<sima>
robclark, ^^
simon-perretta-img has quit [Ping timeout: 480 seconds]
<javierm>
sima: you mean with probe deferral or open? Failing to open is what msm does IIUC
<sima>
I don't see where it bails out
<sima>
hence the snark :-)
<javierm>
sima: ah, sorry you are right, load_gpu() has a void return value
<sima>
yeah and context_init doesn't check for priv->gpu
<javierm>
my patch for powervr makes the open to fail
<sima>
msm_postclose does check for lack of ->gpu, but at that point you've already gone boom
<javierm>
sima: yeah
simon-perretta-img has joined #dri-devel
<sima>
so I mean it ... works
<sima>
dri1 also worked in it's fashion
<sima>
it's just a pretty gross violation of the linux device model, or at least feels like that to me
<sima>
and so I think should be fixed there somewhere
<linusw>
My dim update is now failing like this: "Fetching drm-xe (local remote kernel)... git@gitlab.freedesktop.org: Permission denied (publickey)." hmmm?
Leopold_ has quit [Remote host closed the connection]
<sima>
rodrigovivi, thellstrom, demarchi ^^
<javierm>
sima: I see. Agree with you, I'll explore other alternatives then. Your suggestion of listing the firmwares used by built-in drivers makes a lot of sense indeed
<sima>
javierm, I think the officiated probe_defer is also ok, if gregkh acks it
<sima>
it looks like that's at least what cros wants/needs
<javierm>
or just built as a module and forget this issue :)
<sima>
or well, implemented, maybe it was just an accident they picked this one
<thellstrom>
linusw: You need to either register an ssh key with gitlab.freedesktop.org, or use the https: URL for the drm-xe repo, (try cd src; git config -e to replace the URL).
<sima>
thellstrom, the nightly.conf should list the https: remotes too to make this work automatically
<sima>
or more automatically
Leopold has joined #dri-devel
<sima>
hm it's there ...
<thellstrom>
sima: It does, but how do you make dim select the https url when creating a remote?
<sima>
thellstrom, should we have the https first so it's the one you get set up with automatically?
<linusw>
thellstrom: aha this one git is at gitlab instead of freedesktop.org I get it
<sima>
thellstrom, at least until more drm repos are on gitlab and so most committers are set up with gitlab ssh keys ...
<linusw>
hm it should probably also suggest "drm-xe" as the name for the git remote instead of "kernel"...
<sima>
otherwise I think we'll have a lot of fun right now
<linusw>
I already have a gitlab setup so I try to fix some proper ssh key.
Leopold has quit [Remote host closed the connection]
<sima>
linusw, yeah that's an oops, I thought dim goes with the abstract dim repo name "drm-xe" from nightly.conf ...
<thellstrom>
sima: Ok, I can change that.
<thellstrom>
linusw: Yeah "kernel" isn't a good suggestion, but that requires dim script changes. We're slowly getting to those....
<sima>
thellstrom, hm maybe sprinkling pick_protocol_url over a few places in dim might help for this?
<linusw>
thellstrom: thanks, I just renamed the remote and it seems to work fine.
<sima>
(I haven't caught up on all the dim discussions in the xe thread, just marked those as read)
Leopold has joined #dri-devel
<thellstrom>
sima: We're basically trying to land the xe documentation changes first, and then to the dim script changes.
yuq825 has quit []
<sima>
thellstrom, yeah sounds good
<sima>
the nightly.conf url switch as stop-gap is probably enough for now
<sima>
tursulin, ack on calling it drm_fdinfo_gem_bo_is_shared or something like that
<sima>
makes sense to limit where it should be used ...
<sima>
or whatever you feel is a good name that makes this clear
<linusw>
thellstrom: after renaming the remote to drm-xe and adding an SSH key everything works like a charm.
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
<thellstrom>
linusw: Great. Was the renaming required to make it work?
simondnnsn has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<linusw>
thellstrom: I don't know I was too scared to test it without giving it a proper name :D
<thellstrom>
;)
fab has quit [Quit: fab]
<demarchi>
thellstrom: it seems "kernel" is the default suggested by dim since it just uses the url for that
fab has joined #dri-devel
<demarchi>
we'd need to pass the repo down to url_to_remote for it to use the name from the manifest
<thellstrom>
demarchi: Yes. There are a couple of dim script changes to make things work properly with xe.
Haaninjo has joined #dri-devel
<demarchi>
thellstrom: are you going to work on that?
<sima>
demarchi, yeah it's a bit more surgery to have the repo name there :-/
<thellstrom>
sima: There appears to be an unresolved drm-tip conflict between drm-fixes and drm-next
<tursulin>
sima: Fdinfo part is fine (although why not stay in the _memory_stats_ namespace?) but no other api currently has "gem_bo" as part of the name. On top of ideas I already came up in the email maybe drm_fdinfo_gem_object_is_shared works for both?
<sima>
tursulin, either is fine imo
<sima>
gem_bo was just because the usual gem_buffer_object was more typing :-)
<sima>
ah it's just gem_object for functions
<tursulin>
sure, but afaics there are only ttm_buffer_objects, the gem ones are just gem_object
<thellstrom>
demarchi: I haven't started on that, just noted down a couple of changes so if you want to take a look that'd be great. IIRC you are pretty fluent with bash scripting.
<sima>
tursulin, yeah I'm honestly not sure why my brain picked up the buffer_object one out of a dusty corner ...
<sima>
demarchi, pick_protocol_url in the right places might also help, if you look into this
<demarchi>
sima: it also failed to detect the ssh repo as I had it as git@... instead of ssh://git@
<Venemo>
Lynne: it doesn't seem to be a shader issue to be honest, so I don't know what we can do about it
<thellstrom>
demarchi: Other things: "list-branches" doesn't pick up xe nor the topic branches on drm (only drm-intel and drm-misc are listed), and then there are the cherry-pick-fixes that hardcodes drm-intel.
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<Lynne>
Venemo: yeah, true, it does sound like a fw issue
<robclark>
sima: msm_submitqueue_create() returns an error if you don't have gpu yet.. didn't read whole scrollback but the deferred fw load has been letting us get by with suboptimal initrd's for a long time now
mbrost has joined #dri-devel
<sima>
robclark, but that's already after open has finished and not properly set things up?
<sima>
since it's in an ioctl
<sima>
robclark, I think cleanest would be to delay drm_dev_register (but maybe that upsets your userspace too much, which I think gregkh wont like)
<sima>
but latest open() I'd expect to fail, not some ioctl after that
<robclark>
open succeeds, just anything needing a gpu will fail.. it defn used to work and I don't think we've regressed it
<robclark>
open() fails, then plymouth fails
<sima>
there's a bunch of checks
<sima>
ugh
<robclark>
and defer loading means no display after lateinit kills "unused" clks/gdsc/etc
<sima>
robclark, oh so kms works, it's just gpu command submission that doesn't?
<robclark>
right
<robclark>
if you don't have combined gpu+kms you don't need to do this.. but if you do, you do..
<sima>
ok, then it makes some sense
<sima>
still freaks me out you have the context_init in open() which might or might not do much
<robclark>
I defn don't _like_ it.. but there isn't really a better option
<sima>
robclark, well my only bikeshed now is that I'd do stuff like priv->aspace setup only for the first context
<sima>
instead of maybe in open, maybe later
<robclark>
I'll double check context_init when I get to my desk, it wasn't there in the very early days, but has been around long enough that I don't _think_ it is broken
<robclark>
the submitqueue_create ioctl is optional for old userspace
<sima>
robclark, I think context_init is just a bunch of structs
fab has quit [Quit: fab]
<robclark>
we setup the fallback ctx in open()
<robclark>
brb
<sima>
but ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current); is the one that has !gpu checks in that function
<sima>
and I didn't immediately figure out how you handle the the case where ctx->aspace ends up NULL after open()
<sima>
oh msm_submitqueue_init also has a !gpu check
<sima>
robclark, i915 context does something with proto ctx, where we do an rcu deref for the fastpath
<sima>
and if it's not there, then grab mutex + slowpath lazy ctx init
<sima>
would feel more comfy with that pattern for priv->ctx I guess, since it means same path no matter whether deferred fw load or not
<sima>
but the main one really was that I missed that it's not needed for kms
frieder has joined #dri-devel
<sima>
so consider this a bikeshed (assuming you don't find a hole that has crept in over the years)
kts has joined #dri-devel
<sima>
javierm, ^^ so I guess img would be different since it means the entire driver doesn't really work without fw
kts has quit [Remote host closed the connection]
<javierm>
sima: yeah, also powervr is DRIVER_RENDER only (in my platform tidss is the DRM/KMS driver that is DRIVER_MODESET)
<javierm>
sima: while msm is both DRIVER_MODESET and DRIVER_RENDER, that's why the probe deferral trick won't help there
<sima>
yeah, so also not much need for early boot output since tidss takes care of that
<javierm>
sima: exactly
<javierm>
it doesn't affect having display early on boot
<sima>
iirc i915-gem does something similar to msm, for the same reasons
simondnnsn has joined #dri-devel
Leopold has quit [Remote host closed the connection]
simondnnsn has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
<thellstrom>
agd5f: There's an amdgpu conflict rebuilding drm-tip between drm-next and drm-fixes. Which one is the correct resolution for drm-tip?
<sima>
thellstrom, might need to manually update drm-rerere and hard-reset anything else away
<sima>
airlied pushed a wrong resolution and I fixed it on monday
<sima>
if it's still the same conflict
<sima>
javierm, you replied to me only in private, was that intentional?
<sima>
thellstrom, altough dim rebuild-tip should do that for you ...
<javierm>
sima: gah, it was not
<javierm>
sima: sorry, that's what I get for trying to answer emails while in a meeting
<agd5f>
thellstrom, if it's the mst_state->pbn_div line, the correct line should be mst_state->pbn_div.full = dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
<thellstrom>
agd5f:, sima: Thanks, I'll try to fix it.
<javierm>
sima: thanks for pointing that out and sorry for the additional spam :)
kts has joined #dri-devel
<sima>
javierm, you need the fw list at build time, not run time
<sima>
since without that you can't boot that kernel :-)
<sima>
the fw list is not static ...
<sima>
javierm, kinda like we have modules.builtin already, which is installed into /lib/modules/$kernel_version
<sima>
so probably needs a modules.builtin.firmware file
<javierm>
sima: ah, I thought you meant to keep in a list exposed by the kernel for user-space to consume but a modules.builtin.firmware makes more sense indeed
<robclark>
sima: for extra fun, the zap fw (on platforms that use that, which is basically everything but chromebooks) tends to be signed with device vendor key, so only thing that really knows what fw needs to be in initrd is the dtb.. haven't come up with a reasonable way to deal with that but we need something better than MODULE_FIRMWARE()
<javierm>
sima: let's see what gregkh says, I think that a request_firmware_defer() is reasonable or my patch as is. If not, I guess that will just let this thing go even when my mind refuses too do such thing
<sima>
yeah request_firmware_defer() sounds reasonable too
<sima>
but your timeout patch clearly shows that this is all a massive minefield
<javierm>
yeah
<sima>
robclark, ... :-O
<javierm>
sima: the timeout for probe deferral is really something that should had been refused IMO
<sima>
yeah, and I think I voiced that back then in the thread :-/
<sima>
or at least while ranting here
<javierm>
it makes the whole "probe deferral is a simple, reliable and consistent" argument not true anymore
<javierm>
sima: yeah I think you made that clear as a response to my v1
<javierm>
*consitent mechanism
macslayer has joined #dri-devel
hansg has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<thellstrom>
sima: Simplest solution seemed to be reverting your merge resolution and adding a new one. Not sure why it stopped working. But it seems rebuild-tip works now and the xe URL order has been changed.
<sima>
thellstrom, did the context move around?
<sima>
or do you have a different git version than me?
<sima>
2.43 here
<thellstrom>
Same version here. The resolution worked this morning when I added the xe repo...
<sima>
hm I'm confused, but yeah sometimes rerere falls over in peculiar ways
<sima>
thellstrom, thanks for sorting it out
<thellstrom>
np. Let me know if I somehow broke something.
eukara has quit []
mbrost has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
eukara has joined #dri-devel
Leopold has joined #dri-devel
djbw has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
lynxeye has quit [Quit: Leaving.]
Mangix has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
tyalie has quit []
tyalie has joined #dri-devel
fab has quit [Remote host closed the connection]
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #dri-devel
bnieuwenhuizen has quit [Remote host closed the connection]
bnieuwenhuizen has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simon-perretta-img has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
<demarchi>
sima: need some help with gitlab roles. It seems I can't change the role for some members even if I was given owner role in the kernel repo. Do you know why? Most of them seem to be when they were added by another owner, but there are some odd ones
<alyssa>
(restarted the job so hopefully the pipeline merges. won't show up in the accounting for failed merges, but..)
<daniels>
retries do get tracked
<alyssa>
good to know :+1:
<daniels>
demarchi: ok, that’s because the access is inherited, e.g. lfelipe has maintainer on drm/xe, so then gets the same role on drm/xe/kernel
<daniels>
if you change it there then it’ll get reflected; if you remove it then you can re-add at a different level
<demarchi>
daniels: ok, thanks. Let me try
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<robclark>
daniels, alyssa: looks like OOM killer wrecked things, and then the test was retried but didn't complete before timeout?
<alyssa>
robclark: Maybe? looked like deqp-runner-level fails
<alyssa>
looks like a big chunk of KHR-GL46.* is flaky on a630, maybe?
<jenatali>
I saw a hang recovery in the logs
<robclark>
it looks like things aren't failing until oom killer killed deqp
<demarchi>
daniels: that worked, thanks
<alyssa>
robclark: ah, fair
<robclark>
looks like there is one of the deqp processes that uses a lot of memory.. but maybe this could be flakey if there is some variation in which tests get grouped together by deqp-runner or something like that?
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
frieder has quit [Remote host closed the connection]
kzd has joined #dri-devel
<robclark>
hmm, mesa_logw_once() is still pretty chatty with piglit
<alyssa>
robclark: yeah, very possible
<alyssa>
not sure if that's possible to solve in general :/
<robclark>
on the fence about just removing the mesa_logw_once() vs backporting the missing kernel bit (which would anyways fix some other memobj tests)
<daniels>
demarchi: np :)
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
a-865 has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Remote host closed the connection]
a-865 has joined #dri-devel
simon-perretta-img has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
sravn has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
benjaminl_ has joined #dri-devel
Leopold_ has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
ced117_ has quit [Remote host closed the connection]
ced117 has joined #dri-devel
vliaskov has joined #dri-devel
vliaskov_ has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
alanc has quit [Remote host closed the connection]