00:28 imirkin: karolherbst: hm, i had pointed out that mmu thing to ben before, but he seemed to think that it was getting the right one.
00:29 karolherbst: imirkin: well maybe some nvaf are just different
00:29 karolherbst: I could check on mine
00:30 karolherbst: imirkin: but apperantly the patch I posted on the bug helped, soo...
00:33 nyef: Helped for mine, too.
00:34 nyef: glxgears went from not being able to allocate the depth buffer to actually working.
00:34 nyef: Which means that that's at least two NVAF hardware setups that it fixes issues with.
00:35 karolherbst: skeggsb: so uhm, what do we do then?
00:35 nyef: ... how many different system types have NVAF again?
00:35 karolherbst: I think only apple hardware actually got that GPU
00:36 nyef: So, maybe three?
00:36 karolherbst: I think two, the mac mini and the macbooks
00:37 karolherbst: some apple "news" sites seems to aggree
00:37 karolherbst: *agree
00:37 HdkR: What is NVAF?
00:37 karolherbst: ohhh
00:37 karolherbst: wait
00:37 HdkR: 320M?
00:37 karolherbst: that _is_ nasty
00:38 karolherbst: GeForce 320M vs GeForce _GT_ 320m
00:38 karolherbst: MCP89 vs GT216
00:38 HdkR: gross
00:38 nyef: Oh, games and fun.
00:38 karolherbst: well
00:38 nyef: So, what's the chip ID for the GT216?
00:38 karolherbst: older gens are even more crazy
00:39 karolherbst: 9800M GS/GTS/GT/GTX :)
00:40 karolherbst: 8800 GS/GTS/GTS 112/GT/GTS/GTX/Ultra :D
00:40 nyef: Ah, nva5.
00:41 imirkin: HdkR: 0xaf is the chipset id, we used to call it by NVxx where xx was the chipset id. with GK208, that goes to nv108, at which point it seemed wiser to go with nvidia's chip names
00:41 karolherbst: imirkin: we need that mcp mmu for the GPUs without dedicate VRAM, right?
00:41 imirkin: karolherbst: maybe, maybe not
00:41 imirkin: MCP89 is different from the other ones
00:42 nyef: Well, if it's two, then it's a confirmed win in both cases. If it's more than two, knowing what the other cases are would be nice, but we have confirmed wins in the two cases that we know of. (-:
00:42 HdkR: imirkin: Yea, I just never heard of NVAF. Once you start hitting Tesla or older my knowledge starts falling apart
00:42 karolherbst: nyef: macbook as well?
00:42 nyef: karolherbst: Mac Mini 2010.
00:42 karolherbst: ahh
00:42 karolherbst: that's what I've got
00:42 imirkin: HdkR: well it was the newest of the tesla's :) had a weird VIC too, which apparently exists in a newer form on the TK1+
00:42 karolherbst: oh no
00:42 karolherbst: actually late 2009
00:42 HdkR: Huh
00:43 karolherbst: uhm, not true
00:43 karolherbst: it is 2010
00:43 imirkin: but yeah, almost exclusively on macbook/mac mini
00:43 imirkin: so it doesn't get a lot of love
00:43 nyef: No chance on a desktop mac?
00:44 karolherbst: they've got the 330m
00:44 karolherbst: at least the imac
00:44 nyef: Okay, the mini IS a desktop system, but maybe an iMac or some sort of tower?
00:44 karolherbst: and towers had AGP/PCI cards
00:45 imirkin: you can put your macbook on top of a desk...
00:46 karolherbst: or maybe there was never a 330m.. weird
00:46 karolherbst: 9400m then a lot of ATI/AMD ones
00:46 karolherbst: and then 640M
00:46 karolherbst: (for the imacs)
00:47 karolherbst: imirkin: do you know in what ways the mcp89 is different?
00:47 karolherbst: it seems to be GT216 based though
00:49 karolherbst: but anyway, if in doubt I would rather trust user reports. Maybe there is more to it, but having a working machine is better than a non woring one
00:52 nyef: I was NOT looking forward to trying to track down why that depth buffer allocation was failing. Especially since it apparently was a page-flags thing.
03:59 HdkR: Nouveau generates >32bit attribute/varying fetches on Maxwell+ right?
04:12 imirkin: it def tries to combine stuff, based on various rules
04:12 imirkin: i forget precisely what the rules are for those
04:22 HdkR: I see
04:24 imirkin: it definitely does on fermi/kepler
04:25 HdkR: I could definitely see it being a thing there
04:26 imirkin: i doubt you can find any simple obvious things to improve in the nouveau compiler
04:27 imirkin: most of the improvements are to be had from more sophisticated logic
04:31 karolherbst: imirkin: btw, care to take a look at my set+slct series? https://patchwork.freedesktop.org/series/45204/
04:33 karolherbst: HdkR: best thing to do really is to take a lot at shaders from games running super slow and try to search for patterns which can be optimized a little.
04:33 HdkR: imirkin: Nah, this is my own curiosity. Although those XMAD improvements on the mailing list looked sexy :P
04:33 karolherbst: HdkR: what we kind of completly are loop related optimizations
04:33 karolherbst: *miss
04:36 HdkR: karolherbst: Loop unrolling or missing divergence analysis within the loop?
04:36 karolherbst: everything
04:37 karolherbst: thing is, we don't really have a nice way of manipulating the CFG right now
04:38 karolherbst: but there are also other things like moving things into/out of loops
04:38 karolherbst: sometimes you end up redoing computations you don't have to do every time
04:38 karolherbst: but sometimes that can reduce GPR usage, increasing performance differently
04:39 karolherbst: but then again, it changes if the loop runs 4 or 50 times
04:40 HdkR: Of course
04:45 karolherbst: but, to be safe, we could simply move the top or bottom instructions out and stop at any non moveable
04:45 karolherbst: that shouldn't cause any per regressions
04:45 karolherbst: benefit might be quite small though
04:45 karolherbst: but... where is the loop header and the exit?
04:46 karolherbst: well, we can just annotate BBs and get the information from TGSI
04:46 karolherbst: which works as long as we don't modify the CFG
04:50 HdkR: So you're saying the main limitation is that you have a limited ability to transform the CFG?
04:53 HdkR: Almost sounds as bad as working with clang's AST :P
04:53 karolherbst: well that's why you want to do things based on the LLVM stuff, not clang :p
04:53 karolherbst: but llvm is much nicier in this regard
04:54 karolherbst: you can split a BB with one method call
04:54 karolherbst: we.. can't
04:55 HdkR: LLVM is nice like that
04:56 HdkR: LLVM also takes a million lines of code to get a backend stuffed in to it
04:58 HdkR: `20 files changed, 1720 insertions(+), 370 deletions(-)` 1000 lines of cleanup, ~700 lines of intrinsic implementations. Combination of last weekend and the last couple of days :P
07:04 kubast2: So I figured libdrm-2.4.92 isn't that far away from master ,so maybe it will work nice with the master mesa :shrug:
07:05 kubast2: not sure how it all interacts with each other yet ,but yeh
10:30 kubast2_: That took a very long time (12 hours)
10:31 kubast2_: But the drm_next have just freezed(keyboard doesn't work mouse doesn't networking works) ,my guess is next tine I could try to only shutdown Xorg and it would work just fine
10:31 kubast2_: Because the keyboaed unfreezes on shutdoen
10:33 kubast2_: This is a huge dmesg ans xoeg log and only last secs are when the crash happend
10:34 kubast2_: since it's 12hours long or even more
10:34 kubast2_: http://termbin.com/6ti65 http://termbin.com/lw91
10:44 kubast2_: Also what's a difference beetween high critical and emergency temperatures?
10:45 kubast2_: High is the nvidia marketing temp limit
10:45 kubast2_: What's up with the other 2?
10:45 kubast2_: And when does nouveau clock down in relation to this?
13:16 pendingchaos: imirkin: unless I'm misunderstanding something, can't https://trello.com/c/GGfLYwbD be done by doing
13:16 pendingchaos: "getSrc(src_index)->getUniqueInsn()->bb" instead of adding and maintaining an array of BasicBlock pointers to each phi instruction?
14:12 imirkin: pendingchaos: you're misunderstanding.
14:12 imirkin: but at first blush, that would definitely appear to be the case
14:12 imirkin: imagine the following code
14:13 imirkin: int a, b, c; a == ..., b = ...; if () { c = a } else { c = b }; use(c)
14:14 imirkin: in ssa-land, with copy-prop, after the else, you have a phi node that consumes a and b as arguments
14:14 imirkin: when going out of ssa, you have to insert mov's into the respective blocks in order to resolve the constraints
14:15 pendingchaos:nods
14:35 karolherbst: pendingchaos: look at how nir does things. They basically do something like this: a = phi block4: b block5: c
14:35 karolherbst: currently we don't store the block information inside a phi node, but rely on the order of incoming edges
14:43 karolherbst: imirkin: regarding phis, I have a fix for GlobalCSE which merged phis, because the sources were equal
14:43 karolherbst: which we can't do
14:51 imirkin: karolherbst: right, GlobalCSE can't CSE phi's
14:51 imirkin: i thought there was a fix for that a long time ago
14:52 karolherbst: I sent a patch out to fix GlobalCSE where this happened, but the fix didn't fix the real issue
14:53 imirkin: what's the real issue?
14:53 karolherbst: https://github.com/karolherbst/mesa/commit/e079fc6a9f76ec817f9af8368196cb31049f629f
14:53 karolherbst: that we try to merge something like that
14:53 karolherbst: the fix I sent out was something like that: https://github.com/karolherbst/mesa/commit/f5defc56d3f3720149a16c830fd035756393ead7
14:53 karolherbst: we want both though
14:54 imirkin: ok, so the first one (to isActionEqual) is obviously correct.
14:54 imirkin: R-b me
14:54 imirkin: this->op == OP_PHI && that->op == OP_PHI &&
14:54 imirkin: you don't need to check that->op
14:54 imirkin: if ops are different, we already return false above
14:55 karolherbst: ahh, right
14:56 imirkin: and given that, i believe that the second patch to GlobalCSE is actually unnecessary.
14:56 karolherbst: for now it should be, yes
14:56 imirkin: you should just assert that op != PHI
14:56 imirkin: and if it ever happens, we can re-evaluate
14:57 karolherbst: I kept it just in case somebody wants to add smarter code to isActionEqual
15:07 imirkin: karolherbst: well, i'd rather have an assert in there
15:07 karolherbst: okay
15:08 imirkin: you can keep your patch around, but these sorts of things can paper over unexpected situations
15:08 imirkin: which become increasingly difficult to debug
15:08 karolherbst: mhh, wondering though, if we stick an assert there and not handling the situation, the aplpication would probably crash anyway
15:10 imirkin: assert's only hit in debug
15:10 karolherbst: imirkin: maybe put an assert in additional to my patch? So that even if it indeed happens, we would do something sane nonetheless?
15:10 karolherbst: allthough I am quite positive that this should like never happen
15:10 imirkin: i dunno ... honestly i'd rather not have untested code in such critical paths
15:10 karolherbst: because that would mean we have a phi, with sources being both phis inside the same BB
15:11 imirkin: for "just in case" purposes
15:11 karolherbst: right, but currently hitting that path would lead into another assert anyway
15:11 karolherbst: because we can't stick a phi after a join
15:16 imirkin: yeah, but a lot of debugging
15:16 imirkin: stick an assert in there
15:16 imirkin: and you know exactly why it's happening
15:18 karolherbst: right
17:26 karolherbst: imirkin: I guess it is okay when I put the assert into the isActionEqual commit? https://github.com/karolherbst/mesa/commit/1057fba1f8a44dfd5f8d6381ba5c36516e3ab89c
18:40 imirkin: karolherbst: fine by me
18:46 karolherbst: imirkin: I don't know if you saw my question regarding the "KHR-GL45.packed_depth_stencil.blit.depth32f_stencil8" fail. Do you want to take care of this one, or do you already have an idea, but no time. Because depending on your answer I would either fix that or try to figure out why some tests sometimes fail
18:47 imirkin: i have no idea and no time :)
18:47 karolherbst: okay :D
18:47 karolherbst: btw, we found what is wrong with MS images
18:47 imirkin: the TWO_D_NO_MIPMAP thing?
18:47 karolherbst: yes
18:48 imirkin: make sure it works for non-tiny images
18:48 imirkin: although .... nevermind. should be fine.
18:48 karolherbst: well more like we can't read from 65536 heigh 2D textures
18:48 imirkin: it's generally used for 2DRect
18:48 imirkin: but those can still be tiled
18:48 karolherbst: well, using NO_MIPMAP fixes the 2DMS case
18:48 karolherbst: not 2darrays
18:49 imirkin: =/
18:49 karolherbst: I doubt it really matters in practise, because who is insane enough to create such big MS textures
18:49 karolherbst: especially with nouveau
18:49 imirkin: since the nomimap variant doesn't support arrays?
18:49 karolherbst: I guess so
18:50 karolherbst: pendingchaos_ said that nvidia uses NO_MIPMAP for both though
18:50 karolherbst: imirkin: are there problem switching 2d textures to the NO_MIPMAP thing? I don't really know what the disadvantages would be
18:50 imirkin: this is all maxwell+ issues, right?
18:51 karolherbst: afaik, yes
18:51 imirkin: welllll
18:51 imirkin: yes, i don't think it'll work
18:51 imirkin: e.g. if you bind to level 1
18:51 imirkin: we don't just adjust the offset
18:51 imirkin: we set the minlevel of the tic to 1
18:51 imirkin: iirc
18:51 karolherbst: ahh
18:51 karolherbst: okay, so for now we just leave it as and have the piglit test reminding us
18:51 imirkin: but with NO_MIPMAP that won't pan out so great
18:52 imirkin: well, it's fine to set 2dms to NO_MIPMAP
18:52 karolherbst: uhm, right
18:52 karolherbst: then we don't have the reminder, because piglit runs a quick test
18:52 karolherbst: and 2dms arrays only fail for the non quick one
18:53 karolherbst: uhm..
18:53 karolherbst: but it still throws an error
18:53 karolherbst: weird
18:53 karolherbst: ohh no, that is the output of all subtests
18:53 karolherbst: piglit sucks a little if it comes to subtests :(
18:54 karolherbst: ohhh wait
18:56 karolherbst: okay, no, no clue
18:57 karolherbst: imirkin: quick review for those two patches? Then I can push them as well. https://github.com/karolherbst/mesa/commit/d1d897309d2d9dc7079a332135ca9bfb68828824 https://github.com/karolherbst/mesa/commit/71760bc13ad14f426cd6485589e4920413fea405
19:02 karolherbst: ohh, an idea: we could report the cycle count for maxwell+ and compare that in the shader-db as well
19:03 karolherbst: might be a bit missleading regarding loops, but I guess better than nothing
19:08 pendingchaos_: karolherbst: variable latency stuff like loads and texture fetches might also be a bit of an issue
19:09 karolherbst: right
19:14 karolherbst: pendingchaos_: but the idea was, to reduce stalls between instructions, and it doesn't really matter how long those variable latency instruction take. Maybe we could add them with their max latency, but I doubt we really know that for all instructions
19:16 karolherbst: pendingchaos_: there is one thing I really would like to see inside codegen: anotating sources with possible values(ranges) and being more clever in algebraicopt
19:16 pendingchaos_: value range analysis/propagation?
19:16 karolherbst: yes
19:17 karolherbst: like if you do a max $r1 0.1 $r3, you don't know if you can opt it away, because you have no clue what $r3 is, but if $r3 is >0.2 you could opt that max away ;)
19:17 karolherbst: handling phis would be a bit problematic
19:17 karolherbst: but besides that?
19:18 karolherbst: I already have some WIP patches somewhere, but it is quite some work
19:18 karolherbst: pendingchaos_: https://github.com/karolherbst/mesa/commit/32e4300377c013a2c056614f4c8ecf304f1f5169
19:19 karolherbst: but this was more toying around than creating anything meaningful
19:19 pendingchaos_: and the being more clever in algebraicopt?
19:20 karolherbst: I would rather add a new opt
19:20 pendingchaos_: with i965, they seem to assume loops execute 10 times btw
19:21 karolherbst: and slowly ports opt over from algebraicopt to the new thing
19:21 karolherbst: *opts
19:21 karolherbst: floats are also a bit annoying regarding Inf and NaN
19:22 pendingchaos_: yeah
19:22 karolherbst: anyway, doing it for ints only for now and add stuff later would be already great
19:22 karolherbst: and it doesn't have to land in one step
19:22 karolherbst: or not immediatly
19:22 karolherbst: maybe it taks a year until something like that is done... dunno
19:25 pendingchaos_: i965 seems to assume best-case (data in caches) for variable latency instructions
19:25 karolherbst: yeah, that's probably the best idea
19:25 pendingchaos_: or close to best-case
19:25 pendingchaos_: (i965 sometimes assumes close to best-case)
19:26 pendingchaos_: what would be different about the new algebraicopt?
19:26 pendingchaos_: I think you said it would be nice to have more analysis? and do opts conditionally
19:45 karolherbst: pendingchaos_: well, maybe we could integrate all this into algebraic opt, but I would like to somehow split the detection of possible opts and their execution inf cases where you aren't sure if you really want to do that
19:45 karolherbst: but this is a different thing
19:45 karolherbst: pendingchaos_: like imagine two adds
19:45 karolherbst: you could merge them into an add3
19:45 karolherbst: but, sometimes you can't eliminate the first add, because the intermediate result is also used somewhere
19:45 karolherbst: so you increase live ranges of the operands of the first add
19:46 karolherbst: and in such a case you might not want to convert one of the adds to an add3
19:47 karolherbst: you still want to trade of between smaller live ranges and less instructions, but you don't want to increase live ranges and not decrease instruction count
19:47 karolherbst: but maybe that intermediate result is used in another add
19:47 karolherbst: which could be converted into add3
19:48 karolherbst: and if you would know that the intermediate value could be optimized away, you could do that optimization nonetheless, even if you decided before that if the use count is > 1 you don't
20:06 HdkR: karolherbst: This is just regular cost modeling?
20:11 imirkin: karolherbst: for the depth thing, that was the blitter fail with MS? i think the only reasonable thing to do is to make the 3d blitter use per-sample shading instead of messing around with texture sizes
20:13 karolherbst: imirkin: yes
20:14 karolherbst: mhh, yeah maybe we could use per-sample shading here, I guess I will toy around with it a little and see where that gets me
20:15 imirkin: that won't work on pre-nva3 though
20:15 imirkin: but iirc this all happens to work better on nv50
20:16 imirkin: (pre-nva3 didn't have sample-shading)
20:23 nyef: Umm... Is the use of AIGLX likely to cause multi-thread/context problems?
20:25 imirkin: which one's AIGLX?
20:25 imirkin: is that indirect glx?
20:26 nyef: Yeah.
20:26 nyef: Accellerated Indirect GLX.
20:27 nyef: Using the GLX wire protocol (limited to GL 1.3, I believe) to ship the command stream to the server, then having the server do the things.
20:28 nyef: For some reason, with the "don't mess up the host system" build environment, X is still trying to load the system nouveau dri driver instead of the custom-built one.
20:30 nyef: I'm not able to reproduce a particular crash on this lash-up, but I don't know if it's because AIGLX or if it's because "happens on tesla, not kepler".
20:35 nyef: ... Actually, either case would be a win, if I knew which case it was.
20:35 nyef: On the one side, known issue. On the other, drastic cut-down of the possibility space.
20:41 imirkin: it's a hardcoded path for loading the thing
20:41 imirkin: although in the most recent X, i think it looks at some env var as well now
20:42 imirkin: iglx is disabled by default, even on semi-recent X servers
20:42 imirkin: so it's unlikely that iglx-submitted draws play a role
20:42 imirkin: iirc it was disabled by default in 1.17 or so
20:45 nyef: Hrm.
20:48 nyef: Right, my best path forward is to sort the system to using filesystem labels and UUIDs, pop the disk, and lash it to my mac mini to try again. If it starts failing, it's a tesla problem. If it doesn't, it's probably the aiglx thing, somehow.
21:22 pqatsi: Hello! I bought a new notebook and I cant use nvidia primus here with nouveau. The error in application after use DRI_PRIME=1 is nvc0_screen_create:906 - Error allocating PGRAPH context for M2MF: -16
21:22 pqatsi: And the dmesg is in https://pastebin.com/E05hsDR7
21:23 pqatsi: Its a know issue? How to diagnose and fix it?
21:23 pqatsi: Im using F28 vanilla instalatiion
21:28 karolherbst: pqatsi: something is broken regarding d3cold support for GPUs, try to boot with nouveau.runpm=0 even if that's defeate the purpose
21:28 karolherbst: it is kind of on my todo list to figure out what is wrong and to fix that
21:30 pqatsi: karolherbst: the runpm just disables card power management?
21:30 pqatsi: (Anyways, let me test, i back here in a bit)
21:36 pqatsi: karolherbst: Well, not so good: Messages reduces, but glxgears dont uses nouveau: https://pastebin.com/8jMdjtAz
21:39 rhyskidd: pqatsi: hrmm, part of that error is in sectboot on that GP108
21:39 pqatsi: rhyskidd: Its a brand new dell inspiron 7000
21:39 rhyskidd: yup
21:40 rhyskidd: marketing name of the GPU is MX150 right?
21:40 pqatsi: So may be some unsupported card?
21:40 rhyskidd: the engineering name of that card is GP108
21:40 pqatsi: [leonardo@manaurara ~]$ lspci | grep -i nvidia 01:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)
21:40 rhyskidd: it's one of the newer Pascal GPUs, so potential for some corner cases
21:42 rhyskidd: can you pastbin the output of: tree -s /lib/firmware/nvidia/gp108
21:43 pqatsi: surelly
21:44 pqatsi: rhyskidd: https://pastebin.com/vtYw9D19
21:48 rhyskidd: are you able to test booting with a monitor plugged in?
21:49 pqatsi: Hmmm, I can handle it. Cold boot or hot plug?
21:50 pqatsi: Its a FullHD television with hdmi port - just to inform
21:50 pqatsi: And what you need I do in the test, rhyskidd ?
21:51 rhyskidd: we've seen similar errors before with Pascal cards.
21:51 rhyskidd: issues is that the dGPU "powers off" and doesn't come back properly
21:51 rhyskidd: having a monitor connected prevents it dropping into a d3 or similar low power state (maybe)
21:51 rhyskidd: then see what dmesg looks like after that cold boot
21:51 karolherbst: pqatsi: yeah... there are other secboot related issues outstanding, but with runpm=0 at least your machine shouldn't randomly freeze
21:52 pqatsi: rhyskidd: I undestand. Even with the runpm=0 the state is reached?
21:52 karolherbst: I have a laptop with some of those issues myself, so I kind of want to look into those
21:52 pqatsi: karolherbst: in fact they dont freeze randomly because i think wayland chooses intel gpu for everything in fedora except if DRI_PRIME=1
21:53 pqatsi: But using DRI_PRIME without the runpm=0 leats to a huge crash
21:53 karolherbst: yeah
21:53 pqatsi: Another thing i noticed. If after this issue, i try to unload nouveau module, rmmod freezes and touchpad stops
21:53 karolherbst: there are basically two issues: resuming is broken and secboot is broken
21:54 karolherbst: pqatsi: well, keep moving, at some point your pointer moves
21:54 karolherbst: also you should see a message every 2 seconds in dmesg
21:54 karolherbst: at some point it stops
21:54 karolherbst: takes around 3 minutes or so
21:54 karolherbst: pqatsi: locally I have a script to invoke the ACPI stuff manually
21:55 karolherbst: and remove the PCI device from the kernel
21:55 pqatsi: Indeed it stops. The only annoying thing in dmesg after this is no related to nouveau: [ 1334.486430] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5 (As i found with google, a issue with AER and the wireless card)
21:55 karolherbst: yeah...
21:55 karolherbst: I have that with my nvme controller
21:55 pqatsi: karolherbst: like the usb power/control?
21:56 karolherbst: pqatsi: no. you can completly remove a pci system from your system via sysfs
21:56 karolherbst: and then invoke ACPI methods to turn the GPU off
21:56 pqatsi: Interesting!
21:56 karolherbst: acpi_call is the module which lets you invoke ACPI methods
21:56 rhyskidd: i also have a laptop with some of these issues, so like karolherbst I kind of want to get these fixed properly :)
21:56 karolherbst: and usually the method is "\_SB.PCI0.PEG0.PG00._OFF" and "\_SB.PCI0.PEG0.PG00._ON"
21:56 karolherbst: but can be different on each system
21:57 karolherbst: rhyskidd: well, I kind of know what is wrong witht he suspending stuff though
21:57 karolherbst: but, I don't know how to fix it
21:57 karolherbst: the device turns on and everything, _but_ the communication isn't established yet
21:57 karolherbst: or not fixed or whatever has to be done
21:58 rhyskidd: are you referring to your old patch to "turn it off and on again"?
21:58 karolherbst: so the kernel still tries to communicate with the device in some way, but it fails
21:58 karolherbst: no
21:58 karolherbst: that is the secboot issues
21:58 karolherbst: *issue
21:58 karolherbst: I am talking about the d3cold bug
21:58 rhyskidd: mmm
21:58 pqatsi: Well, while this, let me try rhyskidd reboot with monitor.
21:58 karolherbst: rhyskidd: so basically the device responds with 0xffffffff on each bar access
21:58 karolherbst: or maybe that is some default error value
21:58 karolherbst: who knows
21:59 karolherbst: but this is basically the bug
21:59 karolherbst: rhyskidd: if you remove the pci device, turn it off and on via a ACPI method
21:59 karolherbst: and rescan the bus, it works
21:59 rhyskidd: hrmm
21:59 rhyskidd: i thought 0xffffffff was the default pcie value when nothing could be read
21:59 rhyskidd: defaults low or something
21:59 rhyskidd: (i don't know pcie that well)
22:00 karolherbst: yeah
22:00 karolherbst: might be
22:00 karolherbst: anyway that's the situation
22:00 karolherbst: anyway, this issue has to be fixed first
22:00 karolherbst: pointless fixing the secboot issue before that
22:14 rhyskidd: while you're here, do you have any vbios from volta pulled via nouveau?
22:17 pqatsi: Hello karolherbstand rhyskidd - no changes after boot with HDMI. Logs at https://pastebin.com/s5S5drs6
22:18 pqatsi: A question: Considering F28, may this repo make some difference? https://admin.rpmfusion.org/pkgdb/package/nonfree/nouveau-firmware/
22:20 rhyskidd: you should already have those firmware files
22:20 rhyskidd: that's what I got you to check initially in /lib/firmware/nvidia/gp108
22:25 pqatsi: rhyskidd: they are here. May some version mismatch happens or may F28 be newer enough?
22:26 rhyskidd: there was an initial release of the GP10x firmware files that were borked, but since fixed. You appear to already have the latest -- matches mine here
22:32 pqatsi: rhyskidd: Understood. So the status is this is a known issue, right? Someone reported this in someplace i can follow?
22:48 pendingchaos_: Can https://trello.com/c/F0oW1ojT/199-nvc0-combine-tid-ntid-fetches be closed?
22:48 pendingchaos_: combining ntid fetches isn't very useful imo, as I explained in my post
22:49 pendingchaos_: *be archived
22:51 karolherbst: rhyskidd: uhm.. let me check
22:51 pendingchaos_: *in my mailing list post
22:52 karolherbst: rhyskidd: actually yes... I put it inside nv140 directly
22:52 karolherbst: shame on me
22:53 karolherbst: rhyskidd: fixed and pushed it
22:53 karolherbst: pendingchaos_: yes
23:21 imirkin: pendingchaos: i'll need to test your patch on nv50 with some traces i have which had various problems with the phi thing
23:23 imirkin: it's really nice to see that sort of cleanup though
23:23 imirkin: doing this should enable various cfg manipulation
23:23 imirkin: which was previously next to impossible
23:23 pendingchaos: traces for https://bugs.freedesktop.org/show_bug.cgi?id=90887?
23:24 imirkin: yes, that one
23:24 imirkin: the issues only came up on nv50
23:24 imirkin: probably due to luck
23:25 imirkin: iirc those shaders had texturelod or texturebias calls
23:25 imirkin: and on nv50, the lod/bias argument has to be uniform
23:25 imirkin: so we jump through all kinds of hoops to execute the texture op 4x
23:25 imirkin: which causes various cfg differences
23:27 imirkin: i have one plugged in, so it won't be a big deal
23:27 imirkin: will try ~tonigh
23:31 pendingchaos: karolherbst: perhaps some checks could be done during RA to ensure that phi instructions make sense (basicBlocks.size() >= srcCount() and each source is defined in or available in it's basic block)