01:46imirkin: pmoreau: where's your spirv -> nv50-ir converter live?
07:21karolherbst_work: mwk, mupuf: since 4.6 drivers can protect mem regions to be remaped by userspace. Adding "iomem=relaxed" to the kernel helps
07:22karolherbst_work: related to my issue from yesterday
07:23mupuf: not sure what you mean. Are you telling me the userspace can have partial control of the iommu (mirroring address spaces to other addresses with different access rights)?
07:23mupuf: or you mean that the kernelspace may hand out an address to the userspace that is going to be limited in space by an iommu
07:25gnurou: mupuf: means some userspace mmap() may fail if a driver is loaded - I have met this issue as well when debugging a driver
07:25mupuf: gnurou: oh, lovely!
07:25mupuf: then I guess I will need to set this parameter to my grub :)
07:26gnurou: if you plan on reading some IO region while a driver is using it, "iomem=relaxed" will keep you out of trouble
07:27gnurou: actually it may even be that way since 4.4... commit 90a545e98 is what introduced this behavior
07:39karolherbst_work: mupuf: that's why I told about this :p
07:39mupuf: karolherbst_work, gnurou: thx
07:40mupuf: adding it right now. before I forget
07:46karolherbst_work: mupuf: tell Dan, if he does stuff like that again, he should inform us too :p
07:47karolherbst_work: mupuf: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=90a545e98
07:47mupuf: never heard of him
07:48karolherbst_work: weak performance from you, knowing _everybody_ is the first step everywhere :p
07:48gnurou: probably someone working on persistent memory
07:48gnurou: according to the motivation for this patch
07:48karolherbst_work: most likely
08:01mupuf: probably, yes :)
08:01mupuf: karolherbst_work: yeah, good luck knowing every OSTC developers :D
08:01mupuf: well, admitedly, there are fewer and fewer of them with the big cut
08:06karolherbst_work: yeah, I noticed
08:19karolherbst_work: mupuf: but is the situation really that bad? Because it somehow feels like it from outside (though I know, that you might be able to say anything regarding this anyway :p )
08:21mupuf: well, it is what it is. It is really bad for the people who got fired
08:21mupuf: france lost almost all R&D
08:21mupuf: Sweden is also highly impacted
08:30karolherbst_work: mupuf: :/
08:36karolherbst_work: mupuf: well I hope for you it will get better at some point
08:37mupuf: I am sure it will ;)
09:06karolherbst_work: hehe, yeah, I don't see intel going down, just because some managers want to save money
09:46OxOO: it's NV49(G71) chipset
11:20donbruno: what does me tell: "DRM: Pointer to TMDS table invalid" or "DRM: Pointer to flat panel table invalid"??
11:20donbruno: can I repair this?
11:27karolherbst_work: donbruno: it may not matter
11:27karolherbst_work: donbruno: I would only care about stuff like that, if something is indeed broken and related
11:29donbruno: ok thx karolherbst_work
11:48night199uk: hey, i’m trying to understand the nvidia pll’s, and the code in the various PLL modules of nouveau for calculating pll values
11:49night199uk: as I understand it N, and fN are N and the frational part of N for a fractional pll
11:49night199uk: but i don’t understand M, D, PL, etc?
11:49night199uk: anyone understand that code?
11:51karolherbst_work: night199uk: depends a bit on the chip actually, but M/P are divider on kepler, best would be if you read the code
11:52night199uk: yeah, i’m reading the code but I’m a bit of a newb to PLLs as well :-)
11:52night199uk: i’m reading this in parallel http://www.ti.com/lit/an/swra029/swra029.pdf
11:52karolherbst_work: night199uk: for fermi: return sclk * N / M / P;
11:52night199uk: but a lot of the variables don’t match up
11:53karolherbst_work: for tesla (and maybe older): return (ref * N / M) >> P;
11:54karolherbst_work: no idea what D might be, maybe it is the divider for the dividers
11:54night199uk: karolherbst_work: thanks, let me see if i can make sense of that with the code i have - is there a good ref for PLLs that I can read to understand this better you might know?
11:55night199uk: that ti doc helps, sort of
11:55karolherbst_work: night199uk: I worked on that a bit for kepler memory dual-PLL configurations, but kepler has simplified PLLs compared to older chips
11:55karolherbst_work: night199uk: no clue, never read any docs about PLLs
11:56night199uk: okay, let me see if i can make sense of this with what you just said
15:00gnurou: mupuf: maybe Softbank can buy Intel... too bad it is not a UK company ;)
18:37karolherbst: can somebody tell me how the reclocking state is while the gpu is suspended? I dont have the runpm fixes applied and my card wont suspend with nouveau now until I reboot again
18:38imirkin_: "how the reclocking state is"?
18:38karolherbst: well, what happens when something is writting into pstate while the gpu is suspended
18:39imirkin_: iirc you get an oops.
18:39karolherbst: mhh, yeah, I think so too
18:39karolherbst: but ben said in his review, that it worked before my patches
18:39karolherbst: and within my patches I return -EAGAIN while the gpu is off
18:39imirkin_: or some sort of badness at least
18:39imirkin_: you definitely could cat the pstate file
18:39imirkin_: and see all 0's for current freq
18:39karolherbst: yeah I know
18:40karolherbst: but I at least added that after suspend, the previous clocks are restorted
18:40karolherbst: and I am sure, stock nouveau defaults to POSTed clocks
18:40karolherbst: I also wanted to make it able to reclock while the gpu is off in a way, that the clocks are set after resuming, but somehow I got opses there
18:41imirkin_: anyways... if you want people to test stuff, ask for precisely what you want them to run
18:41imirkin_: that said, i won't be helping as i don't have optimus
18:42karolherbst: well, I just want to know what happens if something gets echoed into pstate while the gpu is suspended
18:42karolherbst: and what happens after the gpu resumes (after the user reclocked before suspend)
21:38pmoreau: imirkin_: The main branch is here: https://phabricator.pmoreau.org/diffusion/MESA/history/spirv_1.0/ with some information on how to configure stuff there (which could be out-of-date) https://phabricator.pmoreau.org/w/mesa/testing_opencl_through_spirv/
21:39imirkin_: pmoreau: is there like a 2-sentence summary of how far you've gotten?
21:40pmoreau: I don’t think I have that, but I can try to do it live :-D
21:40imirkin_: it looks as though there has not been any attempt to properly deal with phi nodes
21:40imirkin_: any other shortcomings?
21:41pmoreau: Calling other functions doesn’t work, no phi nodes, started working on textures almost on the read/write insn, no arrays nor structures but code should handle it.
21:42pmoreau: And I need to fix the operations, since currently the inputs are defining the sign of the operations, and no the operation type. Shouldn’t be hard to fix.
21:43imirkin_: sure, that sounds like a smaller thing
21:43pmoreau: Regarding clover, clCreateProgramWithSource, clCreateProgramWithBinary and clCreateProgramWithIL are supported.
21:43imirkin_: more looking at it from a vulkan standpoint