01:32 flipmess: re ^^
05:20 rhyskidd: imirkin: heard of any post-2015 reports of nouveau lack of support with openfirmware vbios? (e.g. nvidia cards originally from macs)?
05:20 rhyskidd: i can see you touched some of that code then, getting around checksum and offset issues with lacking pcir headers
05:20 imirkin: mmmm ... well i definitely made it work on 4.3 with a nv34 on my g5 ppc
05:21 imirkin: there are unrelated issues on agp nv40's for reasons unknown
05:21 imirkin: i do seem to recall someone came in with issues, but i don't think i was able to identify the specific setup. or i've forgotten if i had.
05:22 imirkin: rhyskidd: is there something specific you're trying to work out?
05:24 rhyskidd: have been helping remote debug problems with a nv34 from a g5 ppc (plugged into an x86 over pci extender)
05:24 rhyskidd: error messages looked similar
05:24 rhyskidd: using a post 4.3 kernel
05:25 imirkin: sounds like the same setup i have
05:25 imirkin: powermac7,3 with an original nv34?
05:25 imirkin: i.e. one with an OF bios?
05:27 rhyskidd: here's the kernel oops, on 4.17.x https://paste.debian.net/1051351/
05:27 rhyskidd: yes, only the card has been removed and plugged into an x86 host
05:29 imirkin: oh wait - you took the nv34 board and plugged it into x86?
05:29 imirkin: bios: version be.2c.08.b5.10
05:29 imirkin: that's a pretty major fail
05:30 rhyskidd: yeh
05:30 imirkin: the OF stuff only works on ppc
05:30 imirkin: if it's the primary board, the option rom will not work at all
05:31 imirkin: since it'll contain an OF image instead of the x86 code
05:31 rhyskidd: so no alternative to reflashing the vbios/eprom?
05:31 imirkin: what's the end goal?
05:32 rhyskidd: ... and thereby neutering the possibility of putting it *back* into the g5
05:32 rhyskidd: option preservation
05:32 rhyskidd: (which may be a futile goal, but what is being worked with for now)
05:32 imirkin: "plugged into an x86 over pci extender"?
05:32 imirkin: it's an agp board
05:32 rhyskidd: sorry, pci --> agp
05:33 imirkin: is it the primary video card of the x86 host?
05:33 rhyskidd: yes
05:34 imirkin: well, the OF blob is not a pure blob
05:34 imirkin: something would have to parse it
05:34 imirkin: normally we let linux take care of it
05:35 imirkin: in order to have it work prior to nouveau loading you'd have to replace the option rom
05:35 imirkin: you can cheat
05:35 imirkin: and override the vbios
05:35 imirkin: but to do that, you need the original
05:35 imirkin: i may have a copy...
05:36 imirkin: nv34/imirkin/ppc-agp/vbios.rom
05:36 imirkin: how convenient.
05:36 imirkin: i wonder what that could be...
05:36 imirkin: anyways, load that with nouveau.config=something (sorry, i forget)
05:36 rhyskidd: great, thanks!
05:36 rhyskidd: will continue testing down that pathway
05:37 imirkin: do you have access to the vbios repository?
05:38 imirkin: nouveau.config=NvBios=path/to/vbios.rom (which will be relative to /lib/firmware or whatnot)
05:38 rhyskidd: yes
05:39 rhyskidd: got it
05:41 imirkin: let me know how it goes
09:00 alloysious: has there been any progress on 1050ti support? booting the latest F29 live images results in hard lockup due to nouveau + 1050ti
10:39 filipdevuan_: hey can somebody help with bumblebee? :)
13:35 filipdevuan_: hey i get this error when optirun ;/ can anybody help [ 56.164354] [ERROR]Cannot access secondary GPU - error: Could not load GPU driver
13:41 RSpliet: I can't help people who leave within 3 minutes of querying...
13:42 RSpliet: filipdevuan_: I can't help you if you keep leaving in 3 minutes. Long answer short: don't use bumblebee in combination with nouveau
13:42 filipdevuan_: sorry i rebooted ;/
13:42 filipdevuan_: im sorry
13:42 RSpliet: The Right Way(tm) is to use PRIME offloading, which is part of the DRM stack. No external tools required
13:43 filipdevuan_: yeah well i installed some packages earlier and it was ok but i installed them in not proper order now i think...
13:43 filipdevuan_: cuz i reinstalled
13:43 RSpliet: This is all part of kernel and wayland/X.org userland support. no packages needed
13:44 RSpliet: Unless of course you want to use NVIDIA's official driver rather than our reverse engineered nouveau work, in which case this is the wrong support channel
13:45 filipdevuan_: well i am not sure which one id like to use but i think id rather use open-source one just wish optirun was running
13:45 filipdevuan_: i have optimus graphics card...
13:45 RSpliet: optirun is obsolete as far as the open source graphics drivers are concerned
13:45 filipdevuan_: when i type lspci | grep VGA i get only intel one
13:46 RSpliet: And what if you type dmesg, and paste the *full* output (so no grepping) into a paste website like hastebin, share the URL here?
13:46 filipdevuan_: ok
13:47 HdkR: RSpliet: Sounds like you were implying that Nvidia has an IRC support channel :P
13:48 RSpliet: HdkR: there is #nvidia . It's not official, but it's a support channel that may or may not give you the desired result of "it works"
13:48 HdkR: Huh
13:49 filipdevuan_: https://paste.debian.net/1051399/
13:51 RSpliet: filipdevuan_: First observation: you're running a 4.9 kernel. When you want to use nouveau, you'll kind of have to keep up to date with upstream kernels as development moves too rapidly. Try and install 4.18 or 4.19
13:52 RSpliet: Second observation: I can't find any line in there mentioning nouveau, which makes me suspect it's either blacklisted (perhaps as a side-effect of once installing the official driver - then uninstalling untidily), or because the module is missing from your kernel.
13:55 filipdevuan_: how do i update kernel in terminal??
13:55 filipdevuan_: im confused
13:55 filipdevuan_: can you run bumblebee using nouveau drivers instead of nvidia?
13:55 RSpliet: Again: Bumblebee is *not* the technology you want to use with nouveau
13:56 filipdevuan_: but if i have optimus graphics card can i use something else??
13:56 RSpliet: "RSpliet: The Right Way(tm) is to use PRIME offloading, which is part of the DRM stack. No external tools required"
13:57 RSpliet: as for updating your kernel: ask your distribution for support. We're nouveau developers, we develop stuff and bring that stuff to an upstream kernel, "mesa" (3D userspace module) and some other components. We don't work on individual distros
13:57 filipdevuan_: yeah i feel like id rather use open-source drivers rather than non-free nvidia
13:57 filipdevuan_: okay cool
13:57 filipdevuan_: well i have to go in a minute can i come back soon, so you're saying that it is possible to use both intel and nvidia optimus using nouveau?
13:58 RSpliet: Yes
13:58 filipdevuan_: ok that's nice :)
13:58 filipdevuan_: okay im gonna come back here as soon as ill be home
13:58 RSpliet: And there should not be a need for extra tools to support that, although it requires a fairly modern distribution
13:58 filipdevuan_: yeah i have non systemd debian 9 stretch fork
13:59 filipdevuan_: but maybe there is any specific open source distro that you would recommend for this technology and nouveau
14:00 filipdevuan_: oh im not going anywhere now
14:00 filipdevuan_: okay ill try to update kernel first then
14:01 RSpliet: filipdevuan_: If you oppose the use of systemd your options are slim. I've succesfully used all this stuff on Fedora, I think Ubuntu 18.10 should be up-to-date enough to make this work too. My memory doesn't go back far enough to make any claims about Debian 9
14:02 filipdevuan_: so maybe i should install linux mint for this??
14:02 orbea: slackware is a stable distro without systemd (just saying)
14:02 filipdevuan_: i have fedora 28 on cd
14:03 filipdevuan_: oh ok
14:04 filipdevuan_: ok im updating the kernel
14:07 RSpliet: orbea: The last release of slackware (14.2) is even more outdated than Debian 9. I don't know what their update policy is...
14:07 filipdevuan_: ok im gonna reboot
14:09 orbea: Its trviial to update the kernel
14:10 orbea: but yet, 14.2 is a bit dated now. Current is not
14:11 orbea: *yes
14:12 filipdevuan_: well i use devuan distro now typed some command updated some image and optirun is okay now
14:13 orbea: :)
14:13 orbea: w/e works
16:17 RSpliet: predicated branching on (pre-?)Kepler is interesting. Weird, but interesting.
16:18 RSpliet: Like... $p0 bra 0x80 seems to push the address 0x80 plus (active lane mask AND $p0) onto the stack, unless $p0 is zero.
16:19 imirkin: makes sense ... since there'd be nothign to pop it
16:19 RSpliet: imirkin: For loops, this is how they break out when all threads are done
16:20 imirkin: it has no concept of loops though...
16:20 RSpliet: There's a join straight after that "backwards branch", which if at least one lane must be active will pop the start of the loop off, if not, it will pop the "joinat" address and the initial mask
16:21 imirkin: branches have to work irrespective of joinat
16:22 RSpliet: Sure, but predicated branches do "push target plus predicate onto stack, continue execution with "Predicate XOR active lane mask" as my new active lane mask
16:37 imirkin: karolherbst: friendly ping on my most recent 3 patches - https://patchwork.freedesktop.org/patch/261300/ and https://patchwork.freedesktop.org/patch/261307/ and https://patchwork.freedesktop.org/patch/261314/
16:56 karolherbst: imirkin: first to patches are r-by me, I am a bit wondering about the last one, especially the limiting to 254 regs part
16:57 imirkin: oh, well that's a long-standing issue... iirc i fixed it before, but something weird happened as a result, and i decided it was better to limp along
16:58 imirkin: basically r127 is reserved for zero
16:58 imirkin: check what nvc0+ targets do - they also return 63/255 regs
16:58 imirkin: except on nv50, r127 is not hard-coded to zero
16:58 karolherbst: right
16:58 imirkin: so you can write a value to it
16:58 karolherbst: ohhhh
16:59 karolherbst: nasty
16:59 imirkin: and in fact we prefer to use r63 for smaller programs
16:59 imirkin: so that we can use the shorter encodings
16:59 imirkin: > 63 regs requires 8-byte encodings
16:59 karolherbst: but how does that work regarding gprs count?
16:59 imirkin: any gpr used over the count is zero
16:59 karolherbst: I see
16:59 imirkin: so we could use any reg
17:00 imirkin: but ... easier to read if it's fixed ones
17:00 karolherbst: so we say there are 63 regs and the 64th one becomes 0 automatically
17:00 imirkin: right. 64th one being $r63 :)
17:00 karolherbst: but don't we get any errors for doing sometihng like that?
17:00 imirkin: nope
17:00 karolherbst: and nvidia does the same?
17:00 imirkin: dunno. i assume so.
17:00 karolherbst: mhh
17:00 imirkin: been a while since i've looked
17:00 imirkin: either way, we've been doing this since the nv50 backend has existed
17:00 imirkin: so it's gotta work at least a little :)
17:01 karolherbst: I could imagine that using const buffer might be good enough as well? but no idea how that plays along with the reg encoding
17:01 karolherbst: probably no short insn then
17:01 imirkin: the whole point of this is to be able to use a short encoding
17:01 imirkin: er, the whole point of r63 is using a short encoding
17:01 imirkin: r127 is by necessity
17:03 karolherbst: mhh, anyway, patch kind of makes sense or I get the rought idea at least. ack-by me
17:03 RSpliet: imirkin: FWIW it looks all right to me. It's been a while since I've played with RA, but the actual bookkeeping part of it wasn't as complex as it seemed. The graph colouring part of it is, but I don't think you really touched that
17:06 imirkin: RSpliet: no. i'm just messing with the order that the "highly constrained" nodes are simplified in.
17:06 imirkin: i think i should send a follow-up patch which adds a few pages of comments
17:07 RSpliet: and messing with the order is a heuristic for making RA more likely to be successful in the presence of 16-bit accesses I presume :-)
17:08 imirkin: well
17:08 imirkin: it's not so much that
17:08 imirkin: normally the coloring algo's job is to color nodes with K colors
17:08 imirkin: however what i'm saying here is that the color of *some* nodes must be between 0..K/2
17:09 RSpliet: Yeah, got that
17:09 imirkin: that's not really what the algo does
17:10 imirkin: the problem is that there's no great way to explain the contraint
17:10 RSpliet: The algo, from the top of my head, uses a heuristic to colour with the minimal number of colours (rather than using a fixed number K as it deems appropriate)
17:10 imirkin: coz it's not a question of degree
17:10 imirkin: it's a question of absolute value
17:11 imirkin: we're not saying that the node's degree must be less than K/2
17:11 imirkin: we're saying that the fixed allocated register value must be less than K/2
17:11 imirkin: and those two things are sadly not the same
17:12 imirkin: right, so the way that heuristic works is it takes the most constrained nodes and simplifies them
17:12 RSpliet: Colouring is done by a heuristic anyway, so there's not really a guarantee that if the degree is less than K, that our algorithm succeeds in finding that allocation. The problem is orthogonal in some sense I'd say
17:12 imirkin: there's a few variations
17:14 RSpliet: It picks the first available reg (using the assign() helper). If you process the fp16 ones first, it's more likely they'll end up on the low end of the register spectrum. Sadly, that would mean that for 64- and 128-bit assignments there could be increased fragmentation.
17:16 imirkin: not fp16 btw ... just low-reg vs all-reg
17:16 imirkin: all 16-bit accesses (like for mul) must use low reg-halves too
17:17 RSpliet: Really? I kind of presumed that the "first 63" limit was a side-effect of needing a bit to select between low and high :-)
17:17 RSpliet: But point taken
17:17 imirkin: RSpliet: well, the order that things are processed is in stack order
17:18 imirkin: so we first process the unconstrained nodes, then the unconstrained 64/96/128-bit nodes, then the constrained nodes
17:18 imirkin: and by process i mean "put them onto the stack"
17:18 imirkin: so then registers are allocated in an order inverse of that
17:18 imirkin: constrained nodes were always put onto the stack last
17:19 imirkin: karolherbst: thanks for taking a look btw
17:20 RSpliet: That rings a bell. I think that was useful when I played with that conversion to MAD on NV50... as src2 had to be the same as dst
17:20 RSpliet: Although... that was too long, I might be talking out of my youknowwhat
17:21 RSpliet: *long ago
17:21 imirkin: no, that's actually right
17:22 imirkin: and the regs had to be < 64 for that to work
17:22 imirkin: but we did that as a post-ra opt
17:22 imirkin: however in some cases, e.g. if there's an immediate embedded, you MUST use short regs
17:22 imirkin: and we do that pre-ra
17:22 imirkin: perhaps we shouldn't
17:22 imirkin: that's another answer here btw
17:22 imirkin: "don't do that"
17:23 imirkin: and just handle inlining as a post-ra thing
17:23 imirkin: and que sera, sera
17:23 RSpliet: For NVC0+ we solve the issue by sticking immediates into a constbuf. non?
17:23 imirkin: no
17:24 RSpliet: Pardon, "could solve"
17:24 imirkin: for nvc0, we solve it by making sure we're not on nv50 :)
17:24 imirkin: nvc0+ has no such crazy restrictions
17:24 imirkin: of course not all ops can take embedded immediates, and more can take constbufs, so there'd be some benefit there
17:24 imirkin: however there's no situation like if you use an immediate, your RA gets more complicated
17:25 imirkin: i suspect the compiler team threatened a revolt
17:25 RSpliet: And in revenge, the hardware team designed NVC0
17:25 imirkin: ;)
17:25 imirkin: and the space-heater even doubled as a GPU
19:51 Xiphoid: Hey, I own a laptop that needs the nouveau.modeset=0 boot parameter to function, is there a way I can help fix this?
19:52 imirkin: what gpu do you have?
20:15 Xiphoid: I have an NVidia 960m (I think)
20:15 Xiphoid: Sorry for the late response, new to the IRC thing
20:19 pmoreau: Xiphoid: You can run `lspci -d 10de:` which should tell you which GPU, and its chipset.
20:22 Xiphoid: 01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev a2)
20:26 pmoreau: GM107 should work fine with Nouveau IIRC. Which issues were you experiencing?
20:27 Xiphoid: It gets the CPU into a soft lockup (22sec)
20:28 Xiphoid: On debian, newest version AFAIK
20:28 Xiphoid: That is, when I don't have the option set to 0
20:31 pmoreau: Do you have logs for those cases? (The output of dmesg for example.) I know there are some issues with suspend/resume, if you are on a laptop with an integrated Intel, you could try booting with nouveau.runpm=0 (It will disable suspending the NVIDIA GPU when not in use, so battery life will be impacted).
20:32 Xiphoid: I do not have logs, how would I retrieve those?
20:38 pmoreau: Xiphoid: If you boot without the nouveau.modeset=0, run `dmesg > some_log_file_name`, which will create the file “some_log_file_name”
20:38 pmoreau: I have to go though; I hope someone else can help.
20:38 Xiphoid: Alright, thanks for your help!
20:39 Xiphoid: Thing is, it never boots when I don't have the nouveau.modeset=0 set.
20:39 pmoreau: Ah... that makes thing harder :-/
20:40 Xiphoid: Looking into it now ^^
20:40 Xiphoid: The joys of Linux
20:58 Xiphoid: If anyone can help me, I managed to get my hands on the logs for a failed run.