02:05 mangix: just updated fedora to 4.11. latest kernel is crashing. pretty soon i won't have 4.10 as a backup. this is worrying
02:07 mangix: WARNING: CPU: 0 PID: 347 at drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1499 gf100_gr_init_ctxctl+0x84a/0xa10 [nouveau]
02:22 mangix: bug posted: https://bugzilla.redhat.com/attachment.cgi?id=1287872
02:42 imirkin: hm, that's new. iirc there were some updates to all that logic in 4.11...
02:43 skeggsb: aaand unfortunately we have no (known?) nvidia employee to deal with such black-box issues anymore :/
02:43 imirkin: probably have to bisect
02:43 imirkin: at least it's not the GTX 970 with 4GB VRAM issue
02:44 skeggsb: that'd be preferable, i'd think
02:45 imirkin: since you solved that one? :)
02:55 mangix: i take it gf100 refers to fermi
02:55 mangix: wonder why
02:55 skeggsb: shared code...
02:55 mangix: ah
02:56 mangix: hopefully i can get dnf not to remove 4.10...
02:57 skeggsb: if you could bisect between 4.10 and 4.11, that would be really useful to figure out wtf happened
02:58 skeggsb: i don't see this issue here, i (primarily) use a gm20x gpu in my test machine
02:58 mangix:has unfortunately never done that before.
03:17 mangix: TBH I bet even nvidia does not have a GPU like this
03:17 mangix: it's not a reference design
04:27 CRCinAU: So I'm wondering.... with a 1060 on xorg-x11-drv-nouveau-1.0.15-1.fc26.x86_64 with kernel 4.11, what would I expect with nouveau vs the binary nvidia driver?
04:27 CRCinAU: Initially, I couldn't even get a display with my 1060, but I assume things may have improved slightly since then?
05:00 moongazer: Hi
05:01 moongazer: nvapeek 0 gives me this output: 00000000: 1171c0a2
05:01 moongazer: Why am I not getting the card name?
06:36 moongazer: imirkin, you there?
06:36 moongazer: imirkin, I am reading the card and gpu schematics right now, am I on the right path?
07:11 koz_: karolherbst: I'm having this weird thing which I think might be card-related. When I run at maximum everything (boost 2 and highest pstate), many games cause spontaneous computer shutdown. If I turn down the settings, said games run a bit longer before this happens. Is this a possible thing when using nouveau, or should I look elsewhere?
07:33 pmoreau_: moongazer: `nvapeek 0` will only read some kind of 32-bit register on the card, and not do any interpretation of the data it read.
07:33 moongazer: koz_, Try using the blob driver and see if it happens again! That way you know.
07:34 moongazer: pmoreau_, ah ok. I am reading the envytools documentation and trying to find my GPU id. How do I do that
07:34 pmoreau_: moongazer: If you want to interpret the data, run `lookup $addr_of_the_register $data_in_that_register`
07:34 pmoreau_: So here, `lookup 0 1171c0a2`
07:35 moongazer: pmoreau_, also does nvapeek need to be sudi
07:35 moongazer: *sudo?
07:35 pmoreau_: It needs to be run as root
07:35 moongazer: Okay
07:36 moongazer: nvapeek lookup 0 1171c0a2 no output pmoreau_
07:36 pmoreau_: To interpret other registers, you will need to specify which architecture you want to resolve a register to using the option `-a $arch`. Because, for example, register at address 0x20 could mean one thing on a G96, and another on GP107.
07:36 pmoreau_: It is just `lookup 0 1171c0a2`, no `nvapeek`
07:37 moongazer: If I use -a, then it won't say I don't know which chipset to use, right?
07:38 pmoreau_: If you want to run both at once, you could write a script that did `value=`nvapeek ${address}`; lookup ${address} ${value}`
07:38 pmoreau_: Right
07:38 pmoreau_: Though, for 0, I don't think it changed over generations.
07:41 moongazer: pmoreau_, What's with the zero
07:42 koz_: moongazer: I'm probably gonna try that.
07:43 moongazer: pmoreau, I used -a NV117 but it yielded nothing. And why has Nouveau changed the notation instead of using the original one?
07:43 pmoreau: I mean, register at address 0 has kept the same format over the different generations, so even if you do not specify the architecture, it should still be fine.
07:44 pmoreau: koz_: Do you have any errors in dmesg when the computer shuts down?
07:44 moongazer: pmoreau, PMC.ID => { STEPPING = 0xa | DEVICE_ID = 0x31 | CHIPSET = NV11 | FOUNDRY = TSMC | 0x40c00 }
07:44 moongazer: pmoreau, So my GPU ID is '0x31'
07:44 pmoreau: This seems weird -> NV11
07:44 pmoreau: Maybe they did change it :-D
07:46 moongazer: pmoreau, What are you saying?!
07:46 pmoreau: I am saying that I was mistaken, and the format of that register changed across generations
07:47 moongazer: ...
07:47 moongazer: What do I do now
07:47 karolherbst: koz_: what the temperature
07:47 karolherbst: koz_: *watch
07:48 pmoreau: What does `lookup -a NV117 0 1171c0a2` says?
07:48 karolherbst: moongazer: where did you buy your GPU?
07:49 koz_: karolherbst: Using what?
07:49 moongazer: pmoreau, lookup -a NV117 0 1171c0a2 says that Variant NV117 doesn't exist in enum chipset!
07:49 karolherbst: koz_: sensors for example
07:49 moongazer: karolherbst, from a local shop
07:50 karolherbst: moongazer: without the NV
07:50 moongazer: karolherbst, PMC.ID => { STEPPING = 0xa2 | DEVICE_ID = 0x1c | CHIPSET = GM107 | FOUNDRY = TSMC }
07:50 moongazer: pmoreau, PMC.ID => { STEPPING = 0xa2 | DEVICE_ID = 0x1c | CHIPSET = GM107 | FOUNDRY = TSMC }
07:50 pmoreau: Yeah, better
07:51 pmoreau: karolherbst: Lies, I am saying! https://github.com/envytools/envytools/blob/master/rnn/lookup.c#L39
07:51 karolherbst: pmoreau: :O
07:51 pmoreau: Will send a PR when I get home
07:52 pmoreau: karolherbst: But yeah, looking at the code, you are absolutely right :-) https://github.com/envytools/envytools/blob/master/rnn/lookup.c#L81
07:57 moongazer: Guys look here https://github.com/envytools/envytools/blob/master/rnn/lookup.c
07:57 moongazer: Lol what
07:57 moongazer: You already did it
07:58 moongazer: pmoreau, karolherbst Anyway what is the 'gpu id' now?
07:58 pmoreau: What do you want it for?
07:59 pmoreau: And what do you mean by "GPU Id"?
08:00 moongazer: pmoreau, https://envytools.readthedocs.io/en/latest/hw/gpu.html
08:00 moongazer: pmoreau, I am trying to gain knowledge so that I can write a device driver for a GM107 card for video decoding
08:01 pmoreau: Ah, so I guess the GPU Id would be 0x117 for your card
08:01 moongazer: Lol
08:02 moongazer: It's an 8 bit number, they say
08:03 pmoreau: Did you click on the link? "You can get the GPU id of a card by reading from its [PMC area](https://envytools.readthedocs.io/en/latest/hw/bus/pmc.html#pmc-id)."
08:05 moongazer: pmoreau, I couldn't understand it
08:06 pmoreau: You have the tables with the IDs and various other information here: https://envytools.readthedocs.io/en/latest/hw/gpu.html#fermi-kepler-maxwell-pascal-family
08:08 moongazer: pmoreau, that is fine. What I am asking is; how do I extract it using some command on the computer
08:10 moongazer: pmoreau, you there?
08:10 pmoreau: `nvapeek 0`, and if you don't want to extract manually bits 20 to 27 from the result of nvapeek, run lookup. Then, you do a reverse mapping of the CHIPSET value (GM107) to the GPU ID using https://nouveau.freedesktop.org/wiki/CodeNames/
08:12 pmoreau: moongazer: Yes, I am there, but 1) it takes a bit of time to write, 2) I am at work (which is not related in anyway to Nouveau development), so I tend to prioritise that over answering on IRC
08:12 moongazer: pmoreau, oh sorry
08:14 pmoreau: moongazer: You can still ask questions here, but do not expect necessarily an instantaneous answer. When we have time, we will answer you.
08:15 moongazer: pmoreau, 1171c0a2 so this at address 0. and 117 was the id. 1c AND a2 were mentioned as stepping and device_id
08:15 moongazer: What's with the zero in between
08:16 pmoreau: Btw, https://github.com/envytools/envytools/blob/master/rnndb contains all the data, in an XML format, lookup is using to interpret what you give it
08:17 pmoreau: If you look at https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml#L41m you will see the different **known** fields for that address.
08:17 moongazer: You people figured all this out by reverse engineering? That's crayzy
08:17 moongazer: *crazy
08:18 pmoreau: They did not start entirely from scratch, as NVIDIA had an open-source driver for early models (maybe pre-Tesla?), though it did not have accelerated 3D support.
08:18 pmoreau: But most of it was RE
08:19 moongazer: I see
08:20 moongazer: pmoreau, is there documentation for nvapeek, I can't find it
08:21 pmoreau: https://github.com/envytools/envytools/blob/master/nva/README
08:23 moongazer: How is reverse engineering legal?
08:24 karolherbst: moongazer: because it usually is
08:24 pmoreau: I don't think it is legal in all countries
08:25 karolherbst: pmoreau: it always depends
08:27 karolherbst: pmoreau: like in the EU decompilation is forbidden for commercial usage
08:28 pmoreau: But not for private usage?
08:28 karolherbst: of course not
08:28 karolherbst: not even patents can protect against private usage
08:29 pmoreau: And what about non-commercial and non-private usage, like Nouveau?
08:29 karolherbst: it only starts to become a problem if you ship binaries (for patents) and if you just violate copyright (add decompiled code into your binary)
08:30 karolherbst: pmoreau: commercial is usage is for example if you have a method to replace commercial software of another company you are in competition to
08:31 karolherbst: and in such a case reverse engineering is only allowed if there is no other way to get compatibility to the software of that other company
08:32 pmoreau: Ok
08:32 karolherbst: and if you use decompiled code, you need to do a clean-room reimplamantation
08:32 karolherbst: *reimplementation
08:33 karolherbst: but this is only important if you sell your software. RE doesn't violate copyright for example in the EU
08:33 karolherbst: except you just post the decompiled stuff, then you do
08:36 karolherbst: pmoreau: https://lwn.net/Articles/134642/
08:36 karolherbst: "In the European Union, reverse engineering is allowed under Article 6 of the European Software Directive, for interoperability purposes only, not for creating a competing program, and the law strictly limits what you can do with the knowledge you gain. "
08:37 pmoreau: karolherbst: Thanks for the link, I'll read it later. :-)
08:37 karolherbst: and this "there is no other way" excemption is for stuff like the original company doesn'T respond anymore and stuff like this
08:38 karolherbst: but I think there was a new law since 2005
08:38 karolherbst: or so
08:39 pmoreau: Yeah, I was wondering the same thing, whether it changed since then
08:39 karolherbst: moongazer: our advantage is, that we don't reverse enginer nvidia software, but the hardware interfaces
08:40 karolherbst: moongazer: and this is allowed
08:41 karolherbst: and nouveau isn't commercial, so we are allowed to use the information we've got
08:41 karolherbst: but you aren't allowed to write commercial software with that and sell it
08:41 karolherbst: or build nvidia like GPUs
09:25 moongazer: karolherbst, building nvidia like GPUs would be insane
09:27 moongazer: I am having difficulties compiling nouveau in standalone mode. I read the procedure but couldn't understand it
09:40 koz_: karolherbst: Is the sensors temperature reading for my card reliable?
09:40 koz_: It's showing 61C
09:40 mupuf: koz_: what generation?
09:40 mupuf: if it is newer than G80, then yes
09:40 mupuf: if it is before, it may be wrong
09:40 mupuf: but I doubt it
09:41 moongazer: I am trying to do this: Maxwell Accelerated Video Decoding, here: https://www.x.org/wiki/SummerOfCodeIdeas/ . Currently, I am reading up on the NVidia card and GPU Schematics, also reading up on envytools. What parts should I study to get the relevant info?
09:41 koz_: mupuf: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) according to lspci
09:45 koz_: OK, the random poweroffs I'm getting from games aren't due to temperature.
09:45 koz_: There was a rise, but it was tiny.
09:46 mupuf: moongazer: Hey, welcome!
09:46 moongazer: mupuf, lol what
09:46 moongazer: mupuf, hi
09:46 mupuf: looks like a cool project to do
09:46 mupuf: so, envytools is definitely a good resource to start with
09:47 mupuf: I would say that you really need to understand how command submission works
09:47 mupuf: then how to use valgrind-mmt
09:47 moongazer: Okay wait wait
09:47 mupuf: then understand the mesa code for video decoding (it will show you part of this)
09:47 moongazer: 1. Don't I need to understand the GPU Schematics first
09:48 mupuf: well, you probably do
09:48 moongazer: I need something for that
09:48 moongazer: The page on envytools is confusing for me
09:49 moongazer: mupuf, https://envytools.readthedocs.io/en/latest/hw/intro.html#gpu-schematic-nv3-g80
09:49 moongazer: What does 'PFB' mean here?
09:51 mupuf: FB = framebuffer
09:52 mupuf: it basically the part of the gpu that speaks to the VRAM
09:52 mupuf: which actually in the schematic :)
09:52 koz_: OK, gonna test if I get weird poweroffs now on the blob.
09:55 moongazer: mupuf, does the P here just mean programmable
09:55 moongazer: what is going on?
09:56 moongazer: um
09:56 moongazer: gotta disconnect
09:58 moongazer: I am back
09:59 moongazer: mupuf, silly question, a bit rusty on my electronics right now
09:59 mupuf: moongazer: P stands for private
09:59 mupuf: AKA, the registers are not accessible by applications directly
10:00 koz_: mupuf and karolherbst: OK, I can confirm the driver has nothing to do with it.
10:00 koz_: Just tried the same thing with the blob.
10:00 koz_: Exact same result.
10:00 moongazer: mupuf, but in something like PCI it is peripheral
10:11 moongazer: mupuf, What is VID GPIO?
10:25 Zeroman: Hi guys. Sorry to bother you with trivial question - can I expect nouveau to work on Pascal (GP106, GTX 1060 6 Gb)?
10:26 moongazer: Zeroman, You can check if your card is supported here: https://nouveau.freedesktop.org/wiki/FeatureMatrix/
10:26 Zeroman: Because I built Linux 4.12-rc5 and Mesa 17.1.2, and only framebuffer console seems to work, and even there screen is distorted and very crummy
10:27 Zeroman: moongazer, there is no entry for NV130 =)
10:27 moongazer: You can check the ids here: https://envytools.readthedocs.io/en/latest/hw/gpu.html#the-gpu-families
10:27 moongazer: Zeroman, ohh....
10:28 Zeroman: Well, I know at least something about cards and Nouveau, I've been using it from time to time since 2008
10:28 Zeroman: Just got a new card and decided to try it out
10:29 moongazer: Zeroman, ok
10:31 dboyan: Zeroman: Make sure you also have fresh firmware. 3D support is there for pascal, but don't expect it'll work for everyone.
10:31 dboyan: Even if it works, the performance will be poor
10:32 moongazer: Zeroman, or use the blob driver?
10:34 Zeroman: OK, I will update firmware to most recent version available and try again. Now have 20170314, there is 20170519 in portage...
10:35 Zeroman: Well, I'm not really into 3D gaming, so if it just works it's fine with me
10:35 Zeroman: Blob 381.22 works, but free is better, right&
10:35 Zeroman: *?
10:36 dboyan: well, gp106 firmware is added in march 1, so updating firmware might not help
10:37 Zeroman: It seems that most of them just symlinks to gp102 firmware though
10:38 moongazer: Zeroman, which driver to use depends upon practicality and philosophy
10:41 gnarface: in practical terms, if you don't need 3d, the free driver is better in the sense that it parses xorg.conf options more completely and isn't *guaranteed* to sandbag, obsolete and potentially brick your card after 6 generations, which Nvidia at this point has not failed to do once
10:41 Zeroman: I prefer free software. I'm not a hardcore free-or-nothing, but it's just more comfortable to me and I'm okay with some possible shortages if there are any
10:42 gnarface: that said, for 3d gaming the performance hit for running the free driver will be severe in the few cases it even works
10:42 gnarface: (think like, 1/20th or 1/30th of the performance)
10:42 Zeroman: gnarface, and therefore I was using Nouveau on my old 6600, 8400 and GT240
10:43 Zeroman: Performance was... Well, lower than on blob, but acceptable
10:43 gnarface: Zeroman: yea, i got a some cards in that era too. theoretically the "legacy" nvidia driver supports some of them, but upon testing it couldn't compose my multi-desktop setup from xorg.conf rules alone, so i went back to nouveau
10:43 Zeroman: Something like 50 FPS instead of 300 in trigger-rally, for example
10:44 gnarface: oh, that's not so bad actually
10:44 gnarface: i've see worse
10:46 moongazer: configuration straps - a set of resistors used to configure various functions of the card that need to be up before the card is POSTed.
10:46 moongazer: What do we mean by 'POSTed'
10:47 gnarface: moongazer: it refers to the small snippet of text output by the card's bios when powering up the computer from cold-off
10:47 gnarface: moongazer: to "POST" means the hardware itself powered on, booted, and reported to you that it booted
10:48 Zeroman: Power-On Self Test
10:48 gnarface: ah yes, i knew that once, then forgot it...
10:48 gnarface: it can POST a failure too
10:49 gnarface: (though all the nvidia cards i've seen have been really good at just ignoring the bad ram and "going for it"
10:49 gnarface: )
10:49 moongazer: https://envytools.readthedocs.io/en/latest/hw/intro.html#card-schematic
10:50 moongazer: What does VID GPIO mean here near the voltage regulator
10:50 gnarface: no idea but GPIO stands for General Purpose Input Output
10:51 moongazer: gnarface, I know GPIO
10:51 moongazer: wondering what VID is
10:52 gnarface: short for VIDEO?
10:53 gnarface:shrugs
10:53 RSpliet: Voltage ID
10:53 gnarface: hmmm, interesting
10:55 moongazer: RSpliet, thanks
10:55 RSpliet: moongazer: the video BIOS contains a table that explains which GPIO pins on the GPU are mapped to what kind of device
10:56 Zeroman: Updated firmware. No luck though.
10:57 RSpliet: NVIDIA has been so kind to document this table http://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html - our nvbios tool should be capable to parse it from your VBIOS (if you're running nouveau, you can grab a copy from /sys/kernel/debug/dri/0/vbios.bin )
10:57 RSpliet: ^ for self-study reference, I shouldn't be answering questions considering I'm at work ;-)
10:58 moongazer: Thank you
10:58 Zeroman: Kernel seems to start with some generic FB driver (uvesafb or so), then switch to nouveaufb. It keeps running a kouple of moments (half a second or so) with some wrong refresh rate, then screen drops to distorted state
10:59 Zeroman: *couple
11:00 moongazer: RSpliet, where do I get the other GPU Schematic from>
11:00 Zeroman: It's npt what it's not usable (lol), just looks very ugly.
11:01 Zeroman: X seems to start and work nicely, but I can see only garbage at screen. Can switch to VT and back no prob
11:01 Zeroman: So driver kinda works
11:01 mupuf: moongazer: VID = Voltage ID
11:02 mupuf: And GPIO... well, google it up :D
11:02 moongazer: mupuf, thank you
11:02 moongazer: mupuf, I know GPIO
11:02 mupuf: so, these GPIOs are used to talk to the voltage controller
11:02 mupuf: in order to select the voltage
11:02 moongazer: mupuf, yep, got it:)
11:02 moongazer: mupuf, I am confused with all the Ps in the GPU Schematic
11:03 moongazer: mupuf, they seem to have different fullforms everywhere. Tell me what is what. Sometimes it's PCI, sometimes it's private
11:03 mupuf: It is never PCI
11:04 mupuf: unless you talk about PPCI
11:04 mupuf: just ignore the first P, really
11:05 moongazer: mupuf, what is it?
11:05 moongazer: "PPMI: PCI Memory Interface, handles SYSRAM accesses from other units of the GPU"
11:06 mupuf: well, you need to grep the documentation a little more to figure it out
11:11 moongazer: Ok
11:12 moongazer: mupuf, where do I find the documentation for GF100 onwards?
11:12 pmoreau: Zeroman: Can you paste logs from dmesg and Xorg.0.log please?
11:14 pmoreau: You will need xf86-video-nouveau 1.0.15 for Pascal support, or use modesetting.
11:16 Zeroman: pmoreau, OK
11:17 CRCinAU: ok - so I've just enabled nouveau on Fedora 26....
11:17 CRCinAU: using KDE - so trying to screw with the compositor....
11:18 Zeroman: I already have xf86-video-nouveau 1.0.15, kernel 4.12 from git and Mesa 17.1.2
11:18 CRCinAU: Seems like OpenGL 2 or 3.1 are kinda laggy compared to Xrender :\
11:19 Zeroman: pmoreau, dmesg: https://pastebin.com/YC3kX7E3
11:20 karolherbst: koz_: maybe a firmware issue
11:21 Zeroman: pmoreau, Xorg log: https://pastebin.com/JTyYynRd
11:22 pmoreau: Zeroman: Thanks
11:22 mupuf: moongazer: same place
11:24 moongazer: PTIMER
11:24 pmoreau: Weird: "[ 203.412] (EE) [drm] Failed to open DRM device for (null): -22", but the setup seems to properly continue after that
11:24 moongazer: measures wall time
11:24 moongazer: What is Wall time?
11:24 koz_: karolherbst: Would that still happen under the blob though?
11:24 moongazer: mupuf, no....
11:24 koz_: I tried it using the blob, and it still had the same power off issue.
11:24 pmoreau: moongazer: I guess https://en.wikipedia.org/wiki/Wall-clock_time
11:25 dboyan: moongazer: One piece of advice if you are learning the nouveau docs, you don't need to understand every word in the doc, or you'll soon get overwhelmed.
11:25 dboyan: Modern gpus are complicated beasts, and unfortunately the doc doesn't cover all the aspects, and somewhat outdated in some parts.
11:25 dboyan: Luckily we don't need to be a master of everything to develop nouveau.
11:26 Zeroman: pmoreau: Well, I got it running now.
11:26 pmoreau: Zeroman: Oh, cool! What did you do?
11:26 Zeroman: Just disabled all other FB drivers in kernel config
11:26 pmoreau: Hum
11:26 Zeroman: Seems to be some sort of conflict with uvesafb or so
11:26 pmoreau: Could you post the updated dmesg and Xorg.log for comparison please?
11:26 Zeroman: OK
11:27 Zeroman: GLX isn't working, because blob is installed, but graphics seems to be OK
11:27 pmoreau: There were some errors in dmesg, related to the display (line 150)
11:29 Zeroman: Xorg: https://pastebin.com/VaJpqGxb
11:30 moongazer: dboyan, We don't need to be a master to develop nouveau!! Yay! Thanks for that
11:30 moongazer: What is PRAMDAC and PME?
11:31 moongazer: Maybe I got to read all the pages in detail
11:31 Zeroman: dmesg: https://pastebin.com/Dkgk67zA
11:32 Zeroman: PRAMDAC seems to be Private RAMDAC, if I was to guess
11:32 pmoreau: moongazer: You can use the search fonction for envytools: https://envytools.readthedocs.io/en/latest/search.html?q=PRAMDAC&check_keywords=yes&area=default
11:33 moongazer: pmoreau, ok thanks
11:34 pmoreau: It won't tell you everything, but at least give you an idea if it is related to the display engine, or whatever
11:34 imirkin: Zeroman: pascal support is generally there, but reclocking is unlikely to ever happen
11:34 Zeroman: I'm fine with just it running
11:34 pmoreau: Zeroman: The new dmesg does not have the display interrupt from the previous one
11:36 pmoreau: So, uvesafb leaves the card in a way that Nouveau does not like, it seems
11:36 moongazer: pmoreau, but where is the schematic for the cards after GF100?
11:37 pmoreau: For which part?
11:38 karolherbst: moongazer: imho you won't be more ready working on Nouveau if you read all the documentation. My suggestion is that you just read about the things you need to know for the tasks you want to work on and then go from there. You can always read more and everything, but you can also start to work earlier.
11:38 pmoreau: Everything we know should be in https://github.com/envytools/envytools/tree/master/rnndb
11:38 dboyan: imirkin: I'm now implementing the DAG construction logics. My current policy with def-use chains is for each def in a instruction, make an edge to instructions that has the use of that value.
11:38 dboyan: Is it correct, especially for memory? I'm concerned about potential side effects.
11:38 Zeroman: pmoreau: maybe it's not uvesafb, I'm not sure. It's just I don't know another FB drivers besides uvesafb and fbdev
11:39 pmoreau: And https://github.com/envytools/envytools/tree/master/docs/hw also has some nice explanations.
11:39 imirkin: dboyan: have a look at MemoryOpt for how it deals with memory
11:39 imirkin: dboyan: you could treat all memory write operations as compiler barriers for now
11:39 moongazer: karolherbst, I am just gathering initial info so that I have a proper overview of things
11:39 moongazer: karolherbst, isn't that good?
11:40 moongazer: imirkin, schematic for cards\ after GF100?
11:41 moongazer: pmoreau, but to understand what I am doing with envytools I need to know the hardware as well
11:41 karolherbst: moongazer: I didn't talked about things being bad or good, it's just usually not needed
11:41 moongazer: karolherbst, so tell me, what parts should I go for?
11:42 pmoreau: moongazer: The hw folder in envytools/docs, is about hardware ;-)
11:42 karolherbst: moongazer: no clue, depends on what you want to work on
11:42 pmoreau: moongazer: And the rnndb folder contains the formatting of all known "registers" you can use to control the hardware
11:45 moongazer: karolherbst, https://www.x.org/wiki/SummerOfCodeIdeas/ Maxwell Video decoding is the one
11:46 karolherbst: moongazer: I see
11:46 moongazer: That's why I was asking imirkin and pmoreau for the schematic of cards after GF100
11:46 Zeroman: 60 fps in Minecraft. Not bad, not bad
11:46 karolherbst: moongazer: you could checkout how it works for other GPUs, most of the stuff is inside mesa with a few buffer management things on the kernel side
11:47 karolherbst: moongazer: there are no schematics
11:47 moongazer: karolherbst, i am
11:47 pmoreau: Zeroman: You could open a bug report about it, say that disabling the other FB drivers helped, and post the initial dmesg with uvesafb, and the second one without it.
11:47 karolherbst: moongazer: we don't know how the GPUs are built internally
11:47 moongazer: karolherbst, then how were the drivers made
11:47 karolherbst: moongazer: well, they have hardware documentations, we don't
11:47 pmoreau: Zeroman: And point out to lines 150 and 152 to 154 in the initial dmesg
11:48 imirkin: sounds like joss?
11:49 pmoreau: moongazer: By mimicking what the NVIDIA driver reads and writes to the card, and trial-and-error: testing different combinations of bits for a value, see what it does.
11:50 moongazer: pmoreau, that's what I have to do ultimately. What I mean is, 2D and 3D rendering works on all cards(nouveau)
11:50 Zeroman: pmoreau: OK, will do
11:50 moongazer: so that should give us a rough idea of what it looks like on the inside
11:51 pq: imirkin, I think a little bit too coherent so far to be him - also lacking personal insults
11:52 imirkin: fair enough
11:52 karolherbst: moongazer: there are usually papers from nvidia about the general stuff, but this is quite useless overall allthough with some interesting facts
11:54 pmoreau: moongazer: If we know which buttons to press on a black box to make it light a lamp, that does not mean we know what happens inside the black box.
11:54 pq: Zeroman, I wonder if the compatibility list at https://nouveau.freedesktop.org/wiki/KernelModeSetting/ is roughly correct, just came to mind since you mentioned uvesafb
11:54 moongazer: pmoreau, but we can build a model for what that black box looks like
11:54 CRCinAU: so I'm wondering.....
11:55 CRCinAU: is it expected that KDE + OpenGL compositor is slugish?
11:55 CRCinAU: I'm using KDE on F26 with a 1060 (which is kernel 4.11.4 + mesa 17.1.1)
11:55 karolherbst: moongazer: but this may take 5 years
11:56 CRCinAU: also with: xorg-x11-drv-nouveau-1.0.15-1.fc26.x86_64
11:56 pmoreau: moongazer: Yes, I don't know how precise it will be. But some on the channel are doing it for very old hardware (<NV10)
11:56 pmoreau: CRCinAU: You need kernel 4.12 to get hardware acceleration
11:56 CRCinAU: ahhhhhhh
11:57 CRCinAU: I've noticed that XRender is lovely and smooth
11:57 CRCinAU: but.... xrender ;)
11:57 moongazer: karolherbst, arr ok
11:57 pmoreau: CRCinAU: (And the proper firmwares, once you have updated the kernel)
11:57 karolherbst: moongazer: those nvidia GPUs are just like super complicated stuff, so we just focus on the interfaces and how to use the GPU
11:58 CRCinAU: ok - I'll start on the hunt for a 4.12 kernel for F26 :p
11:58 CRCinAU: pmoreau: any hints on the firmware filenames to aid in my quest?
11:58 CRCinAU: or are they in the normal linux-firmware bundles?
11:58 moongazer: karolherbst, I see. Anyway, how do I find a mentor for my project?
11:58 pmoreau: CRCinAU: They are in normal linux-firmware bundle, if it is a recent enough version
11:58 karolherbst: moongazer: ask here
11:59 CRCinAU: pmoreau: thanks... I'm thinking of hijacking a Fedora rawhide kernel to test
11:59 karolherbst: moongazer: but this year is too late for GSoc
11:59 karolherbst: moongazer: so only EVoC remains
11:59 karolherbst: but I don't know the details about the latter
11:59 pmoreau: CRCinAU: Look for a gp106 folder in firmware/nvidia.
12:00 CRCinAU: I have that
12:00 pmoreau: Then you should only need an updated kernel :-)
12:00 CRCinAU: for me: /usr/lib/firmware/nvidia/gp106
12:00 moongazer: karolherbst, Yes, I am talking about EVoC only
12:00 moongazer: karolherbst, I was wondering what to ask
12:01 karolherbst: moongazer: well I would have time for that potentially
12:01 CRCinAU: pmoreau: you know I'm going to break the world now, right? :)
12:01 moongazer: in the first place
12:01 karolherbst: moongazer: mupuf knows more though
12:01 moongazer: karolherbst, so you can be the mentor? Or mupuf ? Oh I see
12:01 pmoreau: CRCinAU: O.O Please spare the Earth, it didn't do anything wrong!! :-D
12:01 karolherbst: well others could as well, it just depends on how much time they have and who wants to do that
12:02 karolherbst: maybe I can't be one for EVoC, no idea
12:02 karolherbst: moongazer: but you could just follow those EVoC instructions and then ask here who would fit best for your proposal or something like this
12:03 karolherbst: moongazer: maybe you also change your mind and wants to do something else later on
12:04 CRCinAU: well, 4.12.0-0.rc5 is installing on Fedora 26....
12:04 CRCinAU: It's a bold move Cotton, lets see how it plays out
12:04 Zeroman: pmoreau: Filed https://bugs.freedesktop.org/show_bug.cgi?id=101447
12:04 Zeroman: Thanks for assistance!
12:07 pmoreau: Zeroman: Thanks! Not sure when someone will have a look at it, but at least it is filed. As pq pointed out, it could be due to uvesafb. Do you think you could try with efifb instead?
12:07 Zeroman: Well, it was enabled too
12:08 CRCinAU: yay, X worked.
12:10 moongazer: karolherbst, What do you mean by "just follow those EVoC instructions"
12:11 CRCinAU: ohhhh
12:11 karolherbst: moongazer: https://www.x.org/wiki/XorgEVoC/
12:11 CRCinAU: its not happy :P
12:11 moongazer: karolherbst, Don't you see, that is exactly what I am doing right now:) I have already read that
12:11 karolherbst: moongazer: yeah, I never read it
12:12 moongazer: uh oh
12:12 CRCinAU: so when I enable opengl mode, I get like a 2 bit rendering.....
12:12 CRCinAU: ie it renders just the blue dots on the screen
12:12 CRCinAU: but I can see the outline of the window I changed the renderer in - as a black box
12:13 CRCinAU: it looks like a blue only 2 bit colour fax lol
12:13 dboyan: hakzsam: I've sent the perfmon fix series with more commit messages and patch 3 which coverted metrics including ipc to float.
12:14 karolherbst: moongazer: well I could be a mentor most likely, I would just need an okay from Xorg side I suppose
12:14 moongazer: karolherbst, thanks...so you find out the information needed maybe..
12:14 karolherbst: moongazer: I'll just ask mupuf and/or robclark :p
12:15 karolherbst: I think rob is the general contact anyway, right?
12:16 moongazer: karolherbst, yes on the page it's written that you have to contact robclark, I also mailed Martin Peres, but I don't think Martin is the mentor for this
12:16 karolherbst: moongazer: martin == mupuf
12:16 moongazer: karolherbst, Lol
12:16 hakzsam: dboyan: just saw it. btw, you forgot to add marek's Rb on patch 1
12:17 moongazer: I was asking him totally dumb questions an hour ago or something
12:17 dboyan: whoops
12:17 karolherbst: moongazer: tough ;)
12:17 dboyan: hakzsam: do I need to resend that one?
12:17 moongazer: karolherbst, it's good it can be you or him....I have to study this stuff more
12:17 hakzsam: dboyan: nope
12:17 hakzsam: not a big deal
12:18 moongazer: karolherbst, better than yesterday when I knew absolutely nothing and was asking imirkin totally dumb questions
12:18 CRCinAU: ok - got some crash messages :\
12:19 CRCinAU: kernel: nouveau 0000:03:00.0: fifo: read fault at 0000011000 engine 06 [HOST0] client 06 [GPC0/L1_2] reason 02 [PTE] on channel 15 [017f42a000 Xorg[978]]
12:19 CRCinAU: that one was a system hang
12:20 CRCinAU: https://paste.fedoraproject.org/paste/ug3IFhZHxsql1jwCTdhh-w
12:20 Zeroman: pmoreau: Enabled EFIFB, no result and no traces of it in dmesg. Maybe Nouveau got picked first by kernel.
12:20 CRCinAU: that one is where the display went all spastic.
12:21 CRCinAU: ie:
12:21 CRCinAU: kernel: WARNING: CPU: 1 PID: 984 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x6e/0x80 [nouveau]
12:21 hakzsam: dboyan: what blob returns for those metrics? floats?
12:22 vpelletier: hi. I have an NV40 on a powerpc g5, with debian sid. nouveau works well on tty, but does not like starting X: black screen for several seconds, c
12:22 vpelletier: gah
12:22 vpelletier: chvt 1 does not work, ssh works fine, loadavg between 1 and 2
12:23 vpelletier: shuting down or rebooting from ssh works after several minutes
12:23 pmoreau: vpelletier: What do you have in Xorg.0.log and dmesg after starting to start X?
12:23 dboyan: hakzsam: I haven't used blob's tool myself, but from what I see on google, they are at least floats
12:24 pmoreau: Zeroman: Mmm, maybe? Or you do not boot in EFI mode? You could try another of the supported FB by Nouveau if you want.
12:25 pmoreau: CRCinAU: Do you have a full log for it?
12:25 dboyan: I don't think ipc fits into percentage because it can exceed 1 theoratically
12:25 hakzsam: dboyan: that makes sense for ipc at least
12:25 CRCinAU: pmoreau: which one?
12:25 pmoreau: dmesg, when you get that WARNING, and/or the system hang
12:26 pmoreau: s/starting to start/starting
12:26 CRCinAU: the system hang was instadeath - so I got nothing... that was the fifo read fault.
12:27 CRCinAU: ie that's part of the last thing it wrote to the journal before --- Reboot ---
12:27 CRCinAU: the paste.fedora has the full warning message
12:27 Zeroman: pmoreau
12:27 Zeroman: pmoreau
12:27 Zeroman: pmoreau: Maybe you are right - motherboard does support EFI (UEFI), but I prefer to use old classic MBR-style boot. It's much simpler to set up
12:27 moongazer: karolherbst, could you help me with building nouveau
12:27 pmoreau: If you have journald, you can retrieve the logs using `journalctl -b -1` for the previous boot log
12:27 Zeroman: Damn, sorry
12:28 CRCinAU: I'm just going to upgrade the linux-firmware package to match the kernel - just in case its a different firmware blob or something dumb.....
12:28 CRCinAU: then at least the kernel / firmware are from the same system.... brb
12:28 hakzsam: dboyan: looks good
12:29 dboyan: thanks
12:32 moongazer: pmoreau, I am having trouble compiling nouveau
12:33 CRCinAU: hrrrm - hard hang again
12:33 pmoreau: Which "version" of Nouveau are you trying to compile: the out-of-tree module, or the whole kernel?
12:33 pmoreau: CRCinAU: See if you can retrieve the logs using journald, if you have it.
12:34 CRCinAU: oooo - ethernet is still alive
12:34 moongazer: pmoreau, out of the tree sample directory
12:34 moongazer: *directly
12:34 CRCinAU: ahhh crap
12:34 CRCinAU: no sshd running LOL
12:34 moongazer: It says that some linux/..., file is missing
12:34 pmoreau: CRCinAU: Or, if you have another computer, try to ssh in before it hangs, and see if you can grab some logs when it happens.
12:34 pmoreau: Too bad :-D
12:34 CRCinAU: pmoreau: yeah - that's what I'm thinking.....
12:35 moongazer: Which is ofcourse not there, since I don't have the linux repo..
12:35 karolherbst: moongazer: full output pasted on a paste site like pastebin or something else
12:35 vpelletier: pmoreau: syslog with nouveau.debug=trace: https://pastebin.com/TXsZtbGd
12:36 pmoreau: moongazer: Ok, so you will need to first clone the Linux kernel from here: https://cgit.freedesktop.org/~airlied/linux/?h=drm-next , branch drm-next
12:36 moongazer: karolherbst, https://paste.ofcode.org/NMaWNUJxVDjJ3PGn9XtdTs
12:36 vpelletier: pmoreau: and Xorg.0.log of same session: https://pastebin.com/VWwEATKv
12:36 moongazer: pmoreau, I have cloned the kernel from https://github.com/skeggsb/nouveau.git
12:36 moongazer: pmoreau, is that not ok?
12:36 karolherbst: moongazer: okay, here is the deal: you need the right kernel
12:37 karolherbst: moongazer: what kernel are you on?
12:37 pmoreau: vpelletier: Thank you
12:37 pmoreau: moongazer: The out-of-tree module, is out of tree. But it still needs a regular kernel to compile against, which is what I linked you to.
12:38 vpelletier: pmoreau: this ppc is in big-endian mode, BTW, and it is actually the reason I'm using it (...or trying to), to test portability
12:38 CRCinAU: yay I'm in.
12:38 CRCinAU: ok - time to hang it
12:39 moongazer: pmoreau, karolherbst 4.4.0-79-generic
12:39 CRCinAU: ohhh - there we go
12:40 CRCinAU: kernel: nouveau 0000:03:00.0: fifo: read fault at 0010000000 engine 15 [CE0] client 01 [GPC0/T1_0] reason 02 [PTE] on channel 2 [017fb82000 Xorg[993]]
12:40 pmoreau: vpelletier: I think there are still some open issues with BE, not sure which ones though
12:40 karolherbst: moongazer: that's way too old
12:40 CRCinAU: kernel: nouveau 0000:03:00.0: fifo: channel 2: killed
12:40 CRCinAU: kernel: nouveau 0000:03:00.0: fifo: runlist 0: scheduled for recovery
12:40 moongazer: karolherbst, what I gotta do
12:40 moongazer: Wait a sec
12:40 CRCinAU: kernel: nouveau 0000:03:00.0: fifo: engine 7: scheduled for recovery
12:40 karolherbst: moongazer: upgrade your kernel to something not ancient like 4.11
12:40 CRCinAU: kernel: nouveau 0000:03:00.0: Xorg[993]: channel 2 killed!
12:40 CRCinAU: pmoreau: that's everything in the journal
12:41 CRCinAU: dmesg shows exactly the same
12:41 CRCinAU: nothing further
12:41 moongazer: karolherbst, doing it
12:43 moongazer: karolherbst, I compiled it last nigh
12:43 moongazer: *night
12:43 CRCinAU: it seems there's still a pid for Xorg
12:43 CRCinAU: but its of status D
12:43 moongazer: Kabouik, but 5 .deb files are there. Which ones do I install?
12:45 moongazer: karolherbst, *
12:45 CRCinAU: pmoreau: if I left it alone long enough, I get a warning again: https://paste.fedoraproject.org/paste/ug3IFhZHxsql1jwCTdhh-w
12:45 CRCinAU: then a 'systemctl restart sddm' eventually gives me graphics back
12:45 pmoreau: vpelletier: Xorg.log looks fine, and dmesg mostly fine, except those ioctls returning -22 (starting line 3468)
12:46 karolherbst: moongazer: I have no idea how to install a kernel deb package, never done it this way. Best is to ask in appropiate channels for distribution support
12:46 karolherbst: moongazer: most just install a kernel and add a grub entry
12:47 pmoreau: vpelletier: imirkin has been looking into improving BE support, he might have an idea. Feel free to open a bug report in the mean time.
12:47 vpelletier: mmh, 22 == EINVAL
12:47 CRCinAU: hahahaha - one mouse click and it all crashed again :)
12:47 vpelletier: pmoreau: ok, thanks
12:49 imirkin_: vpelletier: i can't tell ... are you using 4k or 64k pages?
12:49 pmoreau: vpelletier: After looking at the classes used for those failing ioctls, I think the code is trying to figure out which version of the display (for example) class to use, starting from the newest one. And as it fails, try an older one, and so on until it finds one that match. So those -22 are probably expected.
12:49 CRCinAU: pmoreau: both crashes: https://paste.fedoraproject.org/paste/iRREGh7gDrZRaLfvDC5u8w
12:50 imirkin_: vpelletier: also, to be more precise ... you have a G70 (NV47), not a NV40. The original NV40 also came in some G5 PPCs, the AGP ones (GeForce 6800GT).
12:51 pmoreau: CRCinAU: Could you post the whole log please?
12:51 CRCinAU: the rest is all just normal KDE noise.
12:51 CRCinAU: or you want the whole dmesg?
12:51 pmoreau: Whole dmesg, to get Nouveau initialisation and such
12:52 CRCinAU: pmoreau: https://paste.fedoraproject.org/paste/v~ziklvqHWjXsU70t~eiBQ/
12:52 vpelletier: imirkin_: true, this should be a pci-express model I think
12:53 vpelletier: (still looking for page size)
12:53 imirkin_: i THINK it's 4K pages since: [ 0.000000] Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24
12:53 imirkin_: but ... i don't know ppc kernel boot logs THAT well
12:54 pmoreau: CRCinAU: Thanks
12:56 vpelletier: imirkin_: CONFIG_PPC_4K_PAGES is not set, CONFIG_PPC_64K_PAGES=y
12:56 vpelletier: from /boot/config*, which comes from tyhe debian package
12:56 imirkin_: vpelletier: ok, so that won't work with nouveau
12:56 imirkin_: you need 4K pages
12:56 imirkin_: i also recommend using 4K pages over 64K pages if you plan on using it for normal applications rather than HPC purposes
12:57 moongazer: karolherbst, installing the new kernel now
12:57 vpelletier: imirkin_: noted, I'll build a kernel
12:58 vpelletier: (does not seem to be a 4k flavour in debian sid)
12:58 pmoreau: CRCinAU: You should open a bug report as well, so that Ben can have a look at it when he has time; he is the best to have a look at it, since he was the one who moved Nouveau to atomic modesetting, and does most of the kernel-side work.
13:00 CRCinAU: pmoreau: URL for that?
13:00 CRCinAU: but i think I'll be going back to the binary driver tonight ;)
13:00 CRCinAU: but at least I can bug report it
13:00 vpelletier: imirkin_: also, may I suggest somehow preventing nouveau from building with 64k pages ? or maybe detect it when X start ? (not knowing where to look myself, I have no idea how code will tell...)
13:01 Zeroman: CRCinAU: The other thing you can do is to build vanilla kernel from git
13:01 pmoreau: CRCinAU: https://bugs.freedesktop.org/, product "xorg", component "Driver/nouveau"
13:01 Zeroman: CRCinAU: Because I also have kernel 4.12-rc5, Mesa 7.1.2 and xf86-driver 1.0.15 and all seems to work fine
13:02 Zeroman: *17.1.2
13:02 Zeroman: And same videocard
13:02 CRCinAU: hrrrm
13:02 CRCinAU: I'm on mesa 17.1.1
13:02 Zeroman: Distro kernels usualy HEAVILY patched
13:02 Zeroman: This may be the case
13:03 CRCinAU: Fedora usually isn't too bad
13:03 pmoreau: Do you both have the same version of the X server?
13:03 Zeroman: They also include all possible config options, and this can also be the case
13:03 CRCinAU: Seems even in rawhide, Fedora only has 17.1.1-2
13:04 CRCinAU: xorg-x11-server-Xorg-1.19.3-4.fc26.x86_64
13:05 Zeroman: 1.19.3 also
13:09 CRCinAU: is there anything else I should add: https://bugs.freedesktop.org/show_bug.cgi?id=101448
13:11 pmoreau: Seems fine. You will probably asked to get some logs with additional debug flags, like drm.debug or nouveau.debug, but I do not know which one
13:16 CRCinAU: okies... lemme see if I can get mysystem running again so I can do stuff lol
13:16 CRCinAU: pmoreau: thanks for your help - we'll see what it all turns up
13:31 mupuf: moongazer: no worries, everyone has to start somewhere
13:32 mupuf: karolherbst: I don't see any problem with you being a mentor
13:32 mupuf: no need to ask xorg for permission
13:32 mupuf: I will vouch for you
13:34 karolherbst: mupuf: I already got an okay and added me to the list myself
13:55 vpelletier: imirkin: while kernel is cross-building, pmoreau mentionned there may be some broken things in BE, would you know what ? so that I can keep an eye out
13:57 vpelletier: imirkin: and FWIW, I should not be hitting opengl too hard: I'll be working to get residualvm to work
14:04 dboyan: imirkin: what does the "indirect" mean in memory instructions? Something related to array index?
14:09 dboyan: imirkin: After skimming through MemoryOpt, I think I'd better be conservative on memory operations. I want to preserve the sequence of memory operations, at least stores.
14:10 RSpliet: dboyan: Kepler hardware does not guarantee that stores on one SM are observed in the same order on a different SM
14:11 RSpliet: OpenCL (1.2) couldn't do device-wide memory fences at the time I came across this... just to put expectations in perspective
14:13 dboyan: RSpliet: I'm primarily thinking about single thread, such as two stores writing at the same location, we can't change the order of these.
14:15 RSpliet: dboyan: ah yes... being conservative is probably the best approach right now :-)
14:15 dboyan: yeah, that's kind of classical WAW and RAW problems
14:21 vpelletier: [ 6.235138] nouveau 0000:0a:00.0: DRM: GPU lockup - switching to software fbcon
14:21 vpelletier: this does not look too promising :s
14:22 vpelletier: (still in console only, this time on a fresh 4.11.5 4k pages)
14:23 vpelletier: aaand similar garbage screen in X
14:25 vpelletier: anyway, too late for today, got to sleep
15:26 imirkin_: dboyan_: indirect means an indirect offset into memory
15:26 imirkin_: dboyan_: e.g. memory[reg] instead of memory[imm]
15:26 imirkin_: there can also be a second dimension to most things, which can in turn also have indirection
15:31 pmoreau: So... you could have memory[reg1][reg2]? Or does it have to be memory[imm][reg]?
15:32 pmoreau: (Or memory[imm1][imm2], just the first index has to be an immediate)
15:42 imirkin_: well, not memory... but buffer
15:43 imirkin_: where each buffer has an implied base address
15:43 imirkin_: and you could have buffer[reg][reg]
15:43 imirkin_: where it's an indirect offset into the buffer list, and an indirect offset into the buffer
15:45 imirkin_: dboyan_: there are various hints that can be provided in glsl, like that 2 buffers don't alias. i don't know if those hints are being passed into the tgsi though.
15:45 pmoreau: Ah, ok
15:45 imirkin_: so e.g. a read from one buffer could be reordered with a write to another buffer if that other buffer had a "restrict" qualifier (iirc) on it
15:45 pmoreau: And would that be faster than `tmp = buffer[reg]; tmp[reg]`? Or do you only gain by avoiding tmp, which would be two regs on Fermi+?
15:46 imirkin_: well, that's how it ends up being
15:46 karolherbst: imirkin_: so it seems like that we can't do MAD -> fma by default except the shader tells us it's safe. The part of the CTS where we fail to keep the precision has no precise modifier or anything like it.
15:46 imirkin_: there's a lowering from 2d to 1d indexing
15:46 imirkin_: karolherbst: pastebin shader
15:46 karolherbst: https://gist.github.com/karolherbst/80c0f36c7dbaa059fa357aff17af7c4f
15:46 pmoreau: Oh, I thought you were talking about a hardware function :-D
15:47 karolherbst: imirkin_: all MADs in the TGSI can't be fmas
15:47 imirkin_: pmoreau: no... at the hw level, it's just memory
15:47 imirkin_: not sure when the lowering happens
15:47 imirkin_: ideally after opts, but dunno if it is.
15:48 karolherbst: imirkin_: I think it would be safe for "precision low/medium float;", but highfp seems to be the default
15:48 imirkin_: and what fails?
15:48 karolherbst: imirkin_: the test, CTS says it's wrong
15:48 imirkin_: :p
15:48 imirkin_: which part of it fails
15:48 karolherbst: and if I add the MAD -> MUL/ADD split it passes
15:48 imirkin_: not my question.
15:48 imirkin_: my quesiton is ... why is the test failing.
15:49 imirkin_: what precise condition is it expecting that is not being met
15:49 imirkin_: don't guess.
15:49 imirkin_: know.
15:49 imirkin_: :p
15:49 karolherbst: I only know that if we emit mul+add instead of fmas it passes
15:49 mupuf: Sounds like a moto from Yoda :D
15:49 pmoreau: :-D
15:49 imirkin_: karolherbst: sure, but that's irrelevant.
15:49 imirkin_: karolherbst: read up on "confirmation bias"
15:50 imirkin_: karolherbst: perhaps if you just make mul always return 0 it would work as well
15:50 imirkin_: doesn't mean you should do that
15:50 karolherbst: ohhh, I see
15:51 imirkin_: my personal bet is that "precise out float result" - that precise modifier doesn't make it all the way through.
15:51 imirkin_: but that's based on nothing... i haven't looked carefully.
15:51 karolherbst: there is no precise out
15:51 imirkin_: void eval(in vec4 p, in vec4 w, precise out float result)
15:51 karolherbst: weightedSum isn't tagged with precise at all
15:51 karolherbst: imirkin_: doesn't amtter
15:51 karolherbst: precise only scope is inside the function
15:51 karolherbst: outside it is irrelevant
15:51 imirkin_: although actually that doesn't appear to be the case -- TEMP[7].y gets a "precise" value.
15:51 karolherbst: yeah
15:52 karolherbst: it'S the weightedSum.w part which gets the MADs
15:52 imirkin_: as it should.
15:52 karolherbst: well, why is it wrong then to emits fmas? except the issue is really somewhere else
15:52 imirkin_: so check why the test is failing.
15:53 karolherbst: yes
15:53 imirkin_: without that understanding, we can do nothing but guess.
15:53 karolherbst: that's anyway the last issue I have to track down so that I can consider my series complete, hopefully it's down by the weekend
15:53 imirkin_: from a quick read, that TGSI appears to be an accurate conversion of the input program.
15:53 karolherbst: yeah
15:54 karolherbst: that's also what I think
15:54 imirkin_: could be that there's some unwanted CSE that makes the compilation fail.
15:54 karolherbst: ohhhhh
15:54 karolherbst: that makes sense
15:54 imirkin_: (well, not *fail*, but end up incorrect)
15:54 karolherbst: wait
15:54 karolherbst: the nv50ir output looked... wrong
15:55 imirkin_: which, you might recall, was precisely the scenario i was talking about
15:55 imirkin_: when i said that CSE needs to be aware of this.
15:55 karolherbst: didn't saved it, but most of the shader was opted away
15:55 imirkin_: and merge the precise modifier
15:55 karolherbst: and it ended with like 15 instructions
15:55 imirkin_: ultimately it needs to do the ops twice
15:55 imirkin_: once precise, once not-precise
15:55 imirkin_: the former should land into .xyz, the latter into .w
15:56 imirkin_: or just once but precise, in which case the .xyzw value ends up everywhere
15:56 karolherbst: but I am 80% I tested with opts disabled and it still failed
15:56 karolherbst: *sure
15:56 karolherbst: hope I am wrong, otherwise it could get really interesting
16:43 moongazer: Error while trying to compile nouveau from source: https://paste.ofcode.org/k6UH7WFT76mpFTnAa8JupR
16:43 moongazer: uname -r yields: 4.12.0-rc3-custom
16:44 moongazer: I am trying the out of branch compile, by the way
16:45 moongazer: karolherbst, ?
16:47 karolherbst: moongazer: yeah, that might happen if you compile from the wrong drm-next commit
16:47 karolherbst: moongazer: search for "drm-next" in git log
16:47 karolherbst: there you get the last base basically
16:49 moongazer: karolherbst, what do you mean????
16:49 karolherbst: moongazer: well, learn how to search for a string in less and how to use git ;)
16:50 moongazer: karolherbst, :( I know how to do that ofcourse
16:51 moongazer: I mean, do I do that for nouveau or for the entire kernel
16:51 karolherbst: inside the nouveau repository
16:51 moongazer: THANK GOD
16:51 karolherbst: then you get the commit hash of the drm-next commit
16:51 moongazer: So I should just reset the head
16:51 karolherbst: inside the drm-next kernel tree ;)
16:51 karolherbst: and install that new kernel
16:54 moongazer: NOOOOOOOOOo
16:59 moongazer: I just made a mistake
17:00 moongazer: karolherbst, I mean I do it for the standalone one or for the directory in the entire kernel
17:00 karolherbst: moongazer: the kernel you installed and booted from
17:02 moongazer: karolherbst, that is gonna be so problematic
17:03 moongazer: karolherbst, shallow clone
17:03 karolherbst: moongazer: well .....
17:03 moongazer: karolherbst, got to wait a few hours xD
17:03 karolherbst: moongazer: make a shallow clone from commit
17:03 karolherbst: or a full clone
17:10 moongazer: karolherbst, I am trying to get hold of a good connection, got to borrow my neighbour's wifi
17:10 moongazer: wait
17:47 pmoreau: moongazer: If you run the following command inside the Nouveau repository, it will tell you which commit from drm-next or Linus’s tree you need: `git log --oneline --grep="^v[0-9]\.[0-9][0-9]\?\(\-rc\d\)\?" --grep="^drm-next [0-9a-f]\{40\}" -n1`
17:50 moongazer: pmoreau, thanks, I will record it
17:51 moongazer: The kernel has been building for the past few minutes
19:47 moongazer: pmoreau, karolherbst I tried what you said. Still the same erro
19:47 moongazer: *error
19:47 pmoreau: Can you paste the error please?
19:48 pmoreau: When running `make` in Nouveau, you need to tell where to look for your custom kernel, by setting the LINUXDIR environment variable
19:48 pmoreau: You are probably missing that one
19:54 moongazer: pmoreau, https://paste.ofcode.org/Vr8k27aJ8Q2DqBE6eWqRvT
19:54 pmoreau: Mmh...
19:55 pmoreau: Which commit is your 4.12.0-rc3 at?
20:02 moongazer: pmoreau, HEAD detached at bb57d04
20:04 pmoreau: You need to be at least on the 4.12-rc3 tag
20:05 pmoreau: Try the git log command I gave you to get the required commit for Linux
20:05 john_cephalopoda: Hey, I get a freeze of my whole desktop that can't be solved by MagicSysRq-reisu(b), reproducible, when starting Unity games.
20:05 universecoder: pmoreau, I got disconnected
20:06 john_cephalopoda: Is there any way that I could trace that to get usable information about the cause of the freeze?
20:06 pmoreau: john_cephalopoda: Do you have some logs from when it froze?
20:07 pmoreau: universecoder: Ah, you are moongazer :-)
20:07 pmoreau: universecoder: You need to use at least the v4.12-rc3 tag. You are on an older commit
20:08 john_cephalopoda: pmoreau: Oooh, just found a log.
20:08 universecoder: pmoreau, I don't understand
20:08 john_cephalopoda: It looks very nouveau-ful.
20:09 universecoder: pmoreau, uname -r yields 4.12.0-rc3-custom
20:09 pmoreau: universecoder: The commit you are on is from Fri May 12 14:25:22 2017 +1000, the Git tag v4.12-rc3 is from Fri May 12 14:25:22 2017 +1000
20:09 john_cephalopoda: pmoreau: https://bpaste.net/raw/3f0027281dfd
20:10 john_cephalopoda: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)
20:10 pmoreau: *the git tag is from Sun May 28 17:20:59 2017 -0700
20:10 pmoreau: The fact that `uname -r` says 4.12.0-rc3 does not mean you are at least on the v4.12-rc3 tag
20:11 universecoder: pmoreau, where do I checkout then, tell me. I have the full clone now
20:11 john_cephalopoda: Mesa version 17.1.2, xf86-video-nouveau 1.0.15, Linux metis 4.11.0 #2 SMP
20:12 pmoreau: john_cephalopoda: Thanks. Do you have a full log?
20:12 pmoreau: That is the second time today I am seeing "[drm:drm_atomic_helper_swap_state] *ERROR* [CRTC:37:head-0] hw_done timed out", associated with hangs and such
20:13 john_cephalopoda: pmoreau: That is all the log I could find.
20:13 pmoreau: skeggsb: -^ Have you seen those/have any ideas?
20:13 pmoreau: universecoder: Git tags can be checked out like regular commits, so `git checkout v4.12-rc3`
20:14 pmoreau: universecoder: You can try something like this script to automatically checkout the needed commit https://hastebin.com/muquwilazi.bash
20:15 pmoreau: universecoder: You probably need to add a remote for Linus' tree: `git remote add torvalds git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git`
20:15 john_cephalopoda: pmoreau: /var/log/kernel only had those lines associated with nouveau after the boot sequence of that cycle. Currently browsing Xorg*.log.old, but I doubt that I find something there.
20:15 pmoreau: Maybe if you have journald, you could check `journalctl -b -1` to get the logs from the previous boot
20:17 john_cephalopoda: pmoreau: I'm using klogd.
20:17 john_cephalopoda: Which messages exactly do you need?
20:17 pmoreau: Anything related to Nouveau and drm
20:18 john_cephalopoda: The ones I linked ( https://bpaste.net/raw/3f0027281dfd ) are the only messages that happened during the crash things. I can also paste the nouveau messages around boot time.
20:18 pmoreau: If you have another computer, are you able to SSH in? Or if you SSH before it happens, can you grab logs after it happens?
20:19 pmoreau: What card is that btw?
20:19 john_cephalopoda: <john_cephalopoda> 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)
20:20 john_cephalopoda: pmoreau: Those are all the available logs. I got the whole log from second zero of booting up to the reboot by sysrq.
20:20 universecoder: pmoreau, error: pathspec 'v4.12-rc3' did not match any file(s) known to git.
20:21 pmoreau: universecoder: Have you added the remote to Linus' tree (and fetched that remote)?
20:26 pmoreau: john_cephalopoda: Do you have a way to SSH in / see if the computer is still responding even if the graphical interface is unresponsive?
20:26 john_cephalopoda: pmoreau: Unfortunately not right now.
20:27 universecoder: pmoreau, on the new branch now
20:27 universecoder: Now what
20:27 john_cephalopoda: pmoreau: At least it can be shut down with magicsysrq, so that still works.
20:28 pmoreau: john_cephalopoda: I guess it is a regression, isn’t it?
20:28 pmoreau: universecoder: So, you are on commit 5ed02dbb497422bf225783f46e6eadd237d23d6b, right?
20:29 pmoreau: You will sadly need to recompile the kernel using this new version. It should be faster than the previous one, as you are not starting from scratch
20:29 universecoder: pmoreau, yep
20:30 universecoder: pmoreau, ok
20:30 universecoder: pmoreau, 1 hour to go
20:30 john_cephalopoda: pmoreau: What do you mean by "regression"? If it was like that in previous versions?
20:31 pmoreau: Did you experience those freezes on a previous release of the kernel, or is it the first time?
20:34 john_cephalopoda: I don't play many games, so I can't tell.
20:34 john_cephalopoda: Here's a full log of such a crash: https://bpaste.net/show/b582f15a559f
20:36 john_cephalopoda: Here is a full log of an other crash: https://bpaste.net/show/fe8ec7701d66
20:36 john_cephalopoda: With an other unity game, always freezes when the logo appears.
20:36 pmoreau: Do you have another kernel at hand, like 4.9 or 4.10?
20:40 john_cephalopoda: I should have one.
20:40 john_cephalopoda: Back in a bit.
20:45 john_cephalopoda: It also happens with 4.10.0
20:49 john_cephalopoda: pmoreau: Here is the log for the 4.10.0 kernel: https://bpaste.net/raw/df637d94efc0
20:50 pmoreau: If it happens in 4.9, that would rule out the modesetting rework.
20:50 john_cephalopoda: 4.10 is the oldest I got around.
20:50 pmoreau: Ok
20:51 john_cephalopoda: I could get a 4.9 and try. Which version and patchlevel should I use to verify if it's a modesetting rework problem?
20:52 pmoreau: The modesetting rework was first introduced in 4.10, so any version of 4.9 should work
20:52 john_cephalopoda: Ok. That may take a bit.
20:53 pmoreau: Take your time
21:23 john_cephalopoda: Nope, no regression.
21:26 john_cephalopoda: I tested it with 4.9.32, still freezes.
21:30 pmoreau: Thanks for testing!
21:31 pmoreau: So, just playing a Unity game triggers it all the time, is that right?
21:42 TheCephalopod: pmoreau: I tried with various games. When I start the game, as soon as the logo animation screen begins (grey screen, logo is not displayed yet9, the computer freezes.
21:45 pmoreau: TheCephalopod: Are any of them free, so we could try them?
22:30 john_cephalopoda: pmoreau: I got some internet issues rn so I'm not sure if you got my last message. Doesn't work in 4.9.32.
22:31 pmoreau: I did saw it :-)