01:15skeggsb: mangix: patch in my tree
01:30imirkin:wonders what the purpose of that bit is
01:30skeggsb:would like to know that too
01:30imirkin: i.e. not what it does but why it exists/what the use-case is
01:30skeggsb: apparently, BIOS and UEFI CSM (ie. not the native UEFI GOP driver) map the framebuffer there
01:31skeggsb: but, i'm not sure why RM keeps it that way afterwards
01:31imirkin: that makes sense
01:32skeggsb:wonders how many other weird hang/crash cases are because of this
01:33skeggsb: games that use a heap of virtual address space could probably trigger it too, if there's lots of page tables
01:34imirkin: perhaps it'll be the thing that finally fixes F1 ;)
01:34skeggsb: isn't that because of some shader hang?
01:34imirkin: (it always feels that way when you fix $weird bug)
01:35imirkin: yeah, but who knows why the shader hang
01:35imirkin: i mean - the shader ahng happens because some data comes out wrong
01:35skeggsb: btw, i might have asked this before, but, why doesn't the watchdog kill the shader?
01:38imirkin: the shader kills the watchdog :p
01:38imirkin: i think the watchdog works better when you have like one hung shader invocation
01:38imirkin: here every invoc hangs
01:38imirkin: and causes ctxsw timeouts? i forget
01:39skeggsb: yeah, that'd happen if a shader is hung, the GPU can't switch contexts until it's idle
01:39imirkin: but tbh, i dunno for sure
01:39imirkin: i try to avoid running things that hang my box hard
01:39imirkin: can't say i always succeed... but i try!
01:46mwk: what the fuck is that...
01:56mangix: skeggsb: success
02:06imirkin: heh. edge flags.
02:19mwk: I have no idea why there's a method to perform a NOP on the transform engine, but oh well.
02:36David_Hedlund: How well supported is GeForce GTX 1080 Ti?
02:36David_Hedlund: I found it on https://nouveau.freedesktop.org/wiki/CodeNames/
02:46David_Hedlund: A "NV130" column should be added to https://nouveau.freedesktop.org/wiki/FeatureMatrix/
02:56mangix: code too hard to understand, must be black magic :)
02:57mangix: i'm just going to guess init_generic_condition has to do with display outputs
04:21mwk: everything about Kelvin is surprisingly sane so far
04:35mwk: I've been looking for that for years...
07:44pmoreau: mwk: What are those LTC methods? https://git.io/v7q2F I know of one LTC method, but it comes from a SIGGRAPH 2016 paper, so probably not the one found in Kelvim cards. And it would make no sense to have it in hardware.
09:21mwk: pmoreau: light context
09:22mwk: one of T&L engine's memories
09:23mwk: LTC methods are all param-setting methods that happen to be stored in LTC0-LTC3 memories internally
09:23mwk: I'm starting some docs about that madness at http://envytools.readthedocs.io/en/latest/hw/graph/xf.html
09:30Terkal: I there, I come back w/ a mangaro (arch based os) but i'm still getting issues with my hdmi port
11:00pmoreau: mwk: Ah, ok. I had a quick look at the documentation, and it looks like a lot of fun! :-D
11:02pmoreau: karolherbst: https://nouveau.pmoreau.org/ They are finally back (until it breaks again). I'll see whether I can get DRI3 + bumblebee before leaving for SIGGRAPH.
12:01karolherbst: pmoreau: nice
20:25ryan_: how do I get some help troubleshooting problems with the nouveaus driver?
20:25imirkin_: ask and ye shall receive
20:30ryan_: Put simply, on an old Dell workstation laptop, after installing my favorite flavor of GNU/Linux I begin to have all sorts of problems with the screen within a day or two.
20:30imirkin_: workstation or laptop?
20:31imirkin_: (workstation implies desktop... laptop implies laptop...)
20:31imirkin_: what GPU is inside?
20:31imirkin_: and what kinds of problems with the screen?
20:35ryan_: It's a Dell Precision m65 laptop, which has a Quadro FX350 card. It's an old unit, but otherwise works just fine.
20:36ryan_: My gut feeling is that the nouveau driver should be able to handle the simple demands of such a machine.
20:39ryan_: In short, the normal functioning of the screen deteriorates. It loses the ability to display anything in text mode. It begins to lose the ability to change into graphics mode. In time, anything which gets displayed becomes blurry.
20:41imirkin_: and screen == LVDS screen built into the laptop?
20:41ryan_: What's the question about the screen?
20:44ryan_: It's an LCD screen.
20:45ryan_: On two different units I have seen the same outcome.
20:53imirkin_: ryan_: right, i see. it's a G72, which is indeed quite old. did this work before?
20:53imirkin_: [with nouveau]
20:56karolherbst: imirkin_: ever looked into that approx flag on certain instructions?
20:56karolherbst: or is it software only?
20:56mwk: karolherbst: sw only
20:57ryan_: Originally the units were running MS Windows. Then I wiped the hard drives and installed GNU/Linux. I forget the timeline of failure for the first one, but for the second the screen deteriorated in less than two days. It went from displaying the Dell logo while booting into BIOS to remaining entirely black until the OS kicked into graphics mode.
20:58imirkin_: karolherbst: "that approx flag"?
20:58karolherbst: imirkin_: from the cuda docs
20:58imirkin_: karolherbst: link?
20:58karolherbst: "ex2.approx.ftz.f32 xa, a;"
20:58karolherbst: as one example
20:58karolherbst: there are more
20:58karolherbst: usually SFU instructions
20:58imirkin_: karolherbst: i wonder if that skips the preex2 normalization
20:59karolherbst: no clue
20:59mwk: that wouldn't be "approximate", that just wouldn't work
20:59karolherbst: mwk said it's wo only
20:59imirkin_: mwk: ok, so ... what is it?
20:59mwk: preex2 converts the thing to a different, fixed-point format
20:59mwk: approx? IIRC that flag does nothing
21:00mwk: on most insns
21:00mwk: for rcp, there was some way to select a better one
21:00mwk: which involved a round of Newton-Rhapson
21:00imirkin_: that stuff. ok yeah
21:01imirkin_: ryan_: ok, well if the screen is messed up while the bios is booting, then you're in trouble. try powering the thing off completely and see if that helps any.
21:02imirkin_: ryan_: unfortunately i'm not extremely familiar with nv4x laptop issues. you could file a bug with your findings, although not sure anyone will really be able to help unless it sounds familiar to another issue that was already diagnosed.
21:02imirkin_: feels like the lvds clock is getting messed up or something, but i dunno
21:02ryan_: What am I supposed to do?
21:03imirkin_: i thought i covered that...
21:04ryan_: Would the nouveau driver actually damage the screen in such a way?
21:04imirkin_: it's quite unlikely that the screen is actually damaged
21:04imirkin_: but the GPU could be in an unfortunate state that the BIOS/warm reset doesn't fully get rid of
21:04imirkin_: however with sufficiently bad clock twiddling, i suppose a screen could get messed up... i've never heard of such an example though.
21:05ryan_: By "damage the screen" I meant, what would the software do to put it into such a state?
21:06imirkin_: well, to drive a screen you have to use timings. these are provided by the vbios. if nouveau reads those in sufficiently wrong, then it would program them in wrong as well.
21:06ryan_: Is there anything I can do on my end to fix it?
21:06imirkin_: <imirkin_> ryan_: ok, well if the screen is messed up while the bios is booting, then you're in trouble. try powering the thing off completely and see if that helps any.
21:07ryan_: That has not worked.
21:08imirkin_: you removed the battery and all?
21:10ryan_: The screen remains black. Is there a way to pass an option to the kernel or something like that?
21:12imirkin_: ok so the current state is that the screen is black throughout the boot process
21:12imirkin_: but then once nouveau loads it comes up?
21:15ryan_: Yes. When the kernel boots in text mode the screen remains black. Once it switches to graphics mode it comes alive. However, even then sometimes it does not come alive. Also, I lose the ability to fine-tune the brightness. It is either extremely bright or very dark, which makes it hard to look at the screen.
21:19karolherbst: intersting, just by moving the pow lowering into legalizeSSA: "total instructions in shared programs : 4680880 -> 4685522 (0.10%)", pretty big impact
21:20imirkin_: karolherbst: yeah, as expected... you no longer const-fold the imm^power case
21:20karolherbst: yeah, I am aware
21:21imirkin_: karolherbst: a fairer comparison would be to implement the const folding for imm^power
21:24karolherbst: just do a run without opting the pow(2, a) case, cause I forgot about it when writing the new code
21:24karolherbst: and the case with two immediates is also missing
21:26imirkin_: ryan_: sorry, unfortunately i don't have any great advice for you. i have very little experience with such issues. try filing a bug on bugs.freedesktop.org (xorg -> Driver/nouveau) and see if anyone gets any ideas.
21:26imirkin_: ryan_: also make sure to include a full boot log, as that could prove informative
21:28ryan_: Okay. I will put my thoughts together and file a formal bug report. For the boot log, what information should I include? the kernel output for nouveau?
21:28imirkin_: ryan_: try pinging skeggsb when he's around ... probably in a few hours.
21:28imirkin_: ryan_: yeah, just 'dmesg'
21:31ryan_: imirkin, thanks for your help. I realize the laptop is old, but after even 10 years it still is quite a machine and it would be a shame to throw it away. ryan
21:31imirkin_: yeah, it's not that it's old, it's just that i have no experience with laptop screen issues.
21:53pmoreau: skeggsb: I just experienced the following (https://hastebin.com/epuwisegaq.pas) when testing drm-tip (as of a few hours ago) on a GK107 in an optimus laptop; not encountered on 4.12.x. I haven't really played around with Nouveau to see if anything had gone wrong otherwise.
21:54pmoreau: skeggsb: What kind of information would help you debug that? I guess I could always bisect it.
21:54karolherbst: I guess a bisect might help :p
21:55pmoreau: It will have to wait after SIGGRAPH then, as I don’t feel like starting a kernel bisect when it is already midnight and I need to wake up early tomorrow. :-)
21:56imirkin_: my guess is a patch that fixes it would be most helpful ;)
21:56karolherbst: *sigh* with most constantFolding opts: "total instructions in shared programs : 4680880 -> 4683127 (0.05%)" :/
21:57pmoreau: imirkin_: ;-D
21:57imirkin_: karolherbst: yeah, i expect it to be a minor loss.
21:57karolherbst: we miss 50% of the opts
21:57imirkin_: because you lose CSE
21:57karolherbst: mhh, most likely
21:58karolherbst: I didn't opt pow(imm0, imm1) yet though, but I can't imagine that it will make much of a difference
21:59karolherbst: maybe we should simply do a second CSE after a lot of opts? dunno if this is generally a good idea
22:48mwk: ... what's the difference between clip, scissor and viewport anyway?
22:48mwk:never quite remembers that
22:49mwk: too many fucking rectangles
22:53ryan_: skeggsb, I chatted with imirkin_ a little while ago. He/she said you are the person to talk to about laptop issues. Is that right? Do you feel like lending a hand?
22:57imirkin: mwk: do you really need the info, or are you just being facetious?
22:57mwk: not right now
22:57mwk: but eventually I'd be quite interested in figuring out which is which
22:58imirkin: hehe ok
22:58mwk: esp. since we probably didn't even keep the naming stable between card gens
22:58imirkin: well the main diff between viewport and scissor is that scissors clip wide points while viewports don't
22:59mwk: well that's reasonable
22:59imirkin: clip as in clip rects?
22:59imirkin: (also viewport is expressed as a transform with a scale/offset, while scissors are expressed as pixels)
22:59mwk: as in whatever methods 0x200/0x204 do on Celsius/Kelvin/Rankine
22:59imirkin: anyways, clip rects are same as scissors, but there's many of them
23:00mwk: it's just called clip
23:00mwk: Tesla+ doesn't have that, but it has something called SCREEN_SCISSOR instead
23:00mwk: which is most likely the same thing
23:00imirkin: right... the whole screen scissor vs scissor thing is a bit odd
23:00imirkin: but it's basically a second scissor to clip at viewport bounds
23:01imirkin: since RT's might have different sizes
23:01mwk: so that's per-RT?
23:01imirkin: it's global - it's the raster size, essentially
23:02imirkin: also scissors clip vertices while viewports don't (in general)
23:02mwk: and what would be the practical effect if I swapped it with the normal scissor?
23:02imirkin: which is relevant for wide points
23:02imirkin: (and wide anything, really)
23:03imirkin: so if you have a point whose center is outside the viewport but that has covered pixels in the viewport, then it will show
23:03imirkin: if you have a point whose center is outside the scissors but that has covered pixels inside, it still won't show
23:03mwk: alright, but that's viewport vs scissor, right?
23:03mwk: what about scissor vs screen scissor?
23:04imirkin: oh. same thing. i suspect one has int coords while the other has uint
23:04mwk: how useful...
23:04mwk: and, fwiw, not on Rankine
23:04imirkin: well, the "screen" scissor is meant to avoid rasterizing pixels outside of the RT's proper area
23:04mwk: all 3 use the exact same coord system
23:05imirkin: while the "regular" scissor is meant for clipping off vertices outside of some area
23:05imirkin: roughly glViewport vs glScissor
23:05imirkin: (surprise surprise)
23:05imirkin: anyways, i haven't researched this intensively, just my general take on things
23:06mwk: maybe I'll figure it out properly some day
23:11imirkin: mwk: also with DX10, you can have arrays of viewports (with a matching scissor), which one to use is specified by each primitive [in the GS]
23:53mangix: anyone know what the pci id section in the driver is for?
23:54imirkin: skeggsb: --^ i've asked myself the same question :)
23:54mangix: i added mine to the database. i can't say there's a difference
23:55imirkin: it's not used for anything
23:56skeggsb: its primary function is to store quirks, but secondarily it was meant to be used to allow displaying a "proper" renderer string or something, nothing too important
23:57imirkin: but it's not practically used for anything right now, right?
23:57skeggsb: a couple of quirks, but that's it
23:58imirkin: oh? i thought we just enabled that gk10x workaround for everything
23:58skeggsb: there's others, tv-related stuff iirc