ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
darkapex1 has joined #dri-devel
darkapex has quit [Ping timeout: 480 seconds]
<alyssa>
...Okay, why am I getting crtc_state->mode that isn't drm_mode_equal to anything I specified in get_modes ...
vivijim has quit [Ping timeout: 480 seconds]
<alyssa>
I guess I need to be using mode_valid or something
<alyssa>
(but only with Xorg)
<vsyrjala>
get_mods is just so you can report a "these are somewhat guaranteed to work" mode list to userspace. but userspace is free to ignore those and pull a mode out of a hat
<alyssa>
Awful. thanks.
<alyssa>
so I need mode_valid regardless
<alyssa>
(relatedly, why does Xorg default to 1024x768 on my 4k monitor? actually I'd rather not know)
<imirkin>
alyssa: 1024x768 is the default resolution for kms too
<imirkin>
(can anyone even imagine a resolution larger than 1024x768?)
<vsyrjala>
no. vesa says we should default to 640x480
<alyssa>
"Refresh rate 289.73 Hz" ... ok I'm going to need to debug that too. fun.
<imirkin>
i mean, there's VGA (640x480) and SVGA (800x600), so 1024x768 must be even more super than super-VGA
<imirkin>
how much more super do you need it??
<alyssa>
ultra-VGA
<imirkin>
you joke, but all these various names have increasingly ludicrous names
<vsyrjala>
wyxzsvga
<imirkin>
these various *modes*
<alyssa>
extra-VGA
<alyssa>
uber-VGA
<alyssa>
mega-VGA
<imirkin>
basically. but they like to combine the words together
<alyssa>
which is wrong, then. would give a refresh rate of 60khz
<jenatali>
I'd buy that monitor
<alyssa>
jenatali: sounds like driver hell
dayssogood has quit [Remote host closed the connection]
<imirkin>
alyssa: ah, that does sound off
<imirkin>
jenatali: and then complain that you can't get 4k@60*k*hz? :)
<jenatali>
Yep exactly
mbrost has joined #dri-devel
nchery has quit [Quit: Leaving]
gpuman has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
gpuman___ has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
darkapex2 has joined #dri-devel
pnowack_ has joined #dri-devel
pnowack_ has quit []
darkapex1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
pnowack has quit [Ping timeout: 480 seconds]
gpuman__ has joined #dri-devel
gpuman has quit [Remote host closed the connection]
gpuman_ has quit [Remote host closed the connection]
gpuman has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
mikezackles has quit [Ping timeout: 480 seconds]
mikezackles has joined #dri-devel
gpuman__ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
jessica_24 has quit [Quit: Connection closed for inactivity]
tursulin has quit [Remote host closed the connection]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
mikezackles has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<Kayden>
is there a way I can download the kernel images used in the gitlab CI?
<Kayden>
in the logs for my failing run I'm seeing kernel stack traces about not being able to allocate pages
sdutt has quit [Remote host closed the connection]
mattrope has quit [Remote host closed the connection]
gpuman__ has joined #dri-devel
gpuman has quit [Remote host closed the connection]
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom1 has quit []
kmn has joined #dri-devel
pnowack has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman___ has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
gpuman has quit [Ping timeout: 480 seconds]
Hi-Angel has joined #dri-devel
Company has quit [Quit: Leaving]
thellstrom has joined #dri-devel
lemonzest has joined #dri-devel
shashanks has joined #dri-devel
shashanks has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
frieder has joined #dri-devel
shashanks has joined #dri-devel
aissen_ has joined #dri-devel
aissen has quit [Remote host closed the connection]
itoral has joined #dri-devel
rasterman has joined #dri-devel
jkrzyszt has joined #dri-devel
rgallaispou has joined #dri-devel
gpuman___ has quit [Remote host closed the connection]
gpuman has joined #dri-devel
boistordu_ex has joined #dri-devel
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
gpuman__ has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
orbea has joined #dri-devel
rbrune_ has joined #dri-devel
rbrune_ has quit []
lynxeye has joined #dri-devel
gpuman_ has joined #dri-devel
lynxeye has quit []
gpuman___ has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
swivel_ has left #dri-devel [#dri-devel]
swivel has joined #dri-devel
tursulin has joined #dri-devel
itoral has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
camus1 has joined #dri-devel
Ahuj has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
gpuman__ has joined #dri-devel
gpuman___ has quit [Ping timeout: 480 seconds]
gpuman_ has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
guru_ has joined #dri-devel
gawin has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
imre has joined #dri-devel
hansg has joined #dri-devel
darkapex3 has joined #dri-devel
darkapex2 has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
gpuman___ has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
gpuman has quit [Ping timeout: 480 seconds]
anarsoul|2 has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
<emersion>
does somebody need a drm-misc review for something?
<emersion>
i need one, and would like to trade
pendingchaos_ is now known as pendingchaos
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
<gawin>
in case of nir optimizations how do you test/deal if there's overflow?
<gawin>
for example sqrt(a) < x can be converted to a < x * x, but what x * x gonna be inf or int overflow?
aravind has joined #dri-devel
<JoshuaAshton>
gawin: then a would already be inf or overflowed
<gawin>
wait, maybe I explained this in wrong way
<gawin>
`if (sqrt(a) < x)` can be converted to `if (a < x * x)`
gpuman has joined #dri-devel
<gawin>
overall, but doesn't work if x is represented by finite number of bits like in IE754
gpuman___ has quit [Ping timeout: 480 seconds]
<gawin>
so the question is: how to use this optimization in a safe way with NIR?
thellstrom has quit [Ping timeout: 480 seconds]
darkapex3 has left #dri-devel [#dri-devel]
darkapex has joined #dri-devel
<alyssa>
gawin: 1. you don't
<alyssa>
2. if you do you mark it inexact with a ~ at the start so it doesn't apply to spir-v that needs correct numerical behaviour, but still applies to opengl which already has broken numerical support so doesn't mind
<FLHerne>
I thought nir had some range analysis, so the compiler might know that x can't overflow
<FLHerne>
or is that only used for loops?
gpuman_ has joined #dri-devel
<pendingchaos>
mostly comparing a value with zero
<pendingchaos>
limited range analysis
itoral has quit []
pcercuei_ has quit []
pcercuei has joined #dri-devel
rbrune has joined #dri-devel
gpuman__ has joined #dri-devel
gpuman___ has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
gpuman has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
iive has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
sdutt has joined #dri-devel
camus1 has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
thaytan has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
thaytan has joined #dri-devel
<Kayden>
daniels: awesome, thank you
<daniels>
Kayden: np!
fxkamd has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<daniels>
Kayden: it's a bit intimidating at first, but after a while you're Keanu Reeves
<daniels>
Kayden: another thing which is helpful to walk back is to go to the pipeline view, select the 'job dependencies' view, then enable 'show dependencies'
<daniels>
you ... might need a rather tall monitor, but it can be helpful to trace back how the jobs flow into each other
<Kayden>
ah, yep, I did that earlier
<Kayden>
it's a pretty nice feature :)
aravind has quit []
guru_ has quit []
guru_ has joined #dri-devel
guru_ has quit []
oneforall2 has joined #dri-devel
Guest485 has left #dri-devel [#dri-devel]
mikezackles has joined #dri-devel
DrNick has joined #dri-devel
<emersion>
daniels: ahah, alright! lemme read again the pending items in the protocol MR
<daniels>
emersion: <3
<daniels>
emersion: I'll have a quick pass this afternoon in between other stuff, but will have to be during the weekend for a longer/dedicated review
Duke`` has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
<nroberts>
but as far as I can tell, unlike with GLX, EGL doesn’t need to rebind the texture if it detects damage on the pixmap (although to be honest I’m not 100% sure…)
<nroberts>
so maybe calling resource_changed doesn’t make sense?
<nroberts>
in v3d it currently does a similar thing with a shadow texture and it just updates it whenever the texture is used, regardless of whether resource_changed is called
<nroberts>
I think that is probably technically more correct for EGL, even though it is really inefficient
Company has joined #dri-devel
jessica_24 has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
hansg has quit [Quit: Leaving]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
kmn has quit [Quit: Leaving.]
<tlwoerner>
mripard: your xdc talk was very interesting!
<tlwoerner>
mripard: i want to point out that yocto has a recipe for igt-gpu-tools, so if you're using yocto to build your images, cross-compiling igt is trivial
<tlwoerner>
mripard: yesterday, for fun, i built and ran igt-gpu-tools-tests on ~half-a-dozen boards
gouchi has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
fxkamd has quit []
fxkamd has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
sravn_ has quit [Ping timeout: 480 seconds]
sravn_ has joined #dri-devel
fxkamd has quit []
fxkamd has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
gouchi has quit [Remote host closed the connection]
gpuman__ has joined #dri-devel
gpuman has quit [Read error: Connection reset by peer]
gpuman___ has joined #dri-devel
gpuman_ has quit [Read error: Connection reset by peer]
<Kayden>
anholt_: so I was finally able to reproduce some failures on the dEQP multithread tests on my local Apollolake. The tests run for 10 seconds and if they haven't finished, they assert fail the dEQP process out of existence.
<Kayden>
anholt_: I'm pretty sure that my patch is causing some of these to go from 9.9s to 10.1s or something silly like hat
<Kayden>
not because it's doing anything less efficient, but just because Things Have Changed in the driver
<anholt_>
Kayden: which set of tests is that?
<anholt_>
(can I get a regex?
<anholt_>
by assert fail, I think you mean the "dEQP error: what(): Runtime check failed: '!m_requiresRestart' at teglGLES2SharingThreadedTests.cpp:2271"?
<Kayden>
that's one where I just blacklisted reset tests - I think we probably ought to do the freedreno trick for a proper solution, but I hadn't typed that up yet
<anholt_>
if you crash, you probably don't have qpa contents
camus has quit [Ping timeout: 480 seconds]
<anholt_>
also, things that aren't dEQP-GL* or VK* are not great at logging
<Kayden>
right
<anholt_>
but this case looks like just no test result
<Kayden>
wondering if something about the way that it shuts down due to the m_requiresRestart timeout is causing it to skip that test and have no result
<Kayden>
i.e. it's not getting run again or reported?
<anholt_>
seems very likely
<Kayden>
oh, also, I'm able to hit this timeout running dEQP-EGL.*multithread* in a single process non-concurrently.
<Kayden>
so running a number of tests concurrently would probably make it even more likely
<Kayden>
(it usually gets 2/3 of the way through the suite before hitting that, but...)
<anholt_>
(but that was in parallel with GPU hang tests)
<Kayden>
oh, cool, I hadn't spotted that
<Kayden>
so that was just barely on the threshold
<Kayden>
it seems like it's pretty random which tests end up hitting the timeout
<Kayden>
I kind of hate using dEQP-EGL.functional.sharing.gles2.multithread.* as a skip regexp, since that could lose us a lot of coverage
<Kayden>
maybe there's a way to speed these up...
<anholt_>
in a quick test of an rgba8888_window one on freedreno, it looks like papercuts.
<Kayden>
hmm, then again, dEQP-EGL.functional.sharing.gles2.multithread.random_egl_sync.textures.texsubimage2d.11 is taking 0.214s in a debug build here
<anholt_>
yeah, I was looking at one of those here, too, also very fast
<Kayden>
and that was the one that failed due to the timeout in my local run-all-the-multithread-tests run
<anholt_>
and your slowest tests are now *really* slow
<Kayden>
yeah, so, I'm kind of skeptical that any of these should be hitting the 10s timeout...that's pretty absurdly slow
<Kayden>
some of them run a bit longer, and maybe with concurrency, but...still seems off
<danvet>
tlwoerner, should get removed from program as soon as daniels gets around to this ...
<anholt_>
Kayden: deqp-egl: page allocation failure: order:0, mode:0x800(GFP_NOWAIT), nodemask=(null),cpuset=/,mems_allowed=0 also in the log. so, are we leaking memory?
<Kayden>
anholt_: I'm definitely not seeing that on my kernel, and yeah, the kernel backtraces are really concerning
<anholt_>
unless contexts are tremendously heavyweight to allocate?
* Kayden
looks for leaks
<Kayden>
they shouldn't be - we allocate one per GL context
<Kayden>
so this is just one more, total, across the entire app
<anholt_>
ah, and a multithread test like this should already be many contexts. yeah.
<Kayden>
also the fact that it's a kernel allocation failing is suspect
<Kayden>
there have been kernel leaks relating to syncobjs in the past
<Kayden>
but I think the version you have has the fixes that I'm aware of
<zmike>
where does driconf matching against process name happen?
<anholt_>
zmike: xmlconfig.c
<zmike>
driParseConfigFiles?
<anholt_>
Kayden: I feel like I kind of want to printf at screen create/destroy, and make sure that something about their multithread tests or something isn't making us leak screens
<anholt_>
zmike: seems straightforward to trace what's happening from the process references in that file
<Kayden>
good idea
<anholt_>
really grasping at straws here, this is very strange.
<Kayden>
bingo
<Kayden>
iris_screen_create gets called for every test
<Kayden>
iris_screen_destroy is never called
<anholt_>
and no destroy?
<anholt_>
rude.
<zmike>
anholt_: it does, but somehow it's not working right for #5380, so I'm trying to figure it out
<anholt_>
Kayden: I see matching create/destroy screen per test on freedreno
JohnnyonFlame has joined #dri-devel
<Kayden>
Yeah, we have...refcounting that I don't really understand
<anholt_>
hmm, that's surfaceless, though
* Kayden
looks at it
<Kayden>
wow, there's a lot of screen refcounting going on
<Kayden>
wow
<Kayden>
yeah, this is completely broken, glxgears isn't even freeing the screen
<anholt_>
someone made manywin work? I thought we had collectively decided that manywin was Wrong.
thellstrom has quit [Quit: thellstrom]
<Kayden>
I want to say there was some Red Hat bug where some real app also hit the manywin problem
<Kayden>
(which may also be the app being wrong, but alas)
<anholt_>
does screen creation allocate a resource by chance?
<Kayden>
yes
<anholt_>
so you've got circular references
<ajax>
manywin is definitely doing something insane.
<Kayden>
hmm...maybe it doesn't, I should check that
<ajax>
and yes, real app behaviour, that
<airlied>
Kayden: yeah it allocs the workaround bo
<Kayden>
that's what I was thinking of but it's not a resource
<Kayden>
(I had patches to make it one, but those never landed)
<airlied>
oh yeah it's just a bo
<anholt_>
well, once Kayden allocates a context in the screen, that will definitely make some resources, right?
<anholt_>
this encourages me to go get all of us asanned in pre-merge. would have led us to the answer much faster.
thellstrom has joined #dri-devel
<zmike>
anholt_: !12982 if you get a min
lynxeye has quit []
<Kayden>
I could probably make resources for u_upload_mgrs or other internal allocations not ref the screen
<Kayden>
or I could...make the screen record the refcount after aux_context creation, and have iris_pscreen_unref call iris_screen_destroy when it hits that number instead of 0. which is...super gross, but maybe the least likely to break in the future? :/
<anholt_>
trusting aux_context to hold the same number of resources forever sounds very fragile
<Kayden>
good point, it will accumulate more over time
<anholt_>
using resources across screens sounds so incredibly invalid to me
<Kayden>
I agree
<anholt_>
like, if you want to make dri3 work for this, then dedup screen creation
<anholt_>
I think you want the fd dedupe thing in freedreno_drm_winsys.c, then revert that.
mbrost has quit [Ping timeout: 480 seconds]
<anholt_>
(or, to be more clear: I think you want to hoist that up to some common code used by the pipe loader because augh why are we all having to do this?)
<Kayden>
apparently nouveau also refcounts their screens
mlankhorst has joined #dri-devel
<jenatali>
FWIW, in D3D-land we solve this with 2 refcounts - anything allocated by an app gets a public refcount which keeps the device (i.e. screen) alive, anything that might be owned by a screen/context gets an internal refcount which doesn't
<jenatali>
Anytime the public refcount goes from 1 -> 0, we release the extra ref on the device, which can then cascade and clean up all the internal objects
<daniels>
danvet: I’ve asked for it to be updated a few hours ago
<Kayden>
dj-death: I remember we tried dedup'ing screen creation to solve the manywin problem...but I don't remember why we didn't do that or it didn't work
<Kayden>
do you remember anything about this? it's been a year...
gawin has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<pcercuei>
sravn_: could you merge the "yellow tint fix" patch? Otherwise just ack it and I'll merge it.
rasterman has quit [Quit: Gettin' stinky!]
darkapex1 has joined #dri-devel
mikezackles has quit [Ping timeout: 480 seconds]
darkapex has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
imre is now known as Guest703
imre has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<Kayden>
anholt_: I'm a bit puzzled by the freedreno_drm_winsys code. fd_drm_screen_create take a file descriptor, "fd", and looks in the table for a matching screen. If there isn't one, it makes a new freedreno device which sets dev->fd = os_dupfd_cloexec(fd). It makes a screen with that dup'd fd. It then inserts the screen into the hash table...using dev->fd...the dup'd one...as the key
<Kayden>
(there is a line, int fd = fd_device_fd(dev), which makes a local "fd" variable that shadows the function parameter "fd")
<Kayden>
in other words...look up in table based on original FD...insert into table based on dup'd FD
<Kayden>
how can lookup ever succeed?
<anholt_>
Kayden: the trick is the hash key computation
<anholt_>
util_hash_table_create_fd_keys does the thing you need
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman__ has quit [Remote host closed the connection]
<Kayden>
oh, that's right.
<alyssa>
seems.. magical.
<Kayden>
right, the actual unix fstat and comparison of the fds is done in u_hash_table.c
<Kayden>
I am becoming a fan of handling this in pipe_loader if only to try and eliminate how much baklava there is
<alyssa>
anholt_: nice to see vulkan getting cleaned up :]
<Kayden>
so many layers that all try and solve a problem and you can't tell what's happening without looking at all of them at once
<Kayden>
and everybody's solution is a different homebrew layer combo
* alyssa
should really stop her recursive procrastinating
<anholt_>
Kayden: and for bonus points none of it's got a clear explanation of what the code does or why it's there in particular.
<Kayden>
yes!
<Kayden>
out of morbid curiosity, does manywin actually work on freedreno?
<Kayden>
(for some definition of "work")
<Kayden>
it seems like it ought to
<anholt_>
looks like yes
<anholt_>
complete with ubwc it seems
<Kayden>
sweet
<anholt_>
so, vulkan video extensions have been released, but there's no CTS for them that I can find?
<HdkR>
Still provisional apparently
<bnieuwenhuizen>
anholt_: provisional only, no? Or did they recently release the final spec?
<anholt_>
ah, "provisional"
<alyssa>
the CTS consists of watching the entirety of Star Wars on your driver, your boss can't argue with that
<HdkR>
alyssa: What did I do to deserve this punishment? :(
<airlied>
anholt_: there is an internal MR
<kisak>
alyssa: Which one? -> The good one
<alyssa>
HdkR: Did I say Star Wars? I meant the prequal.
<airlied>
but for basics only
<ccr>
not Lord of the Rings Extended Edition? :O
<airlied>
anholt_: dm'ed it to you
boistordu_ex has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
<Kayden>
so many hours of panning footage of New Zealand
<Kayden>
"I'm sorry but there was a blocky temporal artifact at 13 hours, 25 minutes, and 17 seconds, please try and reproduce"
<Kayden>
:D
<Kayden>
*throws driver into Mt. Doom*
<Sachiel>
"And it doesn't happen when playing from the last keyframe, only when playing the whole thing from the beginning"
<ccr>
:D
<HdkR>
Reminds me of tracking down a crash that only occurred if you left the application running overnight
<HdkR>
I don't want to do that again :P
jkrzyszt has quit [Remote host closed the connection]
<robclark>
Kayden: if it makes you feel better, I'm trying to track down a (seemingly kernel caused) iova fault that happens at a rate of once per ~1000 hrs ;-)
boistordu_ex has joined #dri-devel
<bnieuwenhuizen>
robclark: how do you even debug that?
<ccr>
gotta love issues like those. easily becomes a problem of proving if it's been even fixed afterwards.
anarsoul|2 has quit []
anarsoul has joined #dri-devel
<robclark>
bnieuwenhuizen: wait until series I just posted to add more smmu and pgtable state to gpu devcore dumps trickles out to enough users, and hopefully find a clue in crash.corp ;-)
iive has quit []
anujp has joined #dri-devel
<Kayden>
robclark: oh, man. that's the absolute worst
<robclark>
I guess the glass-half-full side is that is the majority of our gpu crashes.. but yeah, I'm pretty puzzled over that and haven't been able to figure it out so far with the crash dumps we have
boistordu_ex has quit [Remote host closed the connection]
illwieckz has quit [Ping timeout: 480 seconds]
xexaxo has quit [Read error: Connection reset by peer]
pcercuei has quit [Quit: dodo]
xexaxo has joined #dri-devel
boistordu_ex has joined #dri-devel
illwieckz has joined #dri-devel
<alyssa>
once per ~1000 hrs means with 100k users you get hundreds per day I hope? 🤔
camus1 has joined #dri-devel
<HdkR>
Just need to wait until 1000 hours after the update rolls out ;)
camus has quit [Ping timeout: 480 seconds]
<robclark>
alyssa: you might need to check your maths.. :-P
<Sachiel>
looks like perfectly fine PM math to me
<robclark>
lol
<alyssa>
robclark: what am i supposed to be a math major here
<alyssa>
...wait do you mean it only occurs after 1000 hrs of /continuous/ use?
<robclark>
not actually sure what you are majoring in (but then again I jumped around a few times before landing in CS)
<alyssa>
not just randomly at an expected rate of once per ~1000 hrs?
<robclark>
yeah
<alyssa>
yikes T_T
<robclark>
there is a CPMH metric.. crashes per million usage platform hours
ngcortes has quit [Remote host closed the connection]